Map Design

[svenskmand]

I would very much like to volunteer for map building , but hopefully we will have a working installer before that - it is a pain to get the game compiled and running as it is now

Regarding scripting in a map, how have we planned doing this? Which language?

[andrewbuck]

I split this topic off into its own thread (I have done that with a few threads to far, I hope no one minds) as I think it makes the discussions much easier to review later on if we use lots of threads and try to keep each thread on topic as much as possible.

Regarding map design, that would be cool if you wanted to start working on that. If you upgrade to Ubuntu 9.10 the game now builds correctly against the libraries ubuntu ships with so much of the pain is removed. I'm not sure about other distros, though. Also note that once you have successfully built the game once, building updated versions will be easy. The windows build is a bit out of date since the level format has changed a bit since then, I can try to get a new release built in the next few weeks but it is tough for me since I only have access to an XP virtual machine.

Back on the subject of maps, we should start trying to brainstorm for some neat things to do with the maps, so once you (or others) start building them they can take advantage of the ideas. Interesting things to note about the games design is that maps can be any shape, and can have holes, or islands in them. This can be done because the tiles are stored in the level file with their X-Y coordinates, instead of being stored in grid format (so don't be afraid to make a level with one long arm sticking out, this is no less efficient to store/load than a boring square level). This removal of restrictions on level shape means that, for example a 3 person map could be triangle shaped so all three players get the same layout (this is a big improvement over the design of other RTS games). Furthermore, we could make a map with lots of little round sections joined together by a web of pathways (with little holes in between the various pathways), or a "spoked wheel" kind of map where you have lots of individual areas connected to a central "core" region.

As for scripting, I haven't given that any thought. I really don't know how to allow scripting on a map and how to let it interact with the rest of the game engine. The goals I asked people to come up with in the other thread were going to be coded in C++ like the rest of the game. The level file then just specifies which goals are needed for victory (and their corresponding arguments) and then they are loaded into a list of things that need to be done by each Seat (a seat is a basically a single dungeon keeper, multiple players can share a seat to allow for teams, spectators, etc). In a way I think this is the best design because since a lot of computation has to be done inside the server, it needs to be very fast. Not only are scripting languages themselves quite a bit slower, but passing things to the scripts and then back to the game could be a serious bottleneck.

-Buck

[Bodsda]

I split this topic off into its own thread (I have done that with a few threads to far, I hope no one minds) as I think it makes the discussions much easier to review later on if we use lots of threads and try to keep each thread on topic as much as possible.

Regarding map design, that would be cool if you wanted to start working on that. If you upgrade to Ubuntu 9.10 the game now builds correctly against the libraries ubuntu ships with so much of the pain is removed. I'm not sure about other distros, though. Also note that once you have successfully built the game once, building updated versions will be easy. The windows build is a bit out of date since the level format has changed a bit since then, I can try to get a new release built in the next few weeks but it is tough for me since I only have access to an XP virtual machine.

Back on the subject of maps, we should start trying to brainstorm for some neat things to do with the maps, so once you (or others) start building them they can take advantage of the ideas. Interesting things to note about the games design is that maps can be any shape, and can have holes, or islands in them. This can be done because the tiles are stored in the level file with their X-Y coordinates, instead of being stored in grid format (so don't be afraid to make a level with one long arm sticking out, this is no less efficient to store/load than a boring square level). This removal of restrictions on level shape means that, for example a 3 person map could be triangle shaped so all three players get the same layout (this is a big improvement over the design of other RTS games). Furthermore, we could make a map with lots of little round sections joined together by a web of pathways (with little holes in between the various pathways), or a "spoked wheel" kind of map where you have lots of individual areas connected to a central "core" region.

As for scripting, I haven't given that any thought. I really don't know how to allow scripting on a map and how to let it interact with the rest of the game engine. The goals I asked people to come up with in the other thread were going to be coded in C++ like the rest of the game. The level file then just specifies which goals are needed for victory (and their corresponding arguments) and then they are loaded into a list of things that need to be done by each Seat (a seat is a basically a single dungeon keeper, multiple players can share a seat to allow for teams, spectators, etc). In a way I think this is the best design because since a lot of computation has to be done inside the server, it needs to be very fast. Not only are scripting languages themselves quite a bit slower, but passing things to the scripts and then back to the game could be a serious bottleneck.

-Buck

I love the idea of scripting levels. I play a game on Windows a lot called Dawn Of War Dark Crusade. It is a brilliant game and also has some interesting gameplay events triggered by scripting. But the game scripting only exists for the Single Player (Campaign) missions. This is good because everything is run from the client side, there is no server to update, no other players to pass information to. The script just waits for certain conditions to be met, and then triggers certain actions, like if your goal is to reach the extraction point but when you get there you find a swarm of enemies, the extraction point changes and your goal changes to eradication of the enemy. I think we could implement this into OD.

We will already have the goals per mission, but why not have a script thats sits on the client, waits for a certain condition to become true, like player1 claims x,y tile and awakens the undead. The script then requests to the game that the goal be changed from whatever it is to annihilate the undead. If the players forces drop to 1/3 of their original strength, the script triggers again and requests the goal be changed to a stay alive for type goal. This has the ability to create an extremely unique gameplay in a way that you could run through the entire campaign 5 times and still not meet every eventuality. This will increase the enjoyment of the game and create some very interesting levels. It also stops people from getting bored. Have you ever played a game where you get to a point where you cant beat this one level, and you spend days and days on it and eventually get bored and give up? This would eliminate that from hapening with OD, because you dont have an all or nothing goal, it can change based on circumstances. We could control this further by branching the campaign with loads of branches which differ in length but all eventually lead back to the ending. People who constantly cant get the first goal get shafted up a branch which is slightly easier, then if they get better, it merges back in.

Bodsda

[Bodsda]

Andrew Buck and I were talking on IRC yesterday about how we could implement the level scripting. The main problem we encountered was that if a user had the ability to send multiple action requests to the server via a script, they could in theory write their own AI to significantly increase their chances of winning. This could cause major problems allowing people to cheat and completely ruin the fun multiplayer aspect of the game. For this reason we are struggling to come up with a suitable way of creating dynamic levels without a scripting interface. Not to mention the extra workload to be able to allow client side requests on another interface other then the game client.

I thin kI may have found a possible solution. We could make the levels event driven based upon trigger points. By this I mean we have a certain point on the map (decided by the map designer) or many points on the map, that when triggered would create a new goal. For example we could have two classes, triggerClaimTile and triggerClaimRoom. Each of these classes have a map of key symbol to value goal which create new goals. If you map triggerClaimTile.goalSurviveNMinutes to %, and then place the symbol % in the map file, when the tile at that coordinate is claimed the triggerClaimTile class is called and runs the goalSurviveNMinutes method which would change the primary goal to be a survival challenge. This would allow you to make specific predefined events happen based on certain triggers which elminates the need for a scripting interface and also stops the possibility of writing an AI hack.

Would does everyone think? Can anyone think of any other ways to do this?

Bodsda

[svenskmand]

I do not think the cheating thing is a problem, the scripts I was thinking about was only made by the map-designer and belongs to the map. It should be the servers responsibility to execute the script, the clients should have nothing to do with this. This should be like the scripting that is possible in StarCraft and WarCraft III's map editors. But I just wanted to hear which language should be used, I would suspect that Python would be easy to use (because many game-developers use it), I do not know any scripting language so I would have to learn it any way.

Also trigger-points is also part of the way StarCraft and WarCraft III does it, so that would be a good idea.

[andrewbuck]

I thin kI may have found a possible solution. We could make the levels event driven based upon trigger points. By this I mean we have a certain point on the map (decided by the map designer) or many points on the map, that when triggered would create a new goal.

This is basically exactly what I was thinking. There is basically a tree of goals, when a goal is completed it can optionally add one or more other goals to the goal queue for the player. This lets you make dynamic levels without the need for parsing scripts and passing stuff between the C++ engine and the scripts. The implementation will be slightly different than you described (there will not be a % sign, etc) but the main idea is exactly what you laid out.

Regarding the point svenskmand made about the scripts running on the server, I am afraid that this is going to be a huge bottleneck for server speed. What you are talking about with the scripting being part of the map is basically what we are going to have. The only difference is that the "language" will be an OpenDungeons specific language specifying the tree of goals, rather than a general purpose language like python.

-Buck