State of the Code

[charlie]

Perhaps you could provide a patch that makes it compile?

[oln]

I'll look into it.

[svenskmand]

So your are up and running now? That is very nice

[oln]

Well almost, have some linker errors, that is probably related to my systems to sort out first.

[svenskmand]

Ok, but it is very good that you are making progress

[andrewbuck]

Glad to hear there are others interested in working on the code. A big part of why I have slowed down recently is simply that it is hard to get motivated to code when you are the only one working on it. A project of this size is far to big for one person to handle so extra help is greatly appreciated.

-Buck

[oln]

The problem was that the code I checked out (and what was listed on the wiki) was the master branch, which is behind the development branch which contains the newest code, which does work (though requiring Ogre 1.7.* / CEGUI 0.7.*). This code compiled nicely.
EDIT: Hm, seems that the drivers weren't the issue.

[oln]

The ogre lib in the ppa in the post earlier is build without thread support, which opendungeons needs. Rebuilding the ogre packages from source worked.
EDIT - disregard that

[andrewbuck]

As far as I know you shouldn't need the multithreaded aspect to OGRE, I go to great lengths to avoid that actually since older versions of OGRE didn't handle multiple threads making rendering requests. I am running the versions from the PPA on my system and it works just fine. If recompiling fixed the issues for you though that's good.

-Buck

[oln]

Hm, that's odd, maybe I did something weird then.

EDIT - Apparently I did :P

[andrewbuck]

Just thought I would make another update to the recent changes I have added. Most importantly I got the Dungeon Temple room type added, as well as a goal type called GoalProtectDungeonTemple. I have tested both of these and they work as expected, if you have a GoalProtectDungeonTemple listed for your seat then as long as you have a temple that goal is satisfied, if your temple is destroyed the goal moves to state failed. Making this a goal, rather than hardcoding it into the game gives us more flexibility in level design, for example you can have one or more sides which do not have dungeon temples, but rather must invade and destroy the temples of the keepers who do have them. Secondly, when the subgoal system is in place we will be able to add a subgoal on the isFailed side of this goal, so initially your task is to protect your temple and acheive some other goals. If your temple is destroyed your goal can then switch to "retreat mode" where you have to protect some creature and get them to a certain target on the map.

I also pushed a second commit this morning which adds the Forge room and allows you to create them. The forge is not functional yet, i.e. you can't build traps, etc, but the framework is now there. The forge will not be functional until the trap system is in place.

I plan to either work on the subgoal system or the trap system in the next few days. Let me know what you all think of this, which one would be more useful to have implemented first? Also, it would be nice to have some simple meshes for all the rooms currently implemented so they can be distinguished on the map (dungeon temple, portal, quarters, treasury, forge). Some of these have meshes already but some others do not.

-Buck

[svenskmand]

I think that the trap system is the first priority of the two, seen from the perspective that we want the most basic things working first, and then we can later add more and more details. Regarding how the placing of traps and triggers should work I think we should use the system from Evil Genius: When you want to place a trap or trigger the game is dimmed to a darker color and colored nodes appears on top of each trap and trigger that you have placed on the map. Each trigger/trap has directed edges to the traps/triggers they spring. If we look at this as a graph then the nodes can have any degree. In this mode you can right click a trigger or trap, then a edge will follow the mouse until you right click a trap or trigger to connect the other end of the edge to the trap or trigger.

Edit: Remember that the above is how I imagine it should work in the final game. As a soft start we could have traps that only trigger when a creature enters its field, like in DK, and then afterwards build the trigger system on top.

Edit^2: A suggestion for the first trap would be the classical lightning trap from DK, it should be fairly easy to implement; it should just instantly kill the creature entering its tile (or at least give a massive amount of damage) and then spawn a very bright light that dies in 200 milliseconds or something like that. It should be triggered once a creature enters its tile.

[oln]

I just pushed a commit which makes it possible to change the mouse speed using the mousespeed command.

[svenskmand]

Nice

[andrewbuck]

I pushed in some code today that I have been working on for the last few days. The framework for the trap class is now in place and I just need to add some code to make it read in traps from the level file as well as make them actually attack creatures.

I also added a class called ActiveObject which should make the upKeep rounds easier to do when there are lots of different classes having upkeep calls. All of these things like traps, rooms, etc, can then ActiveObject and the gameMap can then keep a list of all the things which need upkeep done on them and then perform a single loop over them instead of having to have a separate loop for each subclass.

-Buck

[andrewbuck]

