State of the Code

[andrewbuck]

Well what the bed looks like would tell you what kind of creature owned it, but if you want to know specifically what creature owns it that could be implemented as well. We could do several things (and maybe more than one of these could be possible in the game):

* You could "middle click" on a creature to see its stats, one of which would be where it sleeps.
* You could middle click on a bed to see its stats, one of which would be what creature sleeps in it.
* Or maybe you could do either over the above two actions with a "mouse hover" over the given object instead of a middle click.

Any (or all) of these would be fine with me. Let me know if you hav any other mechanisms for showing it, or if you think these would be the way to go.

-Buck

[andrewbuck]

I just committed another revision to sourceforge which adds support for muti-tile beds. I currently have all of the creatures using the bed from opengameart and it is set to 1x2 tiles in size. The bed size is set in the CreatureClass section of the level file under the parameters bedDim1 and bedDim2. The game engine understands that it requires 1x2 tiles and so will not place it in a spot in a quarters where it will not properly fit. It also checks both possible rotations of the bed to see if one will fit when the other doesn't (i.e. making the bed take 2x1 tiles instead of 1x2).

-Buck

[andrewbuck]

So I've been away from the project for the last few days working on OpenStreetMap (openstreetmap.org if anyone is interested in checking it out, cool project), but I finally got back to coding on OD. I pushed a minor change to sourceforge a few minutes ago which fixes a minor bug in the way creatures look for rooms to sleep in. I also added code to make the workers randomly choose a tile in the treasury that they are trying to deposit into instead of just choosing the first tile. This makes them spread out the gold a bit more and will make the treasury look more interesting when we start getting more "gredations" of fullness meshes.

I was also thinking about adding some code to make gold deposited into the treasury "spill over" into the neighboring tiles and was wondering what you all would think of this. It would work this way: say you deposit 1000 gold on a tile in the middle of the treasury. Instead of just putting all 1000 in the tile you told it to it would put maybe 700 of it in that tile and then divvy up the remaining 300 gold among the neighboring treasury tiles. This would make the treasuries more interesting, otherwise basically all of the tiles will either be empty, filled with 1500 (the amount the kobolds carry) or full; i.e. you will rarely see the "small pile of gold" mesh used since creatures will usually deposit more than this at one time. It would be fairly easy to implement this in the code so that is no problem but I don't want to annoy people if they think it would look "broken" to do it this way.

-Buck

[svenskmand]

Let us try it, as it sounds cool

[andrewbuck]

I just committed another change to sourceforge which makes it so that when you add new quarters tiles next to an existing quarters the rooms are combined into a single room. Prior to this if you created a 10x10 quarters by clicking out one tile at a time, there would be no creatures that would put a bed there since what the creatures see are 100 individual quarters rooms, which are each 1x1 (which is too small for their 1x2 bed). Now if you do this the quarters will be combined together so that they form a bigger single room and the creatures recognize that they then have enough space for their beds. The code seems to work in most cases except for when you have 2 existing quarters that are not touching, and each of which has beds in it; if you create a new quarters in the middle which "bridges" these together you will get a crash. The bridging seems to work fine when there have not been any beds placed in the quarters but when there are beds present you get a crash.

I plan to fire up a debugger and try and fix this tonight but I thought I would commit it the mostly working code so others could check it out. I also like to keep patches fairly small so they are easier to check and understand so adding code in one and then bugfixing it in the next makes for two smaller patches which are easier to understand.

-Buck

[andrewbuck]

I got the bug worked out and the quarters now works as it should. The problem was caused by the fact that when a new room "absorbs" two existing rooms it does one first and then the other. If the first room had a bed its mesh would get deleted and the fact that it exists would get absorbed into the new quarters which would then re-create the mesh for it. Then when the second quarters was absorbed the bed that was inherited from the first room would not be destroyed but it would get re-created a second time. Since Ogre won't let you have two meshes with the same name it would through an error and quit. Adding code to destroy any beds held by the room absorbing the new room fixes the issue.

-Buck

[andrewbuck]

I implemented a similar room absorption mechanism to the treasury as well. This time it only took ~20 minutes compared to the 4 hours or so it took to do the quarters. The framework I have set up for handling rooms seems to work pretty well and I now have two fully functional rooms. The next thing I will probably add is the ability for enemies to destroy a room. Once I have the framework for that in place (and that should be relatively easy) I will add the rest of the room types and we should have an almost fully functional game. Then it will just be a matter of refining the AI and implementing new ideas that weren't present in the original DK series.

-Buck

[svenskmand]

Very nice But you forgot that we also "just" have to make all the content of the game ;P But very nice work

[andrewbuck]

Hey everyone,

I haven't been working on the code much lately (I have been working on Open Street Map) but I finally got some more work done on OpenDungeons. The code I just added makes the creatures behave a bit better in battle. Most importantly they will try to "flee" from the battle if they are overwhelmed. I haven't really tuned the paramters for this yet so they might be too "brave" or possibly too "frightened", however it does at least seem to work. I also added an animation to the list on the wiki on the Creature animations page (the flee animation). If I could get a model that has this then that would be cool so I can really test to see when creatures are "fleeing" vs just the normal walking around.

