Q: Did you use Actionscript 2 for this project? If so what advantages did you find over AS 1 ?
Benjamin: We used Actionscript 2 for Dawn 2. Even though Actionscript 2 compiles to Actionscript 1 and then to Bytecode I think that I would have been not able to develop Dawn 2 without Actionscript 2. Actionscript 2 and a clear oop structure helps me tremendously to keep my coding structure clear and to keep an overview of the various elements.
Q: Do you use an external editor for Actionscript? Which one would you recommend?
Benjamin: At the time we started this project (nearly one year ago) Primalscript was the one I liked most. So that is the editor we still use for editing our Actionscript files. I think it’s a great editor with lots of cool stuff. I tried to move the project over to the famous eclipse combos like FAME, FAMES, etc. (http://osflash.org) but with no luck. If I had to recommend a code editor I would for sure go for these environments.
Q: What were the main difficulties you had to overcome in developing the game?
Benjamin: Coding wise, the biggest problem was to find a structure that works. There are so many different elements in an RTS game which have to communicate with and depend on each other.
As this is my first RTS game (actually this is my first serious game), I had to read through some books about game programming in general (e.g. "Windows game programming Gurus“) and about RTS games in special (e.g. "Real time strategy game Programming") to get a grasp of how the pro's do it.
These books were all written for c/c++ programmers so even though I am able to read and understand the source code I am not able to just port it over to Actionscript because that’s a whole different story.
But what makes these books so valuable even for Actionscript coders is the overall idea of game programming.
Once I had a clear picture of the various elements of an RTS game and how they interact with each other in mind I had to dig deeper into some of them, for example artificial intelligence (finite state machines, path finding) and networking. So in addition to my books I also read through a lot of online articles at that time.
After that I began to port my ideas to an Actionscript friendly environment and drew some diagrams. Some of these diagrams described the structure of the whole game, some of them were more specific and class diagram like (e.g. the units logic, see the last picture above).
This whole research phase took nearly 3 months. After that I could finally get myself into coding. ;)
So as you see the biggest problem was to get an idea of what I want to do and how to do it. If you are an experienced Actionscript developer it's not that hard to write a lot of Actionscript code to make things work. It’s more about getting the idea behind.
Q: Did you develop special tools for creating maps or debugging?
Benjamin: We do not have the need to develop a tool for creating maps yet.
For debugging we actually have a tool in place which gives us in depth info about various aspects of the game. The aspects of the game we can monitor in our debug tool at runtime are:
- grid (show paths of units, show waypoints for path finding engine, show depth grid, show occupied, free tiles)
- units (the unit’s ai reports every single state of every unit to that window)
- projectiles (various info about generated projectiles like damage, source of projectile, damaged units etc...)
- structures (info about entering / leaving structures or taking over energy cells, possibility to show the underlying structure grid)
- shadows (shows which unit is at which time how much in shadow, info about the shortening of shadows)
- network (shows info about incoming xml packages)
- sound (shows which sounds get played on which channel at a given time)
- server (shows info about server load and memory usage)
Q: Talking about the multiplayer side of the game, how did you develop the game logic? Is it on the server side?
Benjamin: The game logic is on the client side. This gives us some advantages and some disadvantages.
Advantages, Client side:
- faster response times (e.g. when you order a unit to move somewhere it goes there immediately)
- no server side coding required
- faster development cycle as I am an advanced Actionscript coder but a beginner c/c++, java coder.
Disadvantages, Client side:
- it's insecure
- synchronisation of both clients is hard to achieve (and there is a very slight possibility of < 0.2% that things look different)
- client has to take care of all CPU intensive calculations (e.g. path finding, line of sight algorithms, etc.)
The main reason for developing the game logic client side was the faster development cycle and the fact that we were able to achieve a synchronisation of both clients.
With our chosen model and implementation there is no 100% guarantee that the game behaves the same on both clients, but I guess the possibility is somewhere around 99.8%. That’s good enough for now.
Q: Did you use any particular "tricks" in your multiplayer code to allow smoother interaction? If so, could you describe some of them?
Benjamin: Well, no tricks at all. It has more to do with which things need to be the same on both clients and which do not.
For example it’s not absolutely necessary that all units are at the same places at a given time, but it is very important that events like taking damage, overtaking structures and dying is the same on both clients.
So, if you have a high network lag, things might look strange to you. A unit might take damage by your opponents unit which is on your screen not even close to it. In a scenario like that the faster client (smaller lag) is always right.
But that is nearly the same if you play any commercial multiuser first person shooter. If you have a high lag your movement will become very slow and you will not be able to defend yourself or attack properly.
Q: Developing a multiplayer game is quite a long work. What would you suggest to developers willing to create their first mp game?
Benjamin: Start small! The first prototype of dawn2 started two and a half years ago. It was done with a self deployed java socket server which consisted of 2 java classes. Play around with some of these free socket servers to get used to it.
Søren: Same here. There's so much production work, so starting off simple gives you more time to worry about the concept, and not whether or not you are going to get those thousands of pics done in time.
Q: Can you tell us about your future game related projects?
Benjamin: No idea yet, we’ll see.
Søren: We'll see. Probably something strange.
Q: The new Flash IDE and Flash player are awaited in a few months. What do you expect from this new release?
Benjamin: I’m not interested in the new IDE, the old one works well for me as a developer. I actually hope I can get rid of the IDE at some time ;).
But there are some things I expect from the new flash player:
- faster code execution
- faster graphics rendering
- load a swf/image into a movieclip and being able to dynamically attach or duplicate that
Søren: Everything should just be faster! Since flash is so slow, you spend a lot of time making workarounds, which is really silly. Other than that:
- finally, different blending modes (I hope they are as fast as in Director)
- a timeline and layers that are easier to manipulate.
- variable framerate (that'll be the day; one can only hope)