State of the Code

[andrewbuck]

There was a huge thread in the old forum (~130 posts if I recall correctly) which was a thread which I used to make announcements on the progress of the codebase and others would comment accordingly. This thread is meant to be a continuation of that thread, so here goes.

I thought the idea of making a "demo" level with a couple simple goals (kill some enemies, dig out some tiles, etc) was a good one so I started implementing that idea. I have gotten the creature combat AI at least functioning (thanks to Bodsda for his suggestions) and I have also tweaked a couple more things relating to the combat AI to make it a bit more sane.

I have also implemented a polymorphic virtual base class called "Goal". The goal class cannot be instantiated directly (since it has pure virtual methods) but is meant to serve as an interface for other goal classes to interact with the rest of the game. The first of these classes is, I believe, created in the true spirit of the game and is called "GoalKillAllEnemies". Although it is not yet fully functional, I have already added support to the level loading/saving routines to read in this class and it should be fairly simple to actually make it function (most of the code is already written, it is just not called yet). Once this is done (and one or two other minor fixes) we will have a simple "elimination" game type to use as a demo. The game engine will simply declare the last person who has surviving creatures the winner (actually the first player to remove all the goals from their "todo" list is the winner, but currently there is only the one goal on that list). It should be fairly easy to create more goal classes, of which one or more can be added to a level file to make a game scenario.

Something I could use help on currently would be the creation of a goal list. The list should contain only items which the game can algorithmically determine (for example I can check if KillAllEnenmies succeeded by checking the color of every creature in the game and seeing if they are all the same color). Some suggestions that have been mentioned or I have thought of to get you started:

* KillNEnemies - takes an argument N, which is a number of enemy creatures which must be killed to satisfy the goal.
* DigOutNTiles - takes an argument N, which is a number of tile sqares which must be dug out to satisfy the goal.
* ClaimNTiles - takes an argument N, which is a number of tile sqares which must be claimed to satisfy the goal.

It would be nice to have a list of 10 or so of these so we could build a sort of "tutorial campaign" to introduce new players to how the game works.

-Buck

[charlie]

* SaveXGold - fill coffers with X amount of gold
* SurviveNDays
* CreateNCreatureX - two arguments, the number to create and the type of creature
* BeforeNDays - complete all other goals before N days expires

[Bodsda]

There was a huge thread in the old forum (~130 posts if I recall correctly) which was a thread which I used to make announcements on the progress of the codebase and others would comment accordingly. This thread is meant to be a continuation of that thread, so here goes.

I thought the idea of making a "demo" level with a couple simple goals (kill some enemies, dig out some tiles, etc) was a good one so I started implementing that idea. I have gotten the creature combat AI at least functioning (thanks to Bodsda for his suggestions) and I have also tweaked a couple more things relating to the combat AI to make it a bit more sane.

I have also implemented a polymorphic virtual base class called "Goal". The goal class cannot be instantiated directly (since it has pure virtual methods) but is meant to serve as an interface for other goal classes to interact with the rest of the game. The first of these classes is, I believe, created in the true spirit of the game and is called "GoalKillAllEnemies". Although it is not yet fully functional, I have already added support to the level loading/saving routines to read in this class and it should be fairly simple to actually make it function (most of the code is already written, it is just not called yet). Once this is done (and one or two other minor fixes) we will have a simple "elimination" game type to use as a demo. The game engine will simply declare the last person who has surviving creatures the winner (actually the first player to remove all the goals from their "todo" list is the winner, but currently there is only the one goal on that list). It should be fairly easy to create more goal classes, of which one or more can be added to a level file to make a game scenario.

Something I could use help on currently would be the creation of a goal list. The list should contain only items which the game can algorithmically determine (for example I can check if KillAllEnenmies succeeded by checking the color of every creature in the game and seeing if they are all the same color). Some suggestions that have been mentioned or I have thought of to get you started:

* KillNEnemies - takes an argument N, which is a number of enemy creatures which must be killed to satisfy the goal.
* DigOutNTiles - takes an argument N, which is a number of tile sqares which must be dug out to satisfy the goal.
* ClaimNTiles - takes an argument N, which is a number of tile sqares which must be claimed to satisfy the goal.