I also added a bit to the rules for how creatures gain experience in combat. Now, when they hit an enemy creature, the experience they gain is modified by the other creature's level. The difference between the level of the creature you hit and your own level is how much of an exp "modifier" you get. The modifier means you get more experience when you hit a creature who is higher level than you and you get less when the enemy creature has a lower level. This keeps the battles a bit more even. Before, if you let a couple of your creatures get killed because your initial charge was week you could lose the whole game since now the enemies are higher level meaning they are both harder to kill and do more damage. Now however since they are higher level you get a bonus when you hit them and so your creatures will "catch up" to their level fairly quickly; this evens out the odds a bit.

-Buck

[Skorpio]

Ah OpenStreetMap ... once I thought this could be something for me as well, but I'm too lazy and don't have a GPS tracker.

I'm trying to make a flee animation for the orc and will upload it later today.

Apropos battles and animations, there are some things that need to be improved. Sometimes creatures are moved to another tile while they are fighting, what looks like they are floating. Fighting creatures either shouldn't move or we have to add an attack-move animation.
The second thing is that creatures don't always face the enemy while attacking them. It looks ridiculous when they beat the air.
And sometimes a creature attacks another and the second doesn't fight back, or maybe the attack animation doesn't start for the second creature.

[Skorpio]

I've just uploaded the orc with a flee animation. It's only a slightly modified walk anim and would probably look better, if the orc was running instead of walking.

[svenskmand]

Nice work guys I have myself been experimenting with setting up a workable music environment on by laptop using JACK, ZynAddSubFx, Hydrogen, Rosegarden and Ardour. And will be experimenting with creating some ambient music for the game. I also wanted a keyboard for this, so I thought about buying a Yamaha PSR-E423, but I first need to confirm that it works on linux, else it is no use to me And while I am at it, I might also buy the Zoom H2 portable microphone I was talking about in another thread, as we will mainly have to record our soundeffects ourself I think - my idea of using freesound.org did turn out bad , what a pity

[andrewbuck]

Thanks for uploading the new mesh right away, I think this system of using SVN for the content is going to work pretty well. I updated the code a bit to make the flee animation work properly, which I thought I already had working (without an animation to test it it looked like it was working but the flee animation was getting overridden in other places, having an animation allowed me to spot this). It seems to work correctly now. The decision of when to flee vs when to attack will need some refinement but it works for now. Once we get more worked out with regards to the creature's hitpoints and damage we can start tuning some of these algorithms, for now I am just trying to get the framework in place.

EDIT: P.S. the bug where creatures don't face the enemies when they attack, dig, etc has been fixed a couple commits ago. The fix is not in the windows build yet though but it will be in the next release.

-Buck

[andrewbuck]

I got a fairly minor commit pushed to sourceforge today. It doesn't really do anything yet as it adds a function which is not yet called, but it is laying the groundwork for future work. The function computes what spot on the ground the center of the camera view is pointed at. Knowing this will allow me to do two things. First, it will allow me to make the camera automatically move to a new location, like the dungeon temple when you press 't' or maybe to a battle when you click on a notification icon. Second, I want to rework the way the camera rotation works. Currently the rotate left and right buttons just leave the camera where it is and rotate it. The effect of this is that you lose what you were looking at. In the future I want to make it so the camera "swivels" around the point on the ground that you are focused on so you can rotate around a battle or something else very easily.

-Buck

[andrewbuck]