Just pushed another commit which adds support for displaying RoomObjects. Room objects are things which exist as part of a room but are not loaded as part of the room's mesh itself. I made the dungeon temple create an object as part of its loading and it seems to work. There are now two separate meshes associated with the dungeon temple.

DungeonTemple.mesh - The "floor" for the dungeon temple, i.e. what each 1x1 tile should look like.
DungeonTempleObject.mesh - The actual dungeon temple mesh that Skorpio is currently working on in the other thread.

As a test I just copied the mesh for the treasure chest as my DungeonTempleObject and the loading/detruction of the mesh works as it should. This same framework will make it quite easy to add the items for the forge and things like training room objects, etc, when we get to them.

I also made some more progress on the trap class. The input/output routines are in place, I haven't tested them explicitly yet but they are basically using the same system that room loading/saving works so that should be no problem.

-Buck

[andrewbuck]

I got the room objects working completely now. I have moved the code into a function in the room class called Room::loadRoomObject() which lets you load an object at a tile in the room (or anywhere on the map if you want). I have attached a screenshot below showing the code working, although the meshes are wrong since I haven't exported all the meshes yet. In the image below the portals are 3x3 with the gold bag loaded where the portal should be. For the Dungeon temple it is currently 1x1 and the dungeon temple would be loaded where the gold chest is. The forge has the flame where the forge should be (the furnace), the bed where the table should be, and the gold chest where the anvil should be.

The filenames of theses objects should be as follows.

Forge.mesh - the "floor" for the forge room.
ForgeForgeObject.mesh - the furnace.
ForgeAnvilObject.mesh - the anvil.
ForgeTableObject.mesh - the table.

Portal.mesh - the floor of the portal area.
PortalObject.mesh - the actual portal itself.

DungeonTemple.mesh - the floor of the dungeon temple area.
DungeonTempleObject.mesh - The actual dungeon temple object.

I plan to do other kinds of objects that always come with the room itself in a similar naming fashion. For objects which can be purchased/added to a room by the player I will probably encode the name into the file itself. I may even make it so you can specify default room objects in the file too but that is a lower priority.

-Buck

[svenskmand]

Nice, one we are getting close to something that we can actually play

[andrewbuck]

I got the trap loading working now. You can't yet add your own traps in game but hopefully that should be pretty easy to implement.

-Buck

[svenskmand]

Awesome, I cannot wait to try it out

[oln]

Pushed a commit with the music changes. Will update the wiki with build instructions later this evening. It looks in "Media/music" for audio files and plays whatever is there.
I believe andrew merged the master branch with the current updates from the developer branch (before this update), so that can be used if people want to check out the last version without sound.

[svenskmand]

As mentioned in this thread I will try and see if I can make a PPA. But I also think that we should have Windows binaries build for every release. Right now the building guide state that to build on Windows you need Visual C++ 2008, I would really like if we could change this requirement such that we only depend on FOSS to build our game on Windows, say using GCC, as I have no license for Visual C++ and do not intend to buy one. I am hoping for a easy one button compilation for Windows binaries, such that we can easily make new ones for each release. If no one of you guys have a windows install at hand I can build them, but I would like some easy one-click solution.

Edit: Oln it seems that you have forgotten to list some package for OgreOggSound, I just followed the steps until this

{l Code}: {l Select All Code}

cp /usr/lib/libOgreOggSound.so /usr/lib/OGRE/OgreOggSound.so


which did not work as I have no file called libOgreOggSound.so in the directory /usr/lib/ :S

[Bodsda]

As mentioned in this thread I will try and see if I can make a PPA. But I also think that we should have Windows binaries build for every release. Right now the building guide state that to build on Windows you need Visual C++ 2008, I would really like if we could change this requirement such that we only depend on FOSS to build our game on Windows, say using GCC, as I have no license for Visual C++ and do not intend to buy one. I am hoping for a easy one button compilation for Windows binaries, such that we can easily make new ones for each release. If no one of you guys have a windows install at hand I can build them, but I would like some easy one-click solution.

You don't need a license for the cut down version. I don't do any programming on Windows so I don't know of any other windows C++ compilers. Once the initial build development is set up though, recompilation of a new version should be fairly trivial.

Bodsda

[svenskmand]

Ok, I just thought that I needed a license. You normally do for all their stuff.

[Bodsda]

Ok, I just thought that I needed a license. You normally do for all their stuff.

Well, they arent that bad. Almost all of their enterprise stuff has a stripped down 'express' version.

Bodsda