It would be nice to have a list of 10 or so of these so we could build a sort of "tutorial campaign" to introduce new players to how the game works.

-Buck

ProtectCreatureForNtime - If creature of another colour (not yours or the enemy) is alive after N time, you win
DestroyKeeperCountN - Complete when: CurrentKeeperCount = (StartKeeperCount - N)
ProtectAllyN - Protect ally of colour N - You lose if colour N dies
AttractNCreatures - Complete when: CurrentCreatureCount = (StartCreatureCount + N)

[andrewbuck]

Well, OpenDungeons is now officially a game. I got the goal framework implemented and GoalKillAllEnemies now works as expected. Since the OpenDungeons engine can now tell whether or not someone has actually completed the objectives assigned to them I am officially re-designating it from an "activity" to a full fledged "game", albeit a simple one.

The design of the goal framework makes it very easy to "explain" what a given goal means to the game engine. Once this is done the engine can read in the goal from level files, assign it to each of the seats, and monitor the status of whether it has been met by a given seat or not.

I also added a Goals page to the wiki where I have copied the goals you all provided in this thread (I was impressed with how quickly the list came together). I will also document how the goal framework works there when I get a chance.

As an aside, I should probably explain what I mean by seats. When a level file is loaded, one of the first thing loaded onto the GameMap is the seats. Each seat represents one dungeon keeper on the map. When a player joins the game they currently sit down in an empty seat, to play as that dungeon keeper. Although I haven't implemented it yet it should be trivial to allow more than one player to sit in a given seat, allowing two or more players to play as the same dungeon keeper (i.e. their share gold and mana and a dungeon heart, they can both pick up the same creatures, build rooms for that side, etc). Note that this is different from allying yourself (also not yet implemented) with another keeper where both players have separate dungeon hearts, cannot pick up eachother's creatures, etc.

-Buck

[svenskmand]

...
Although I haven't implemented it yet it should be trivial to allow more than one player to sit in a given seat, allowing two or more players to play as the same dungeon keeper (i.e. their share gold and mana and a dungeon heart, they can both pick up the same creatures, build rooms for that side, etc). Note that this is different from allying yourself (also not yet implemented) with another keeper where both players have separate dungeon hearts, cannot pick up eachother's creatures, etc.

-Buck

This sounds interesting

[Skorpio]

You've forgotten the kidnap the princess goal. I think some kind of capture the flag or reverse capture the flag could be fun. And what about king of the hill?

[andrewbuck]

I like the idea of defending/imprisoning/torturing a given creature as a goal. As for the king of the hill, we could do something like maintain a certain amount of claimed land, or maintain the most claimed land of any player. This second option actually leads me to something I should add to the goal classes, currently they provide a criteria to indicate when they are met, they should also provide a criteria to determine when they are unmet after having previously been met.

-Buck

[andrewbuck]

I added the goal "ProtectCreature" to the codebase. Unlike the KillAllEnemies goal, ProtectCreature starts out in the "met" state and will move to the state "unmet" if the creature is no longer alive. This demonstrates that the goal framework is capable of properly handling both possible transitions between the different goal states (met and unmet). It also demonstrates the simplicity with which new goal types can be added to the game engine. The two goal types (KillAllEnemies and ProtectCreature) are each ~100 lines of code in the engine, however about 80 or so of these lines are the same between the classes, the only differing code is the code to detect whether the goal is met or not.

In the future I also plan to add another state called "failed" which goals can also exist in. This state will behave basically the same as the other two, however once a goal has entered the state "failed" it will no longer be checked to see if it is met or not and cannot ever be moved back to one of the other two states (met or unmet). This will be useful for things like the BeforeNDays goal. It will start in the unmet state, if all the goals are cleared before the due date it will move to the completed state, if not it will move to the failed state. If any goals are moved to the failed state the player will be given the option of quitting, since success will now be impossible.

Finally, I fixed a minor bug which cased an infinite loop in the creature AI. If a worker was on the other side of the little lava section in the current test map, they would be able to see tiles they should try to claim, however they would not be able to find a path to one so they would get stuck in an infinite loop trying to find a valid path.

-Buck

[Andrew]

