State of the Code

[oln]

Was helping svenskmand with building the game today, he also got the issue where CEGUI doesn't find layout/font etc. files, for some reason it's not looking in the resource folders. Need to find out what's causing this.

[svenskmand]

Also when you press the mouse to dig an area, the game slows down allot, it seems to be doing something it is not supposed to do.

Another thing, the mouse in the game also moves weird, it is like the mouse somethings jumps from one tile to another. And somethings the mouse gets stuck at some place at the screen, and cannot move in some direction anymore, but it works in the opposite directions.

Was helping svenskmand with building the game today, he also got the issue where CEGUI doesn't find layout/font etc. files, for some reason it's not looking in the resource folders. Need to find out what's causing this.

I will see if I can make a PPA for OD, now that I have our stuff compiling - and with sound, it is awesome

[andrewbuck]

Also when you press the mouse to dig an area, the game slows down allot, it seems to be doing something it is not supposed to do.

Another thing, the mouse in the game also moves weird, it is like the mouse somethings jumps from one tile to another. And somethings the mouse gets stuck at some place at the screen, and cannot move in some direction anymore, but it works in the opposite directions.

I will have to look into the digging issue, there shouldn't be a problem there but I can check into it (it may just be the creatures trying to determine what tiles to dig out). I think that the issue with the mouse pointing to different tiles has to do with the way OGRE is returning results from a ray scene query. You can do a more sophisticated search for tiles which looks at the individual mesh polygons but it is obviously more expensive to do this. The issue with the mouse getting stuck is something else I will have to look into.

Good to hear you are working on a PPA, that would make it much easier to distribute the game. We should consider doing a separate package for the media stuff which is a dependency on the main OD package. The media could even be split into several sub-packages (sounds, meshes, textures, etc) which can be updated individually. That way updates to some or all of the components can allow people to stay more in line with the cutting edge development with much less for them to download.

As far as the code, I have been working on tweaking the way the vision algorithms work. Previously this has been done in the creature class but I have decided to move it into the GameMap class so that traps and anything else can call it. More significantly I have found a much more efficient way of calculating which tiles are visible from a given tile. I have this about halfway implemented and hope to finish it soon. Once this is done I can call the visible tiles routine from the cannon's doUpkeep() routine and shoot at any enemy targets seen there.

-Buck

[svenskmand]

Good to hear you are working on a PPA, that would make it much easier to distribute the game. We should consider doing a separate package for the media stuff which is a dependency on the main OD package. The media could even be split into several sub-packages (sounds, meshes, textures, etc) which can be updated individually. That way updates to some or all of the components can allow people to stay more in line with the cutting edge development with much less for them to download.

That is a possibility. But I will just make a single package as a start, I do not know if the extra hassle is worth it in the long run.

[andrewbuck]

I got the updated vision algorithm working finally. I am going to push the new code to sourceforge in the next few minutes. After switching to this new system for vision calculations, my computer which previously could run the game at a maximum of 3 turns per second can now run at 5 turns per second. There are also some improvements I can still make to the algorithm which will speed it up more but it is already signifigantly faster. Also, now that I have the vision code moved to the game map it will be easier to get the traps working.

-Buck

[andrewbuck]

I just committed some more work on the vision algorithm. Now when the game loads it precomputes a lookup table of the order in which you list tiles for the vision algorithm. This speeds up the already improved vision algorithm that my previous post was about (the game now runs at 7 turns per second on my machine). The reason for the extra speedup comes from using this table instead of listing/sorting the tiles like I was doing before. The sorting routine was actually a fairly large component of the whole process but since the order of the tiles always ends up being the same anyway it is much faster to do it once at load time and then just peek at the result.

The algorithm can also be sped up quite a bit more because the TileCoordinateMap where the lookups are being done also contains information on the direction to all the tiles in it. Currently the vision algorithm is still doing it the hard way and generating this information everytime it is needed (which is tens of thousands of times in a typical game). It should be fairly easy to leverage these lookups to further improve the efficiency.

-Buck

[svenskmand]

Super nice, good work Andrew So when will we have a new release with all this stuff added? I hope aim at getting the PPA ready for the next release It could contain a fully working trap, the music we now have, digging sounds for the Kobolds, and rockfalling sound when a tile us dug out, and all the improvements you have made. Actually it will be a pretty huge release, allot have already been done

[andrewbuck]

The next release really could be put together any time. I have been trying to get a build environment set up on windows but have been unable to get it working. Once this is done then we can release anytime, it may take me a while though since I focus more on writing the code than packaging it. Also, I know very little about visual studio so if someone with more experience can get it working that would be cool, too.

-Buck

[svenskmand]

I will let you know once I have the Ubuntu packaging working, and have set up the PPA. Regarding the Visual Studio stuff I also have no experience with that software, so if someone else with more knowledge could set it up that would be brilliant, once we have it set up and running I can be the one clicking the button to make the binaries to distribute, I do not mind that.

