State of the Code

[svenskmand]

Nice, I will try and build it and update my build script accordingly.

[andrewbuck]

I just pushed a commit to sourceforge which adds support for subgoals to the level file. I have bumped the game version to 0.4.7 since the file format has changed but if you keep running your same level file and just change the number it will still be compatible with the new format (explained below). Subgoals are lists of goals which are added to your list of things to accomplish in the level when their parent goal is either successfully completed or failed. The goals section of my level file now looks like this:

{l Code}: {l Select All Code}

# Goals
5  # The number of goals to load.
# goalName   arguments
KillAllEnemies   NULL
ProtectCreature   King
- 1
ClaimNTiles 1000
ClaimNTiles   200
MineNGold   20
+ 1
MineNGold   5000
+ 1
MineNGold   10000
ProtectDungeonTemple   NULL


This means that there are a total of 5 goals to load initially that you must complete to be declared a winner for this level. Two of them, however, have nested subgoals. After The protect creature goal is failed there is one subgoal which will be added, the "ClaimNTiles 1000" goal. Note: the protect creature goal itself is broken right now and you fail it no matter what you do, I started a trac ticket on this issue. Also if you look at the "Mine 20 gold" goal, you see it has one subgoal which is added when you complete it, expecting you to mine 5000 gold. This subgoal has a subgoal of its own which is that you mine 10,000 gold. The goals do not have to be of the same type like this, that was just a convenient way to test the system. This lets you design levels for a campaign which have more than one way to beat them, and depending on the way you finally beat the level you proceed to a different level next. So you could have a level where you start out trying to defend your dungeon temple. If you fail and that is destroyed it activates a chain of subgoals requiring you to protect some creature until they can be brought to safety. Depending on which way you beat the level you would either start the next level in your dungeon temple that you protected, or in a new area with just a few creatures that managed to escape and a different dungeon temple. I will close the trac ticket on this feature addition which moves us a bit closer to the next release.

-Buck

[Bodsda]

That's excellent news. For level/campaign designers, we can get really imaginative now. I think this will give a great depth to the game that wasnt seen in DK.

[andrewbuck]

Yeah, Thats kind of why I wanted to get it into this release. I am hoping that the game is starting to get near enough to complete that we can start examining level design, creature statistics (hp, damage, etc), room design, and other balance issues. These kinds of things will take a long time to work out and there is no way around that so the earlier we start the better.

-Buck

[Bodsda]

Yeah, Thats kind of why I wanted to get it into this release. I am hoping that the game is starting to get near enough to complete that we can start examining level design, creature statistics (hp, damage, etc), room design, and other balance issues. These kinds of things will take a long time to work out and there is no way around that so the earlier we start the better.

-Buck

Balancing is always an issue. And due to the ammount of creatures we invisage having, it will probably be quite painful for us. But the easiest way to balance is to play the game. Hopefully we can have a playable campaign before 2012

Bodsda

[andrewbuck]

I got the bug fixed that was causing the workers to get stuck forever trying to dig out claimed tiles and never making any progress. Now they dig them out as they should, however the digging is much slower than for other tiles (currently 0.2 times as fast). While working on this I did a bit of tweaking to the way tiles are redrawn and there is now a bug where sometimes gold tiles will still show gold on the ground after they are dug out. The new bug is caused by the removal of a line of code that I considered somewhat of a hack so I removed it. I hope to get a fix worked into the new code which will handle it automatically in the Tile::digOut() function (and it should be already) but this does not always seem to happen. It may be due to the fact that tile fullness is stored internally as an int. I plan to change this eventually so hopefully this bug will just resolve itself.

-Buck

[andrewbuck]

I just put up a change which limits the dojo to be only used by 3 creatures at a time. It seems to work pretty well and the system I set up to do this should make it possible to have other rooms (like the forge, etc) use it as well. I think in the future I will need to add some code to prevent creatures from trying to walk to a training room if it is more than a certain distance away.

By default a room will allow any number of creatures to use it, but can keep track of which ones are (I plan to switch the quarters over to this system and use it that way). Alternately, rooms can override the function which says how many open "slots" there are to limit the numbers in a way that makes sense for that particular room type.

-Buck

[andrewbuck]

I got a commit pushed a few minutes ago that fixes two bugs. One is the crash on combining quarters together when they have beds in them. The second was a bug in the creature AI that was reported by Danimal in a youtube comment on the last video I made of the gameplay. I will repost the comment and my replies below if anyone wants to read them without jumping over to youtube.

Need music, and sometimes the creatures are sliding in the floor instead of walking and they seem to be rather pasive towards enemy creatures
Danimal696969 2 days ago

I am still working on fixing this bug. I made some changes to the animation code which result in a better underlying system but it exposed a lot of places where I wasn't quite handling the animations correctly. I have fixed some of these bugs already but there are still a few in there.

The combat AI is still very rough. I haven't spent a lot of time getting it working and tuning it beyond just making the creatures kill eachother.
OpenDungeons 1 day ago

"they seem to be rather pasive towards enemy creatures"

Thank you for pointing this out. I looked into it and the attack action was pushed onto the creature's action queue but then another action like train or sleep could get pushed on top before the attack was processed. Adding a jump to start processing the attack immediately fixed the problem. A two line bugfix that makes the game much more playable. Thanks again for pointing it out.
OpenDungeons 7 minutes ago

[Danimal]

No prob, happy to be of use to better this project.
Thinking back i did choose a rather ashmasing nickname for youtube, oh my youthful days...

[svenskmand]

Cool subgoals , I cannot wait to be mapping for our great game

