About my projects
I currently have tons of different projects in mind - at least 4 of them are related to game development. I already spoke about the Designer Wiki System (oh! DWS looks like a cool name...) in one or two threads so I won't speak a bout it here unless I make some major improvement to the PHP code. 2 out of the 3 other projects are still in the "early development stages" (usually you use this expression when you haven't done anything yet).
The last one is a 2D RPG (2D top view), and I'm currently designing the graphic engine. I won't speak about the game itself, and I won't speak about the gameplay - which is rather basic. I target both PC and mobile phone (I'd like to program a nokia - this may modify the gameplay because of the limitation of cell phones). You might think that I should use java to do it. I won't (I never used java. I bet a game should not be the first thing to do with a language that you don't master).
Anyway, I was speaking about the graphic engine design. Why should I begin with it? There are tons of other components in a game - sounds, gamerules, input and son on - and the graphic part is just one of them.
The point is that once the graphics are set up, I can show the game to others, and maybe I'll be able to hire artists to deal with sound and sprites. I'm not able to do my own sprites and I really need (well: I'll really need) an artist to help me. This will be easier when I'll get something to give him ideas about the game itself. Until then, I'll use free tiles/sprites which can be found all over the net.
If we do some short UML design sequence, we have to ask ourselves the question: who is going to use the software we are currently doing? In my own case, this is simple: the game will do. Not me, not the user, only the game. When it comes to library design, this is the only answer you'll be able to do. Since human beeing are not able to read binary code and execute it in their mind, only a program can use a library (a package if we use UML terminology). That's really cool.
The difficulties begins when we ask the second question: what will the actor do with your software? In UML terminology, you deal with use case scenarii. This is typically the negliged design part, but I believe it is the more important. How can you design a library interface if you don't know what your library will have to do? This is not possible. Moreover, I'll bet you'll experience some really difficult design issue even if you barely know what should be the goal of your program.
When I say "my graphic lib will be able to display a 2D world and the player and 2D object sprite and monsters and cool graphical effects" then I said nothing interesting. The real "use case scenario" question is a bit more complex.
So, what are the use case scenarii? Let's examine some (like in: not all) of them:
- the game needs to init and uninit the graphic library. This one was an easy one. It simply says that I'll have at least two entry points in my package: init() and uninit().
- the game needs to display the static world. Wow. The big one. What does mean "displaying static the world?". Static is easy: this part of the world only deals with things that don't move. We'll have to admit that we still don't have a clue of what a world is. What this issue tells us is that a world is not really a graphical object - it is more a game object - and therefore is not a part of our library. We don't care about its internal representation for now - this may evolve during the design process.We have now another entry point: draw(worldtype world);
- the game will need to display non static objects. Since static means 'which do not change during the game', we can understand that non static means 'which can be modified during the game'. A player's avatar is a non static game object. A door is also a non static object. There are tons of non static object in the game world, and this use case deals with their display. Again, we add one entry point to our package: draw(nonstaticobjecttype object).
Of course, there are numerous other "use cases". I'll probably give you all of them in a subsequent journal entry. In this (rather short) design, I can only display my world and display a player.
Before we'll stop considering the different use cases, we'll have to ask ourselve another important question: 'did I forget anything important?'. Of course we did. We forgot to ask ourselves numerous questions which are related to the design of our graphic library: who is responsible for doing the collision detection? If we need a per-pixel collision detection then the only subsystem who is able to do it is the graphic engine. If we only need a simple collision detection then we'll may be able to perform it outside of our package - this should be better.
The next point will be simple: we'll begin to design the different class we need, and - of course - we'll have to update our preliminary design. We'll need to have a look to the inside of a graphic system.