[andrewbuck]

So I think I finally have the vision system working. There seemed to be a bug in the code where creatures would lose their vision when they got close to walls but I have it resolved now and the vision system is at least mostly correct. There are still a few transient tiles that appear as visible which really shouldn't be but the error is intermittent and only at very large distances which don't typically matter anyway. I have a rough idea what the problem so hopefully it should be fixed soon.

Now that i have the vision system working well enough to allow the game to function again I am going to resume work on the traps. I hope to have them doing damage to creatures by the end of the night. Once that is happening I will look at animating the trap firing as well so you can see when the thing is hitting your creatures.

-Buck

[svenskmand]

Very good

[andrewbuck]

I have the cannon doing damage to enemy creatures and rooms now. After it is created or loaded it has to wait its reload time (5 turns) before it can fire. Once it is loaded it checks every turn to see if there are enemy creatures visible to it. If there are it randomly picks one and shoots it doing some amount of damage. After it has fired it begins reloading and will be ready to fire again in 5 turns.

Of course you can't see any of this happening yet unless you look at the program output after you close the game. I think I will use a system similar to the RoomObjects but I haven't decided yet. This will be the same visual mechanism that wizards and other creatures which use ranged attacks will use. What I am thinking is that the object will be created at some source point and will fly toward some destination point (which is specified when the missile is created). Once the missile arrives at the destination it can (optionally) perform some animation and then destroy itself.

-Buck

[andrewbuck]

I started the implementation of the cannonball with a new class called MissileObject (code is on sourceforge now). These missile objects are similar to the RoomObjects created before but they will soon be subclasses of a base class called AnimableObject. An AnimableObject will be one which has both a "walkQueue" and one or more animations that should be carried out at different times. Currently the creature class has a special bit of code in the ExampleFrameListener class which does this. When the AnimableObject framework is set up this code will be modified to handle the generic AnimableObject framework so it will move both Creatures and MissileObjects with the same code.

-Buck

[andrewbuck]

I just pushed more code to sourceforge which implements the AnimableObject (now actually called AnimatedObject). The new code subclasses this for the Creatures and the MissileObjects and actually moves the creatures through the new AnimatedObject interface. This should (and does) allow the MissileObjects to be moved just like the Creatures however when I add a destination to the missile's walk queue the program segfaults. I have the line which does this commented out for now so the current git build is playable (as I always try to keep it) but the cannonball still will just sit there when it is created.

-Buck

[andrewbuck]

I got the bug which prevented the cannonball from working properly fixed so now they will fly towards their target. The motion seems to be not quite right so it will require some more debugging but it functions now so I have begun looking at other things.

I have started implementing the code for the creature job in the level file loading/saving. The creature jobs are things like BasicWorker, StrongFighter, WeakBuilder, etc. The code to load and save the job to the level file is now working and I will next be adding functions to allow the creature AI to use this to change how the creatures behave. My initial thought is since almost everything we have right now is a BasicWorker, WeakFighter, or StrongFighter, I will work on developing the AI code for these first. I may also look into spellcasters since they would have a ranged weapon that I could implement with the newly developed code for the cannonball (the MissileObject class).

I want to leave the WeakFighters functioning like the fighters do right now and patrol the border area between the claimed and unclaimed region. The StrongFighters will be programmed to do the same thing, however they will patrol farther out than the weak fighters and will be less likely to follow the kobolds. The workers will continue to function like they do now. Let me know if you think there are other kinds of things I should add, either to the AI code, or just in general.

-Buck

[andrewbuck]

I have made quite a few minor tweaks to the creature AI fixing several bugs and improving the performance by making creatures only compute their full field of vision once every few turns. This improves the AI speed quite a bit but it leads to creatures seeing something way off in the distance, starting to walk there, and then "forgetting" about it if they do not see it on the next turn because their field of vision is smaller again. I need to implement some sort of short term memory of objectives that have been seen in the last 10 turns or so.

-Buck

[svenskmand]

I have a feature request: Will it be possible to record replays of games? Like in quake/unreal and starcraft? I would be a really nice feature for gamers, but also for debugging later on.

[andrewbuck]

It would be possible, it would take a while to implement though. Basically you need a way of recording the game state and then recording changes to that state. It would be nice but ultimately I think it might be more trouble to implement it and more potential bugs created by trying to make it work than you would be able to fix by using it. There are just too many calculations going on at once to realistically store them all.

-Buck

[svenskmand]

Ok, then how about a replay that is not for debugging, but only for watching you played games? We only need to store creature movement paths, fights and diggings, along with room/trap/door builds and keeper spellcasting. It would be a nice feature to have, but yes the game has to be prepared for it at a early stage, which is why I am asking, the question is then just if we are already to late.

