State of the Code

[svenskmand]

The coolest is the improvements to the mesh optimization routines for the tiles. The game now does a much better job of "rounding" out the jagged edges on the tiles than it did before.

-Buck

Another very cool improvement, suggested by Skorpio/ghoulsblade was to add perlin noise to the vertices of the dirt to get "wobbly walls" as in DK1 and 2. I also think that it would look very cool with "wobbly walls" combined with the mesh simplification which was not present in DK1 or 2 (at least to as much as we have it now).

[andrewbuck]

I do intend to switch to a hand or something like that eventually, the square thing there now is more of a placeholder than anything. As for the perlin noise on the walls, it would be a bit tricky to do as you would need to make sure the vertices on the next mesh over got the same distortions (otherwise the tiles wouldn't fit together properly. I also added a section to the upkeep round of GameMap::doTurn() which makes your land grow out automatically at a slow rate (your workers are still the main way to claim ground). I am thinking we should include some thing like this as it means you don't have to micromanage the claiming so much.

-Buck

[svenskmand]

I do intend to switch to a hand or something like that eventually, the square thing there now is more of a placeholder than anything. As for the perlin noise on the walls, it would be a bit tricky to do as you would need to make sure the vertices on the next mesh over got the same distortions (otherwise the tiles wouldn't fit together properly.

Ohh, yeah that gives problems :S and to avoid it we have to use the perlin noise on all vertices of the dirt at the same time, which again must be done each time a tile is dug out, sound like a pretty bad idea performance wise , wonder how they made it in DK1 and 2 then?

Edit: It could be implemented by just adding noise to the corners of the tile which are free from other tiles. Then we a tile is dug out, there will just be added noise to the vertices of surrounding tiles which are free. Then only a constant amount of tiles will have to be changed when digging, which is okay performance wise.

I also added a section to the upkeep round of GameMap::doTurn() which makes your land grow out automatically at a slow rate (your workers are still the main way to claim ground). I am thinking we should include some thing like this as it means you don't have to micromanage the claiming so much.

-Buck

Upkeep what is that? Is it mentioned in the wiki somewhere? So the land just expands, by automatic claiming the surrounding tiles, once in a while?

[svenskmand]

Just saw that we are now ranked 416 on SourceForge

Just to give a broarder view; we are ranked above Warzone 2100 which as far as I know is a pretty decent open source game And Nexuiz which is the best open source FPS

But remember that these ransk are only activity, and not popularity.

[Skorpio]

It looks like you may not have directx installed. The file you are referring to is not one that is part of the open dungeons install, I think it is part of the direct x runtime. I would suggest installing the directx runtime from here here (go to "Latest DirectX Downloads for Gamers").

-Buck

That helped, I can run the game now, too.

[svenskmand]

I just tried the game on Ubuntu 9.10, as I have stated before the compile went very smooth. Then I started the game and was trying to figure out the keys for camera control. I got the camera in a weird position which I could not get out of (I did not know where the buttons where) so I quited the game. But then when I started I again, hoping that the camera was at its initial starting position, I was surprised to see that the camera was constantly rotating around the axis which follow the direction the camera is pointed at at start up. No matter what I press I cannot get it to stop. I have delete the entire game, compiled from scratch and all, but I still get the same weird behavior :S Any ideas for what the hell is going on? It is very strange :S

[andrewbuck]

@Svenskmand, when you are updating the game from git and there are files added/deleted you need to do "make clean" then "cmake ." again to flush the build caches. I think this is basically what you ended up doing by deleting and pulling a fresh copy. Regarding the ranking: the score is a function of both activity and popularity (click on the dates on the left to see how the calc was done). I am guessing we are small enough that we slip through a crack somehow and get a high ranking due to something the big games have a tough time with; hopefully though we can maintain the rank long enough for the project to reach "critical mass" and really start attracting new people.

@Skorpio, glad to hear you got that figured out. We should add something to the download page on the wiki regarding directx since it is obviously something a lot of people are going to have issues with. Its difficult for me to spot these kinds of things since all my computers have a full build environment set up on them so I don't need additional packages.

Regarding the code, I have started tracking the .level files and the CEGUI layout file in the media directory. This will allow me to mess with the level file format as I push forward the development branch and allow other people to check out the latest updates without us having to push a new ~15 mb media pack when all that has changed is a ~20k level (and of that 20k only 2 or 2 lines might be changed). This avoids cluttering the git repo with 100's of megabytes of .mesh files, while still allowing the most critical parts to be tracked.

-Buck

[andrewbuck]

I made a significant improvement to speed on the creature AI thread. There is a function called GameMap::path() which returns the shortest path between two given tiles. The algorithm uses an A* search algorithm, which is very fast but performs very poorly if you ask for a path between two tiles where there is no valid path and the start of the path is in a big open area. This makes the Creature::getReachableEnemies() function perform very poorly if a creature can see an enemy but cannot reach it (like when they are across lava, etc).

In order to solve this I introduced a function called GameMap::walkablePathExists() which is a very quick way to check if a a creature could walk from from one tile to another. I made the path() function call this whenever it is asked for a walkable path and the speedup is quite significant. By avoiding calling the A* search on a non-existent path, the call is limited to exactly the cases where A* performs well. The downside to running this is that a flood fill algorithm must be called on a tile whenever its "passability" changes (i.e. when a tile changes from being filled in to dug out). The map must also be flooded when it is loaded but that is quick. All in all, the benefits far outweigh the costs and the game runs signifigantly faster. Whereas before my dual core computer could barely do the AI calculations at 1 turn per second, now it can do them at ~12 turns per second.

-Buck

[svenskmand]

Uh nice, speed ups are always good

[andrewbuck]

I got a new windows release built and uploaded to sourceforge (version 0.3.8 Executable_2010-03-13.zip). You can just unzip it to a folder with the dll's and the media already there (or over an existing install). Make sure to unzip Executable_2010-03-13.zip last because it overwrites some files in the media directory.

-Buck

[Bodsda]

Latest code upload improves the output of the ls command, making it readable now

Also a new command has been added, ls levels. This will display all the level files in ./Media/levels/ - It should check that the file names match the pattern '.level' but do not match the pattern '.level.' - so if anyone sees any behavior on the contrary, please let me know. These updates are currently only available in the Linux build.

Bodsda

[andrewbuck]

I just committed a commit to sourceforge (and also pulled master up to the current development version) which splits the Creature class into to classes: Creature and CreatureClass. The CreatureClass class is responsible for storing class specific things like moveSpeed, digRate, maxHP, etc. The regular Creature class has been made a child class of CreatureClass and thus inherits all the datamembers which were previously directly included in the class Creature.

Although this seems like a meaningless change, and it has no effect on the gameplay, it is a much better design from the standpoint of code maintainability. This will make it significantly easier to change the "class descriptions" section of the level file format (as well as the associated network protocols, terminal commands, etc) in the future since the CreatureClass class can now overload its own version of the << operator like all the other classes.

-Buck

[andrewbuck]

I got another commit pushed to sourceforge a little bit ago, this one brings about a major improvement in the reliability of the game. Previously, when I deleted creatures from the map after they died I just waited until the next turn to delete them hoping that this would be long enough for the other running threads (the rendering thread, etc) to have purged all their references to the creature. However at high game speeds (setting the turns per second to 5 or 6) the next turn would sometimes occur before the other threads got through their processing. I have added a pseudo reference counting system protected by semaphores to guarantee that creatures queued for deletion on a given turn are not deleted until a turn is retired. A turn cannot be retired until its reference counter drops to zero. There are a couple more places where the reference counter should be incremented/decremented but the most egregious problems have been fixed. As a test of this I beat the demo level twice at 6 turns per second (it took me about 1500 turns to beat it each time) without the game crashing.

Also the problem of randomly disappearing creatures and creatures you cannot pick up seems to have been solved by some changes I made a couple days ago. Hopefully this weekend I will have some time to get a new windows binary built using the latest codebase. This, combined with Skorpio's reworking of the tiles, should make for a pretty cool demo.

-Buck

[charlie]

Nice then plan the next release release then plan then release!

[andrewbuck]

Another new commit pushed tonight, this one implements basic support for adding rooms (in both the map editor and in the game itself). Currently you can only add the "quarters" room as that is the only button that has been set up, but now that the framework is in place it should be easy to make it so you can add all the other room types (treasury, foodery, training room, etc). The rooms also don't cost anything to build at this point, I don't plan to add that until the treasury is functional. When you are in the map editor, rooms can be placed on any empty "claimed" tiles however you cannot set their color yet; in the game itself you can only add rooms to empty, claimed tiles which match your color.

Releated to this is a new request for Skorpio (and anyone else with blender skills). Currently only the quarters has a mesh and that one is very basic, just a square tile with a pink square surrounding it. We will need meshes for the other room types, even if they are just simple "placeholder" meshes for now (e.g. a square with a T on it for treasury). I plan to do a bit of reworking of the room code in the next few days to make it a bit more flexible, then I will be implementing the actual code for the rooms (making the treasury count the gold stored in it, etc). I plan to model this after the design I used for the goal class so it should be fairly easy to implement that.

I had planned to compile a new windows binary this previous weekend but that never got done. Now with this development on the room code I will probably put off the next binary release until this code is fully up and running so people can test it out. I hope to have the next binary release out sometime next weekend.

EDIT: see here for a thread discussing the particulars of the room design. Please make any comments regarding room looks and mesh design there and keep responses in this thread pertaining to the code itself.

-Buck

[andrewbuck]

A few more commits tonight, all of them fixing minor memory leaks as well as removing some deprecated semaphore code which was made unnecessary by the "reference counting" system I added last week.

-Buck

[andrewbuck]

Another major commit tonight. Last night I used the program called valgrind to chase down and fix a few minor memory leaks. Tonight I used valgrind to fix approximately 50 potential race conditions in the code. A race condition occurs when two or more threads try to operate on the same piece of data without enforcing a locking mechanism to ensure they don't garble the data they are working on. There was really only about 10 or so peices of data that had race conditions associated with them but approximately 50 places total where this data was accessed.

This appears to have fixed a known crash when you used the brush tool to create new tiles on the edge of the map, but I'm not sure yet; the crash only happened once in a while before so I may not have tested it thouroughly enough to make it happen tonight. There were probably several other known/unknown bugs and random crashes that this commit also fixes since race conditions lead to unpredictable behavior.

-Buck

[svenskmand]

Nice , memory leaks and race conditions are bad for us

[andrewbuck]

Another couple of commits added today, both relating to the room code. The first makes the Room class a base class to allow for polymorphic subclasses such as RoomQuarters and RoomTreasury (currently the only two implemented so far). This allows the subclasses to carry out functions which are specific to them (such as depositing gold in a treasury) while still allowing them to delegate generic stuff that all rooms do to the base Room class (creating meshes for the tiles covered by the room, etc).

Using this new polymorphic system I added a class called RoomTreasury which implements the basic functionality of the treasury. I also added the relevant code to the creature AI to make workers carry the gold they mine to a treasury. The code is in its early stages but it does seem to work.

Due to this added code I will need a couple meshes added to the media pack. The first is Treasury.mesh which of course is the mesh for the treasury tiles (see the link a couple posts up for the discussion of how these should work). I would also like to have the GoldBag.mesh and GoldChest.mesh added if possible so that I can implement those to show when there is gold laying on the ground and gold stored in treasuries. It might be a while before I get the code for the bag and chest implemented in the game engine but I would like to have these meshes ready when I do. @Skorpio, I have made some meshes for these two, although they could both use some improvement, I think they were in the .blend files I sent to you, if not they should be on the wiki under the "Items" section.

-Buck

[andrewbuck]

In conjunction with the previous commits which added support for the treasury, I have added support for the goal called MineNGold. In the "Test.level", which is the default level that loads when you start the game, there is now a requirement that you mine 2500 gold. Currently the goal is considered met if your treasuries currently contain more than 2500 gold and unmet otherwise. This means that if you meet the goal and then "un-meet" it by spending the gold you mined it will revert to the unMet state. I plan to fix this in the future so that it stays met once you have met it regardless of whether you spend the money or not. I have not done so yet because there are a couple ways I could implement this and I am in the process of evaluating the pros and cons of each.

The commits today really demonstrate the flexibility and extensibility of the codebase. The code which made the creatures dig out gold and carry it to the treasuries was approximately 100 lines, with the code for the treasury itself being about 150 lines. The code for this new goal was ~75 lines, this means that the design of the current codebase can be easily extended to include a multitude of goals, etc, without becoming unmanageable (for comparison the entire game is now about 13,000 lines of code, whereas the linux kernel is ~9 million).

-Buck

[charlie]

Good to hear a bit of pride on display there. Keep up the good work!

[TheAncientGoat]

Darnit, I so wish the game would work for me :\

[andrewbuck]

The next release I plan to just do a whole game zip file (dll, media, and exe all rolled into one). That should take care of you if you have a windows machine around to try it. If you are on linux you should be able to build and run the code in the git repo, if you have any problems with that make a post in the "Installation experiences" thread and I will see if I can get you going. I also have skype (username andrewbuck40) if you want to try to talk on there to work out the build issues.

-Buck

[TheAncientGoat]

I already did post my issues in the installation experiences, man, and tried all the recommended solutions, but none of it worked.

[andrewbuck]

Another code commit just pushed to sourceforge. This one makes it so that adding rooms actually costs money. The gold required for the creation of your room will be withdrawn from your treasuries (you do not need all the gold in a single treasury you just need to have enough in the sum of all your treasuries). If there is not enough gold in the treasury the room will not be created.

-Buck