Can you have both ProtectCreature and KillAllEnemies on the same level? You might want to create a level where the goal is to kill the enemies while still keeping one of your creatures alive.

[andrewbuck]

Yes, the level file currently contains a section of "goals for all seats", which is the list of goals any given player must complete to win the level. The list can be as long as you like and can contain any combination of goals (e.g. KillAllCreatures + ProtectCreature Knight_001 + ProtectCreature Kobold_003). In the future I plan to add seat specific goal lists as well so you can have an asymmetric game. For example one player might be trying to satisfy KillAllEnemies, whereas the other player might be working on SurviveNTurns, where N = 500.

It will also be set up as described in the Map Design thread where the success of one goal can add other goals to your list of things to do. So on a given map you might be able to do either (KillAllEnemies) or (ProtectCreature Knight_001 + SurviveNTurns N=250). Whichever set of goals you complete first makes you a winner since your goal list is now empty. Hope this all makes sense.

I think this setup, coupled with allowing multiple players to share a given seat, and having no limitations on map size/shape should make for almost limitless campaign levels which could be possible.

-Buck

[andrewj]

I think the terms met/unmet/failed are not very clear. Instead I suggest: completed/trying/failed.

Perhaps you could have a goal classes like CompleteAll and CompleteAny, which could store the sub-goals and handle the success/failure cases as you'd expect. (Dunno if this makes sense in your codebase, just something which came to mind).

[andrewbuck]

Internally in the code I am going to stick with met/unmet/failed, however what the user sees can of course be labeled however we want. As for the CompleteAll and CompleteAny, I think that is an interesting idea. They would actually be quite easy to to implement too. I was trying to think of a good way to specify AND and OR operations on the goals and that will work excellently.

-Buck

[svenskmand]

Regarding getting more coders, I just found this project maybe we could convince the guy behind it to join our project. His project description says 'OpenSource Real-Time-Strategy game in the flavor of good old "Dungeon Keeper"', so if he does not like the factions part he can always fork/branch off from the project at some point, but the basic engine should be the same. In the old forum we also talk about implementing the Old dungeon keeper first, before we completed the factions. This could also be a convincing argument to get him aboard. His username on sourceforge is lutz_ifer.

[andrewbuck]

The project you linked to had its last SVN commits in December of 2008 so the developer listed is likely not even following the project any more but it's worth a shot. Regarding the factions, I don't think that would be a problem for him since the effect of factions on the codebase is pretty small anyway and you could easily make a packaging of the game that had models/rooms for only one faction anyway.

-Buck

[Skorpio]

There's also this guy: viewtopic.php?f=20&t=204

Apparently there are quite a lot of people interested in a new Dungeon Keeper game, we just have to bring everybody together.

[svenskmand]

I have now mailed lutz_ifer through sourceforge, hopefully he will come look at the wiki or this forum

[andrewbuck]

I got a couple more commits pushed to the git repository on sourceforge tonight. The first removes all of the stuff under the Media/ directory from being tracked by git; this is because we are now switching over to using the zip files for the game art rather than tracking it in git. Because of this when you now do a "git clone" of the repo on sourceforge you will also need to download and unpack the latest media pack from sourceforge as well before you can play the game.

The more interesting note is that I now have working code for reading in lights from the level files. This is much better than the original system, where the lights were created in 4 or so fixed locations by the game engine. If you tried to load a map which was bigger than the area covered by the default lights you would be unable to see it. Also, all levels were lit exactly the same, causing the level to look pretty boring. The new lighting system, combined with Skorpio's work on redoing the material scripts for the models, makes the game much more pleasant looking. It also looks like he may have gotten normal mapping on some of the tile textures to work although this could just be a remnant of removing the double rendering blocks on the material scripts.

Currently the updated lighting code is only available via the development branch on git so if you want to see how it works you will have to pull the latest code from git and build the game yourself. I set up a windows build environment on a computer I borrowed over the weekend and I hope to get a new windows build posted to sourceforge fairly soon here (although the current build of the game I made on the windows box is crashing upon loading, but I think I might be able to fix it).

-Buck

[Skorpio]

It also looks like he may have gotten normal mapping on some of the tile textures to work although this could just be a remnant of removing the double rendering blocks on the material scripts.
-Buck

