"Improving OpenDungeons" party

[MCMic]

Hi!

I'm organizing next week a afternoon of coding for OpenDungeons.
The idea is to work on the code together with a few friends, there will be 4 of us at least.
It will be thursday, the 31th. About from 13:30 pm to 17:30pm (french time)
We are all student in computer sciences, most of us already worked on small game projects. (Not all of us in C++ though)

I mailed andrew about this and got no answer, so I'm asking you, what part of OpenDungeons should we work on?
I would like it to be something noticeable so we can actually see we improved the game.
Is there a TODO somewhere?

[oln]

Some major things that you could work on are:

• A startup menu
• Sound engine
  • Delayed playback to synchronise creature effects with animations
  • Add in sound play calls on more of the creature actions
  • Rewrite the sound back-end to use openal directly instead of using sfml
• Graphics
  
  • Get normal mapping working (It's okay if the team colouring breaks)
• Gameplay
  
  • Start support for a computer AI for opponents
  • Improve creature AI - not sure about the details here, andrew will have to fill in
  • Improve room functionality - not sure about the details here, andrew will have to fill in

There are probably more things to do that I forgot.

You can also look at the bug tracker for some ideas:

https://sourceforge.net/apps/trac/opendungeons/report/1

It's really cool that you want to want to work on the project

[svenskmand]

Very nice initiative MCMic

I say figure out how to get the normal maps working. It is no coding per se, as you should only need to configure the material scripts of models correctly, but it will have a HUGE impact on OD, and Skorpio will love you the rest of you life

And if you get that done, then I think a particle system would also be very nice, so we can spice up the graphics of the game.

Another idea would be to implement the UI for setting up traps, we want to use a extended version of the system in Evil Genius, that is: after you have placed some traps you can connect triggers and traps by right clicking on one of them, then a graph is overlaid on top of the game, where traps and triggers have a circle/node hovering above them, then you can click one and then another one to connect them using a directed arrow, see the image below:

[StefanP.MUC]

As the for Startup menu, there's already a CEGUI layout in the gui folder on svn. This should be a quick task and enhance the game strongly.

Another task could be: split (better: reduce by optimizing) the 1000+ line code blocks in creature.cpp, for example. It's extremly hard to get into the code of the game and understand it if you have to read over 1000 lines of dozenz of for/while loops that are partially nested even.

[MCMic]

Another idea would be to implement the UI for setting up traps, we want to use the same system as in Evil Genius, that is: after you have placed some traps you can connect triggers and traps by right clicking on one of them, then a graph is overlaid on top of the game, where traps and triggers have a circle/node hovering above them, then you can click one and then another one to connect them using a directed arrow.

Hum, I don't know Evil Genius, and I don't understand fully the UI you're aiming for.
That would be an interesting thing to do, thought.
Would that be using CEGUI? Or would it be directly handled with OIS?

StefanP.MUC : Doing a startup menu seems to be a bit complicated :
-We don't know CEGUI at all (or at least I don't, I'll have to check with the others)
-It would mean change the way the game is launched, and that part of the code seems obscur to me, with all the Ogre and CEGUI system.

[svenskmand]

You should not use cegui for the trap system ui, only ogre. I can make a more detailed explanation of the ui tomorrow. Also if you try out the demo of evil genius that will show you how it should work.

[oln]

That kind of trap system seems kind of ambitious for a 4 hour job.

[StefanP.MUC]

For the startup menu you don't really have to know CEGUI. I already did set up a menu layout (in CEGUI's own XML syntax), only thing to do is to load the menu screen and add the button handlers (you can have a look at the other ButtonHandlers to see how this is done).

But if you you don't do the main menu it's OK (after the improvment party I'll have a look at it if it's not done by someone else until then). The others things (normal mapping or sound system) are much more important, IMHO.

[svenskmand]

That kind of trap system seems kind of ambitious for a 4 hour job.

True, but that is the case for all of the problems :S

[StefanP.MUC]

Yeah, that's also my problem getting something done code-wise, currently. All the tasks need so much refactoring work before you can starting coding your intended function.
I just took a look at the main menu problem to get a general overview and it's harder than I thought:
The problem is that the source code we are currently working on was originally planned as a standalone map editor without lots of fancy hick-hack around ("start the app and edit the map"). The current code just directly initializes the whole 3D rendering stuff and loads the map and ingame menus instantly in one big code blob. I think, to get a main menu done there's a lot of reordering and code separating and refactoring needed.
However, the menu itself shouldn't be a problem at all (I already have the code to set the button handlers and load the layout file, etc).