[andrewbuck]

I got a commit added just a bit ago which makes the dungeon temples spawn 4 kobolds as we had discussed (actually it just prints a terminal, the actual spawning code needs to be added).

I also split up the code for the GameMap::doTurn() routine into three separate threads which should allow it to either run more turns per second or run with more creatures (assuming you have enough cores to actually run them in parallel). There seems to be a deadlock that pops up occasionally as a result of this but that should be pretty easy to resolve once I have a look at it in the debugger.

-Buck

[oln]

Pushed a commit doing the changes needed to build with MinGW. Release is being uploaded to sf.

[svenskmand]

Please make a wiki post while it is still fresh in you mind, then I will try it out

[oln]

Working on a wiki update.
I seem to have forgotten the mingw runtime dlls in the release, I will see what i can do about it.

[oln]

Will reupload with the needed dlls when andrew has tested it.

[oln]

Wiki updated and new file uploaded. Please test svenskmand.

[andrewbuck]

I got a whole bunch of minor race conditions fixed today in an attempt to fix a crash when the creature AI is done in more than one thread, however I was not yet able to fix whatever is causing the crash so the numThreads variable in the doTurn() method is currently just left at 1 (which basically disables multithreading). Solving these race conditions through proper semaphore locking on the affected variables should help make the game more stable/reliable in general and is definitely worth doing periodically.

Even though I didn't get the bug fixed that I was looking for I did get one random segfault that has been plaguing me for a long time fixed so that is cool.

-Buck

[andrewbuck]

Several more commits fixing lots more potential race conditions, some of them with the potential to cause major bugs like segfaults, etc. In fixing all of these the multithreading of the creature AI has worked itself out so now it doesn't crash. I have enabled it in the git version of the code now and have added support for it to be adjusted on the fly on the in-game console (see the aithreads command help on the console for details). I have the number of threads defaulting to 2. On my dual core computer this seems to work about right, setting it to one disables the speedup to the AI routines, and setting it to more than 2 causes it to steal too much CPU time away from the renderer which causes jerky animations. People who have more than two cores in their computer may want to experiment with higher values (theoretically any number of threads is possible and the game will auto limit itself if the number of threads is greater than the number of creatures). If you have a nice multicore rig and want to try setting it to 15 or 20 threads you could and it should be stable. You do seem to get better performance with more threads than cores, however the gains will begin to diminish with more threads.

All of these race condition fixes should make the running game a lot more stable, and since we have a release coming out soon I think that is a good thing. I have been using valgrind a bunch to find these race conditions and may give it a run or two in trying to find memory leaks as well.

-Buck

[oln]

Me and svenskmand went through the windows mingw build procedure and verified it, and it works. The instructions on the wiki are updated. I have VM set up to build for windows, so it should be simple when the release is ready.

[svenskmand]

Andrew could you explain me how the thread model works in the game?

[andrewbuck]

The thread "model", well there are quite a few threads. The main one that starts right away handles the rendering and user input. When you run the 'host' command you spawn one thread to handle cleint socket connections and another to do creature AI (as well as one for a server message processor). The AI thread runs in a loop and executes each turn. When the turn starts it spawns two threads (an AI thread and an upkeep thread), and it joins them at the end of the turn. This short-lived AI thread then spawns N threads to do the AI for the individual creatures. It is this N that is what you set with the terminal command above.

If you want to see this graphically there is a big PNG picture of it in the Documentation directory in the code you check out from git. The picture does not include the recent threading work for the AI stuff though, it is more focused on the message passing infrastructure which hasn't changed. Hope this answers your questions.

-Buck

[andrewbuck]

I just pushed a commit in which adds a "stats" window that pops up now when you middle click on a creature in the game. The stats window shows the creatures HP and mana (and the max for both which is currently just stuck at 10 since it's not read in properly from the level file). It also shows the creature's current AI state and the window gets updated when this state changes so you can debug the AI routines more effectively. In the future this window will be how you can change the creature's properties in the map editor (properties like color, etc).

-Buck

[andrewbuck]

New commit which _finally_ adds support for starting a game by clicking on buttons instead of having to run the host command from the terminal. This should make it easier for new users to play the game. You can now go to the "System" tab along the bottom of the window and click the "Host a server" tab and it will start playing the current level you have loaded. I don't know why I didn't get this working sooner, but it works now so that is good.

-Buck

[andrewbuck]

I just got a commit added which makes the dungeon temples spawn kobolds like they are supposed to. You now get one kobold of your color spawned every 30 turns until you get up to 4. This prevents you from being unable to finish the level just because your kobolds died. You still have an incentive to keep them alive though because they are much more useful at higher levels and also 30 turns is a fairly long time to be without them.

-Buck

[andrewbuck]

Just pushed a commit with a _major_ speedup to the creature AI routines with basically no effect whatsoever on the functionality. There is a function called getReachableObjects() which you pass it a list of attackable objects and a starting tile and it returns a new list of only the objects which can be "walked to" from that starting tile. It can also optionally return a pointer to the nearest one (by walking distance) and the distance. This option was being used and it resulted in hundreds of calls to the GameMap::path() function, which although it is a fairly optimized routine is still pretty expensive. So all of these hundreds of calls were being made to compute the distance to the nearest enemy object which was being used to... alter how likely workers were to attack vs just working (i.e. nothing of any significance whatsoever). Not using the option to have that function speeds the game up a lot, the battle test level I built on my system here previously struggled to keep up taking about 2 seconds per turn on my CPU, now it does the same level in 0.2 seconds per turn, a tenfold improvement.

-Buck