No I haven't included a normal map yet, I just added a new dirt texture. Normal maps are a "bit" more complicated than other materials: http://www.ogre3d.org/wiki/index.php/Ma ... umpMapping

No idea how to make them work, but I have generated a normal map for the dirt already if you wanna test it.

[andrewbuck]

I will probably just be focusing on the code for a while yet here. I got the game to build successfully on windows so I hope to put out a release of the latest binary on sourceforge. That won't be until this evening though (6 or 7 US central time GMT-6).

-Buck

[andrewbuck]

I guess the release of the new version is taking longer to put together than I thought. I am trying to trim down the list of necessary dll's and it is proving to be more difficult than I had originally intended.

On the bright side, however, the delay has given me enough time to add code allowing you to drag around the lights in the map editor. When you load the game the lights are surrounded by a mesh (currently just a blue cube) to show where they are. You can drag them around to change the x-y coordinates on the map, but to change the z coordinate, brightness, etc you will still have to edit the level file by hand. When you start a game with the host or connect commands the light meshes will be destroyed but the lights themselves will survive.

For the light mesh, we may want to do something more than just a blue cube. I just threw that together for testing purposes. Whatever we end up using I will need Skorpio to add the Light.mesh to the media pack (although there is no hurry to get this done until I get the latest build posted to sourceforge). I could send you the .blend file I used but I don't think it is even worth doing since it is just a cube. The only thing I would suggest for whatever mesh you create is that it should have the "emit" slider on the material tab turned up (probably about 50%). This is because the actual light is inside this mesh (at the mesh's pink center point dot) and so it will not light up the mesh itself. Therefore if you only have one light in the scene no light will be illuminating the light mesh itself making it pretty hard to see.

I will also have to send the latest map files to Skorpio since the level file format has changed a bit to include lights and comments. The format of the creature blocks, etc, themselves have not changed so you should be able to copy in your existing list of creatures, although some of them are standing where there are walls in my version. Unfortunately the Test.level file included in the 0.3.4 release had all the walls knocked flat. I will try to get on IRC today to send those files to you Skorpio.

-Buck

[Skorpio]

You can send me the files via e-mail (I hope you still have my address). I think the maximum for attachments was 25mb.

[andrewbuck]

Message sent. By the way, I don't check that e-mail address often (rarely in fact) so if you want to respond you should at least post a short message on here letting me know, or just post the full response here.

-Buck

[andrewbuck]

Well, tonight was a somewhat interesting night. I made some changes which begin the integration of the CEGUI overlay into the actual game engine, as well as beginning work on the "upkeep" round of the GameMap::doTurn() method. The upkeep round currently just adds 50 mana per turn to any seats with players in them. This is reflected in the CEGUI overlay which now properly shows the mana for you (actually the mana for the seat you are sitting in since keeper mana is a seat property rather than a player property).

In the process of making these changes, however, I introduced some kind of a bug which would screw up the rendering of the scene. After doing a bit of wizardry with git I was able to track the bug down and get rid of it, but not without quite a bit of trial and error. Ultimately I don't even know what code it really was that I reverted that caused the problem, however I have gotten rid of it without undoing the changes I described above regarding CEGUI and the upkeep round.

EDIT: I also just noticed that since I have added the sourceforge logo to the bottom of our wiki pages, our sourceforge project ranking has gone from ~1000 to 625. We should continue to climb even higher too since the "logo hits" portion of the score is a 7 day total and we only have 1 day of logo hits contributing to this portion of the score. Details can be seen here and you can click on the dates on the left to see how the score was calculated for a given day. Maybe our high ranking will help attract some new people from the sourceforge community.

-Buck

[svenskmand]

602 Now

[andrewbuck]

Last night I got a couple more changes checked into git. The first is a series of modifications to the writeGameMapToFile() function. Now when a level file is saved the game automatically adds comments to the level file to show the file's format. The second change is several improvements to the creature AI for when they are in combat. It still isn't perfect however I have somewhat fixed the dancing issue. It turns out the idea I had for the algorithm was correct, however due to the way I coded it, the algorithm wasn't exactly carried out.

-Buck