Application to OpenMW: nhydock

Join the team. This area is for people who want to participate in OpenMW's development in one way or another.
Post Reply
nhydock
Posts: 6
Joined: 21 Jan 2012, 23:21

Application to OpenMW: nhydock

Post by nhydock »

Purged
Last edited by nhydock on 04 Oct 2014, 22:21, edited 1 time in total.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application to OpenMW: nhydock

Post by Zini »

Welcome.

You have forked OpenMW already. Can I assume, that you have gone through the rest of the new developer checklist (link in pinned thread in this forum section)? If not, please do so, before you do any development work.

As I wrote on the bug tracker, the 3D pausing needs to be discussed more. Right now I am sceptical about it and anyway it is a post 1.0 feature.

You can have the player control task (including the camera). This is not a beginner task, because it requires a certain amount of knowledge about our codebase. But if you want to have a go at it, feel free to give it a try.

Please note, that you should work on the subtasks of player control in the order given, because the early tasks are prerequisites for the later ones.

When you are ready to code, please make a new thread for this task in the development section of the forum (one thread for all sub-tasks of player control is enough). If you need any help finding your way around in our codebase please ask.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Application to OpenMW: nhydock

Post by Zini »

As for documentation: You will find our codebase a bit underdocumented in some areas (*slightly nudging some coders*). We use doxygen for code documentation and you can even find the doxygen generated pages for the most recent release online.

My position is, that each class should have at least a \brief field, with additional explanations where needed. Any transfer of ownership (the responsibility of deleting an instance) must be explicitly documented and also any special out of band values/restrictions to arguments and return values. In functions of non-trivial size it is preferable to have a line of comment per code section. Some documentation at a larger scale (e.g. apps/openmw/doc.hpp or components/doc.hpp) is also useful.
On the other hand I don't like over documented code. A function named setStrength certainly does not require a "sets the strength" comment; unless there are other specifics to it. In particular I am not a fan of documenting member variables or local variables (unless there is something very special about them). Having too much documentation will only make it hard to keep the documentation in sync with the code.
User avatar
ElderTroll
Posts: 499
Joined: 25 Jan 2012, 07:01

Re: Application to OpenMW: nhydock

Post by ElderTroll »

I would really like to welcome you. I appreciate how professional your application is. It sounds like you'll be a great addition to the team. Like I told Draghan, please tell your friends and peers about OpenMW. Maybe next summer we'll be in a position to get a Google summer of code student!
nhydock
Posts: 6
Joined: 21 Jan 2012, 23:21

Re: Application to OpenMW: nhydock

Post by nhydock »

I've been following this project since October and have been regularly posting on my facebook the preview videos you guys release each month to inform my friends. Sadly, all of them aren't programmers like I am so they wouldn't be much help code wise unless they could continue to get the word around.
Post Reply