Because the game is turnbased I actually think it will make life much easier for us should we decide to implement replays, because we only need to save state for each turn. For creature movements we can save the tiles that creatures are currently at, likewise for rooms we can for each tile save if there at turn x is build a room, and then when it is destroyed at time y we save that information, and nothing in between for the rooms, so we save build and destroy events. We can use the same scheme for doors and traps, and when they trigger they have a trigger point at time x. For fighting we could for each creature store the id of the enemy creature it hits and the damage it does, that way a creature has a list of all hits it has ever made in the game. The keeper movement we can also base on the center tile in his screen to capture his viewpoint, so we store that for each turn, and we also store a pickup time x and drop time y along with the identity of the creature, we know where it is picked up from and dropped to from the positions of the creature a time x and y.

[Bodsda]

Ok, then how about a replay that is not for debugging, but only for watching you played games? We only need to store creature movement paths, fights and diggings, along with room/trap/door builds and keeper spellcasting. It would be a nice feature to have, but yes the game has to be prepared for it at a early stage, which is why I am asking, the question is then just if we are already to late.

Because the game is turnbased I actually think it will make life much easier for us should we decide to implement replays, because we only need to save state for each turn. For creature movements we can save the tiles that creatures are currently at, likewise for rooms we can for each tile save if there at turn x is build a room, and then when it is destroyed at time y we save that information, and nothing in between for the rooms, so we save build and destroy events. We can use the same scheme for doors and traps, and when they trigger they have a trigger point at time x. For fighting we could for each creature store the id of the enemy creature it hits and the damage it does, that way a creature has a list of all hits it has ever made in the game. The keeper movement we can also base on the center tile in his screen to capture his viewpoint, so we store that for each turn, and we also store a pickup time x and drop time y along with the identity of the creature, we know where it is picked up from and dropped to from the positions of the creature a time x and y.

I agree that having a replay system would be extremely benficial, both during main development, and after, but I think your idea here would not work. There are too many things that could get missed, and everytime a new feature is added, it would have to be implemented into the replay structure.

I havent done any research on this, but as ogre is a graphics engine, can it not create an avi file or equivalent automatically? Or perhaps there is an external application we can integrate to capture window output?

Bodsda

[svenskmand]

I do not see why there should be a problem with by suggestion? Of course new features need to be implemented in the replay function, but if we are going to have the replay function it is better to consider what to do now, and implement it now, rather than after the game is done or has been developed too much such that certain structures and ways of doing stuff have stuck to much in the code, and make it difficult to implement the replay function.

If you just want to record movies of the game there is special software around to do that. But a replay system will have so much more functionality, you can interact and fly around the dungeon seeing each player build his dungeon, check creature, room, trap, door and spell stats while you watch.

[andrewbuck]

What you are suggesting (saving just the creature positions and door events, etc) wouldn't be all that difficult to implement. Something like that could be done eventually but it will be one of the last things to be coded since the focus right now is on getting a playable game. The structure of the code makes it fairly easy to add this later on so that should be no problem. I don't think it makes sense to worry too much about the design of the replay system now though. The code is currently (and will continue to be) structured in such a way that the system you suggest (at least the recording of the data) will be possible to implement whenever. The tricky bit is the playback, but that is not necessarily a showstopper.

-Buck

[svenskmand]

Ok, that was all I wanted to know. The reason I asked is that undo functions and the like which needs to store state, like the replay function does, often shoots people in the back if they do not implement it or consider how to do it from the early beginning of the development.

[andrewbuck]

Yeah, it is good to be thinking about it early on.

I got some more work done on the creature AI, mostly just bug fixes but the game proceeds a bit faster now. Workers now gain experience from both digging and claiming tiles. When they gain levels the amount they dig per turn as well as the amount they claim per turn increases. At about level 10 or so, the creatures will be claiming more than 1.0 tiles per turn. This extra amount will "spill over" into neighboring tiles so that they get partially claimed as well. The amount that spills over is pretty small so they would need to be doing a lot more than 1.0 per turn to see a noticeable effect but it should make the game proceed much more quicly once the workers level up to level 30 or 40. I think I may make the spillover a bit more effective than it is right now and then adjust the workers claim rates accordingly but it seems to work pretty well right now.

Currently the digging does not "spill over" at all but I may implement that in the future. The next thing I plan to work on is getting the creatures to not walk through the dungeon temple, the portal, and other assorted room objects. This should be pretty easy to implement so I hope to have this done soon but no guarantees.

-Buck

[oln]

Pushed a commit that has sounds for dirt being dug out, the mouse fix, and an attack sound that is currently a sword hit sound for all creatures.
Uses the Sword folder and the RocksFalling folder in SVN, which are in the "Sound" folder.
They should be put in Media/sounds in the OD root folder.

Regarding the AI, kobold AI's doesn't seem to prioritise digging as often as they should, they run off and start claiming tiles instead a lot of the time.