I got the camera swivel thing described in my previous post implemented and it works great. I switched the 'delete' and 'page down' keys around since the meaning of left/right basically got reversed when I switched how the camera worked, but everyone should get used to the change pretty quickly (I already almost have and I've only played with it for a minute or two). This seems to work a lot better since when you rotate the camera you don't lose focus on what you were looking at; you just see it from a new angle, which is probably what you really wanted to do anyway.

Hopefully I will get the "goToLocation()" function working later today which will allow you to re-pan the camera to focus on an x-y location like a fight, or the dungeon temple. That one should be pretty easy to implement now that I have the function I described in the previous post working.

-Buck

[svenskmand]

Nice one Andrew

[andrewbuck]

I started working on the room HP framework and I think I have it working. Currently the creatures will not attack enemy rooms so I don't have any way to verify that it functions properly, however the implementation is simple enough that it should be correct. My next step is to make the creatures try to target enemy rooms for destruction, and if this works correctly then the room framework will be complete. If all goes well and the framework seems to be correct it should be a simple matter to finish implementing the rest of the room like I outlined a few posts back.

-Buck

[andrewbuck]

Although I said in the previous post that my next change would be the room attacking, I had an idea how to fix the last of the known camera movement bugs. With all the discussions of n-dimensional vectors and other assorted high-level math we have been having lately I thought there might be some people here who would enjoy the details of the bug, so here they are.

Previously, forward and backward camera movement used a bit of a hack that didn't fully work. Instead of trying to move forward the camera would try to move "up" (relative to the screen), the altitude change would then be chopped off so only the motion "forward" (relative to the ground) would take effect. This worked pretty well, unless the camera happened to be pointed at the horizon, rather than at the ground below you. In this case the entire motion of the "up" was in the altitude change and it would all get thrown away (or most of it if the camera was nearly horizontal), resulting in little or no forward motion.

The new method uses a quaternion to rotate the translation vector into the camera's reference frame. This gives consistent camera movement regardless of how the camera is tilted. This bug is fixed on the development branch in git, however it didn't make it into the windows release on sourceforge. I probably won't release a patch just for this since it is a relatively minor issue but the next release will have the fix.

-Buck

[svenskmand]

I think the model animations should also be looked into, they seem to much too fast in the game. Also creatures move while they are performing attack moves, which makes the slide across the ground which looks dum. I can look into the camera math, it should be easy, I once tried to make my own software render engine (very basic) and I remember that camera movement was pretty easy.

[andrewbuck]

You don't need to look into the camera math because it is already fixed, that's what my post was about.

The reason the animation looks a bit fast is I set the default gamespeed to 1.4 instead of 1. A speed of 1 makes things a bit slow so this is why I sped it up. You can use the 'tps' terminal command to change the 'turnspersecond' that controls this.

As for the "sliding" while attacking, I agree this is a bit of a problem, but I think there may be a way to solve it (the reason they do it, by the way, is that they have a probability of "strafing" during the battle mode where they try to swing around the side of their enemy, this sometimes coincides with an attack). One way we might be able to solve it is this... We make two separate walk animations called Walk and WalkLegsOnly. The animations are exactly the same except WalkLegsOnly has all the keyframes for the upper body bones deleted so the upper body remains motionless. We can then use the fact that when Ogre plays animations you can enable multiple ones at a time which will be "blended" together (this is what caused the problem with the animations looking funny before). Then the upper-body will do its attack and the legs will do the walking animation (Note: that the attack animation should maybe also be split to a normal Attack and an AttackArmsOnly or AttackUpperBodyOnly). This should work for humanoid creatures but I'm not sure it will fix it for all of them (as some other creatures may use their legs in the attack so it would be impossible to separate them). We could just disable strafing on the ones we can't fix it for, and/or possibly disable strafing for all creatures until we get it fixed (this would be as easy as commenting out a block of code, if that is what is causing the problem anyway).

-Buck

[svenskmand]

You don't need to look into the camera math because it is already fixed, that's what my post was about.

Ok

[andrewbuck]

I have started to implement making the rooms "attackable", albeit in a somewhat roundabout way. I just pushed a commit to sourceforge which adds a new class called AttackableObject. This class is an abstract base class, which means you can't create an instance of this class directly since some (or in this case all) of the class's methods are not implemented. Instead this class is meant to be a base class which other classes inherit from and subsequently provide implementations of the methods.

The attackable object class has methods like getCoveredTiles(), getHP(), takeDamage(double damage), etc. These effectively provide an interface to allow creature AI routines to walk over to and attack anything that implements them (i.e. anything which inherits from the AttackableObject class and implements the various methods). Currently only the Creature class implements the AttackableObject methods, and the creature AI still only allows for the attacking of other creatures (instead of any AttackableObject). My next move will be to make the combat routines route their operations through the functions specified in the AttackableObject class. Once this is done (which should be quite soon since it is an easy thing to do), I can implement the methods for the Room class and then creatures will automatically attack either creatures or rooms. This same interface will also work on traps, doors, and anything else that we want to have enemy creatures destroy.

-Buck

[svenskmand]

That is nice. By the way do you have a roadmap of what features you plan to implement in the next while?

[andrewbuck]

Not a formal one, I plan to get the room attacking finished up so that the interface that rooms use to interact with everything else is totally defined and working. Then I plan to Add some more room types (maybe training room, library, etc). Also at some point here I will start on sound but the rooms are the current priority.

-Buck

[andrewbuck]

The room attacking is now functional. The AttackableObject system ended up working almost exactly as expected and it will be easy to add to traps and doors when I get them added so that creatures will attack any enemy assets that they see (creatures, traps, doors, and rooms). The advantage to the this system is that the combat AI only has to be written once; the same code that makes a creature walk over to and hit another creature is the exact same code block which makes a creature walk over to and hit an enemy room tile. The tiles are destroyed one at a time and each has its own HP value.

The only thing the system does not do yet is there is no concept of a "threat level" posed by the various AttackableObjects. This means that when an enemy army invades your dungeon, some of them will attack your creatures and some will attack your rooms (even though the rooms pose no immediate threat and they should therefore focus on killing your creatures first). This is something I plan to add in the future, I know how I will add it and know that it won't break the existing framework; the only reason I am not adding it now is that it is not a huge problem and although I know what to add it will be fairly tedious to set it up.

-Buck