[svenskmand]

Well then refactoring is the true next job to approach. But you need to be very comfortable with the code base to do proper refactoring, so I think it is better newcomers does not do that, unless they have read the code and know by heart the inner details of it and that truly takes allot of time :S

[svenskmand]

Some major things that you could work on are:

• Rewrite the sound back-end to use openal directly instead of using sfml

Why do you want to do this? Is SFML not fine?

[oln]

I think the sound might be the easiest to work on as it's quite separated from the rest of the code.

Some major things that you could work on are:

• Rewrite the sound back-end to use openal directly instead of using sfml

Why do you want to do this? Is SFML not fine?

I have changed my mind again since that post, so just ignore it.
It would have mainly meant less dependencies, also I had some issues that I had to work around, though that's been fixed now.
Anyhow, it would be way down on the stuff to do list.

[svenskmand]

Anyhow, it would be way down on the stuff to do list.

But still what should the benefit be, except from one dependency less?

[andrewbuck]

Sorry I didn't get back to your e-mail. The account I have on here is one I don't check very often, also I have been busy working on OpenStreetMap in Libya in support of necessary humanitarian work that will be done there after the fighting stops. The idea for an OD coding party is actually not any different than some of the mapping parties their project has done, I like it.

Any of the things listed by oln would be good to work on. As for the AI and whatnot, feel free to change that block of code, split it up into functions or whatever. Basically it is just a finite state machine implemented in a big switch statement, but there are other ways to do a finite state machine as well.

-Buck

[MCMic]

Well, I think we'll go with the trap&trigger system.
I have a week to understand what svenksmand mean with this whole "directed arrow" thing xD

Would it be possible to have a comment at the approximative lines of the code where we should implement this thing? (something like /* MCMic coding party emplacement */, so that I could search for the MCMic keyword in the code and read the functions that contain it. We would remove these comments after the coding party)

[svenskmand]

Ok, I will make a detailed post later today about the system, I will make it on the wiki. I will also suggest a plan for implementation, i.e. which concrete things to do first, as the system I have planned have allot of details, that will probably not be doable in 4 hours. But if you get the basic stuff running that would be an incredibly nice new feature in the next release

[StefanP.MUC]

I pushed a commit adding some basic stuff for the main menu (in case you don't read the State of the Code thread).

[svenskmand]

I read all threads :P

[StefanP.MUC]

I did mean MCMic.

[MCMic]

I read all threads, btw, why is this "state of the code" thread? You guys never heard of git log?

Svenskmand : thanks a lot! Even if we only spend 4 hours on the code, I think I'll continue coding on Open Dungeons personally, at least helping using what we did.

[StefanP.MUC]

You can't discuss in a git log. Not everything goes into the "state of the code" thread, only summaries and discussions of bigger or even major changes. It's also a good way for non-coders to follow the development.

[oln]

What stefan said. Though we are of course commenting the commits in git as well.

[svenskmand]

I am not completely done with the wiki entry, but I will have it up tomorrow.

[svenskmand]

Ok here is the wiki post for how the traps and trigger system works.

Now regarding implementation I suggest you follow these steps:

• Make one of each of the basic trap types; proximity traps (a cannon), directional traps (a boulder), and single tile traps (the lightning trap) which is triggered when a creature enters this tile.
• When these three basic types of traps are working, then make a trigger, and add the code so it is possible to make it trigger say a bolder trap, i.e. no UI yet. Then add the functionality that traps can trigger other traps.
• Now is the time to add the UI elements, first make the rings display over the traps and triggers, and make the user able to enter and exit the traps and trigger system.
• Now add the basic functionality of left clicking a trigger or trap, and then left clicking another trap, to connect them. Then added the ability to remove an arrow.
• Now refine the arrow selection by implementing the "selection mode" where you can choose which arrow to select by use of the mouse wheel.
• Finally add the ability to enter delays for an arrow, and display the delay for an arrow.

When you implement this you will run into these challenges: 1) how to do the layouting of the arrows so they look nice (i.e. collides less) here I suggest just doing it simple first and then take one of the two Manhattan routes (i.e. the red one in Wikipedia) between the two points, then we can latter tweak this to look nice, but it will be very difficult. 2) Deciding if and where to place the delay of an arrow, so it is clear which arrow it corresponds to when your not hightlighting an arrow (when you do hightlight an arrow the number is also hightlighted and then it is easy to see that it belongs to the arrow).

Let me know if something is unclear to you