Since my last post, the one about game design that included a discussion about using XML, I took another run with Microsoft's XNA studio. In particular the RPG toolkit.
Can you guess how it stores all of it's quest, item and character data?
Yup. XML. I'm building it at the moment, using the "release" configuration. For science!
While waiting I may as well say something useful... ho-hum. ICO is great, though I think I preferred Shadow of the Colossus.
When I saw that my counter had reached over 2000 hits I had a look at my stats again. Some interesting ones. I get regular searches through google, and some hits from Wikipedia. My main traffic comes from the Nosgothic Realm, which is fair enough. However, I've also been linked to through a quick-search on Facebook and Google's Orkut beta, which is basically Google's answer to Facebook. It looks a bit interesting.
Also, I've gotten hits to the main page without a referring link from someone in Japan using the "@home Network Japan" ISP. Sam, is that you?
There we go, build done... The XML files are transformed into Microsoft's own standard, XNB files... which are non-unicode files, so difficult to mess with.
On the one hand it is good - if you were to design an RPG and then give it to people, you wouldn't want it to be essentially you giving them the engine, leaving them able to mess with the data. That would be a bit pointless.
However it also makes it a bit more difficult - for example, if you wanted to create an RPG which was extendible, so people could make mods for it. Even if you didn't want to let them mess with your stuff, you might still want them to be able to add things. You would then need to make the program in such a way that it could also read the external files added by users, which may or may not be difficult.
Tuesday 25 August 2009
Monday 10 August 2009
Game design
I like to try and program games in my spare time - I've got a few projects in mind, but they'll all take a long time to make.
One of the first tasks would be to try and design an engine for the game, which in turn requires figuring out what classes to use/design and how they should interact.
So I'm going to muse upon this here and we'll see what I come up with.
The first thing to consider would probably be whether the game is 2D, 3D, or a mix of both. This would greatly influence how characters get displayed - you could have a fully 2D game using sprites like the old Zelda games; You could have a fully 3D game like Half Life, in which everything is a 3D model with a texture on top; Or you could have a game that blends the two - 2D sprites in a 3D environment, 3D models on a 2D plane... those are probably the only two options to be honest.
You could even have fully 3D game but viewed from such a perspective that it looks like a 2D game - the most recent Pokemon games seem to be like this (though the characters could be 2D sprites, it is difficult to tell.)
Since I know next to nothing about 3D programming, I'll focus on 2D for the sake of familiarity and simplicity.
For 3D games you'd probably want a camera class, but this also goes for 2D games.
Though the camera will likely be following the main character, perhaps all of the time, it can be more complex depending upon how the game world works.
Think of Link's Awakening on the GameBoy, or the Minish Cap - the world is split in square areas. Large square areas, bigger than a single screen, but they have borders. When Link approaches a border, if the camera is centred on him constantly, then the game would have to display what is outside the area. If not properly controlled, it could show the contents of some other bits of memory.
The game could be set to only display black outside of each map (so, make it place the maps in the centre of a large piece of black that is generated by the game itself) - this would take up processing power, which may or may not be cheap.
You could design each map and have a big black border around the side of it (assuming that the maps are saved images, rather than generated on the fly using a tileset) - this would cost storage space, which may or may not be cheap.
Another solution would be to make the camera centre on the character, but to never cross the border of a map - this would require that the map somehow conveys what its borders are and would be much easier if the maps were uniformly rectangular.
A final solution would be to make the maps wrap, but this would only really be sensible if the game world was open and not a set of isolated maps.
Also, perhaps worth some brief contemplation - will the camera make the engine render only what the camera sees, or does it simply display what is rendered within a small space. I'd think the latter, though the former is probably possible (just not obviously sensible.)
Next I might as well consider maps. In 3D games they tend to be meshes with textures stretched over them, so you could have one mesh landscape with a single texture over it per map, but this is a silly option.
A better option would probably be to have maps made up of different 3D models placed together, intersecting.
But enough of that, let's focus on 2D.
The way I see it you have two main options:
A single image per map. Though this is a misnomer of sorts - how would you account for solid objects? One solution is to use what is referred to as a "hardness map" - another image using particular colours so that the game came determine what you can and cannot walk through. This of course means that you have at least two images per map.
You could perhaps still do this, but have all solid objects (or objects that would result in particular interactions, for example water) as sprites.
If storage is an issue and you plan to have many maps, this may not be the best solution.
The second idea is to use what is referred to as a "tile set" - simply a set of tiles which can be used to create maps. In many cases I think I've just seen this as a tool for creating the single images as mentioned above, but you could use it another way.
You could use something like xml for each map (which, since it would be unformatted text, would be small in file size) which maybe would say the name of the set it will use, the dimensions of the map, and the tiles.
As an example, if you have a set consisting of 8 tiles and a map which is 2x2 (and each tile is, say, 32 pixels square) this could be described as:
[tileset]"set1"[/tileset]
[size]
[tile]32[/tile]
[height]2[/height]
[width]2[/width]
[/size]
[map]1,2,2,1[/map]
Or something like that. There would probably be a more sensible way to describe which tile goes where, but I think I made my point. A file like this would be 117 bytes (in windows), where the equivalent image (I just quickly tested in GIMP) was about 34.2 kilobytes - roughly 299 times larger (though some of that will be offset by including the tile set, so this is probably only a good idea when you have many many maps.)
Not only is this obviously better in terms of storage, but this method is highly adaptable - the information can be arranged in any way and new functionality that is part of the maps can be easily added without needed to carefully alter an image.
However, if the maps are too big this might impact processing power too much, so the designer should take care.
Another consideration is the sprites in a game.
Now, I cannot think of any way around this problem - no matter what you will need a lot of images. From some tools I've used this is normally done in the form of a sprite set - so, rather than needing many many smallish images, you can have one large image per character (or per character type if they are going to be used multiple times.) This will cut down on storage marginally, but also increase processing somewhat.
These would be used much like the tile set, except you would only display one at a time. By having a series of sequential images you could do a character animation (though maybe storing them as animations could be a better solution.)
The only major problem with this is if the sprite will ever change in size - they might be 32x32 for most of the time, but then for some actions get larger, which would mean all of the other images would need to be larger, increasing file size greatly - so, basically, if the character images (for one character) are going to be similar in size, a sprite set is the way to go; if the character is ever going to change in size, then separate images is the way to go.
Collision detection could also prove to be a problem - if the character images are stored in blocks with some blank space around them, then the game would need to understand not to report a collision if the blank space is hit - using a uniform background "ignore" colour is probably the best way to go, but the game would also need to make sure that colour is not displayed, so would need to either not draw it or convert it to transparency. Either way, processing is probably going to increase.
On that note - characters. Each character will obviously have a sprite, but what other aspects should they have?
In many RPGs you will have characters you can talk to but cannot kill, or even attack. If any fights are going to be separate to the talking mechanisms (i.e. in the Final Fantasy games where you would normally be talking when viewing the game from one perspective, but in battle be on a special map from a different viewpoint) then you could either have two separate characters (one for outside battle, one for inside) or have one character with two different sprites (in and out of battle.)
If it is more of an action oriented game (e.g. Zelda) you could stop the player from being able to attack in certain areas and you would populate the areas with such NPCs. Other games in the same series don't stop you from being able to attack, but have no collision detection from your weapons activated on such characters.
Or you could go the route of Elder Scrolls and give everyone every single statistic and just make everyone killable.
Though this may seem to be only applicable to RPGs or Action RPGs, but it could also extend to other genres - platformers, or even top-down-shooters (perhaps first person shooters, but that is a bit harder to imagine) - heck, even GTA kind of goes the Elder Scrolls route, it just has fewer stats.
Assuming you go any route but the latter, a class hierarchy could be like this:
Character (has a sprite)
/ \
NPC | Enemy (also has a battle sprite and stats)
But then what of the player character? It seems like it could be a subclass of enemy. Also, what of Enemies that you won't encounter in the field? Perhaps their "character" sprite could be null - as long as it is never called then everything should be fine.
Maybe then a better structure would be:
Character
/ \
NPC | Statted (or a better name)
/ \
Enemy | PlayerCharacter
That's all I can come up with for now.
PS: I note that the class diagrams are bad at the moment, but having worked on this post for about 90 minutes now, I have run out of steam.
One of the first tasks would be to try and design an engine for the game, which in turn requires figuring out what classes to use/design and how they should interact.
So I'm going to muse upon this here and we'll see what I come up with.
The first thing to consider would probably be whether the game is 2D, 3D, or a mix of both. This would greatly influence how characters get displayed - you could have a fully 2D game using sprites like the old Zelda games; You could have a fully 3D game like Half Life, in which everything is a 3D model with a texture on top; Or you could have a game that blends the two - 2D sprites in a 3D environment, 3D models on a 2D plane... those are probably the only two options to be honest.
You could even have fully 3D game but viewed from such a perspective that it looks like a 2D game - the most recent Pokemon games seem to be like this (though the characters could be 2D sprites, it is difficult to tell.)
Since I know next to nothing about 3D programming, I'll focus on 2D for the sake of familiarity and simplicity.
For 3D games you'd probably want a camera class, but this also goes for 2D games.
Though the camera will likely be following the main character, perhaps all of the time, it can be more complex depending upon how the game world works.
Think of Link's Awakening on the GameBoy, or the Minish Cap - the world is split in square areas. Large square areas, bigger than a single screen, but they have borders. When Link approaches a border, if the camera is centred on him constantly, then the game would have to display what is outside the area. If not properly controlled, it could show the contents of some other bits of memory.
The game could be set to only display black outside of each map (so, make it place the maps in the centre of a large piece of black that is generated by the game itself) - this would take up processing power, which may or may not be cheap.
You could design each map and have a big black border around the side of it (assuming that the maps are saved images, rather than generated on the fly using a tileset) - this would cost storage space, which may or may not be cheap.
Another solution would be to make the camera centre on the character, but to never cross the border of a map - this would require that the map somehow conveys what its borders are and would be much easier if the maps were uniformly rectangular.
A final solution would be to make the maps wrap, but this would only really be sensible if the game world was open and not a set of isolated maps.
Also, perhaps worth some brief contemplation - will the camera make the engine render only what the camera sees, or does it simply display what is rendered within a small space. I'd think the latter, though the former is probably possible (just not obviously sensible.)
Next I might as well consider maps. In 3D games they tend to be meshes with textures stretched over them, so you could have one mesh landscape with a single texture over it per map, but this is a silly option.
A better option would probably be to have maps made up of different 3D models placed together, intersecting.
But enough of that, let's focus on 2D.
The way I see it you have two main options:
A single image per map. Though this is a misnomer of sorts - how would you account for solid objects? One solution is to use what is referred to as a "hardness map" - another image using particular colours so that the game came determine what you can and cannot walk through. This of course means that you have at least two images per map.
You could perhaps still do this, but have all solid objects (or objects that would result in particular interactions, for example water) as sprites.
If storage is an issue and you plan to have many maps, this may not be the best solution.
The second idea is to use what is referred to as a "tile set" - simply a set of tiles which can be used to create maps. In many cases I think I've just seen this as a tool for creating the single images as mentioned above, but you could use it another way.
You could use something like xml for each map (which, since it would be unformatted text, would be small in file size) which maybe would say the name of the set it will use, the dimensions of the map, and the tiles.
As an example, if you have a set consisting of 8 tiles and a map which is 2x2 (and each tile is, say, 32 pixels square) this could be described as:
[tileset]"set1"[/tileset]
[size]
[tile]32[/tile]
[height]2[/height]
[width]2[/width]
[/size]
[map]1,2,2,1[/map]
Or something like that. There would probably be a more sensible way to describe which tile goes where, but I think I made my point. A file like this would be 117 bytes (in windows), where the equivalent image (I just quickly tested in GIMP) was about 34.2 kilobytes - roughly 299 times larger (though some of that will be offset by including the tile set, so this is probably only a good idea when you have many many maps.)
Not only is this obviously better in terms of storage, but this method is highly adaptable - the information can be arranged in any way and new functionality that is part of the maps can be easily added without needed to carefully alter an image.
However, if the maps are too big this might impact processing power too much, so the designer should take care.
Another consideration is the sprites in a game.
Now, I cannot think of any way around this problem - no matter what you will need a lot of images. From some tools I've used this is normally done in the form of a sprite set - so, rather than needing many many smallish images, you can have one large image per character (or per character type if they are going to be used multiple times.) This will cut down on storage marginally, but also increase processing somewhat.
These would be used much like the tile set, except you would only display one at a time. By having a series of sequential images you could do a character animation (though maybe storing them as animations could be a better solution.)
The only major problem with this is if the sprite will ever change in size - they might be 32x32 for most of the time, but then for some actions get larger, which would mean all of the other images would need to be larger, increasing file size greatly - so, basically, if the character images (for one character) are going to be similar in size, a sprite set is the way to go; if the character is ever going to change in size, then separate images is the way to go.
Collision detection could also prove to be a problem - if the character images are stored in blocks with some blank space around them, then the game would need to understand not to report a collision if the blank space is hit - using a uniform background "ignore" colour is probably the best way to go, but the game would also need to make sure that colour is not displayed, so would need to either not draw it or convert it to transparency. Either way, processing is probably going to increase.
On that note - characters. Each character will obviously have a sprite, but what other aspects should they have?
In many RPGs you will have characters you can talk to but cannot kill, or even attack. If any fights are going to be separate to the talking mechanisms (i.e. in the Final Fantasy games where you would normally be talking when viewing the game from one perspective, but in battle be on a special map from a different viewpoint) then you could either have two separate characters (one for outside battle, one for inside) or have one character with two different sprites (in and out of battle.)
If it is more of an action oriented game (e.g. Zelda) you could stop the player from being able to attack in certain areas and you would populate the areas with such NPCs. Other games in the same series don't stop you from being able to attack, but have no collision detection from your weapons activated on such characters.
Or you could go the route of Elder Scrolls and give everyone every single statistic and just make everyone killable.
Though this may seem to be only applicable to RPGs or Action RPGs, but it could also extend to other genres - platformers, or even top-down-shooters (perhaps first person shooters, but that is a bit harder to imagine) - heck, even GTA kind of goes the Elder Scrolls route, it just has fewer stats.
Assuming you go any route but the latter, a class hierarchy could be like this:
Character (has a sprite)
/ \
NPC | Enemy (also has a battle sprite and stats)
But then what of the player character? It seems like it could be a subclass of enemy. Also, what of Enemies that you won't encounter in the field? Perhaps their "character" sprite could be null - as long as it is never called then everything should be fine.
Maybe then a better structure would be:
Character
/ \
NPC | Statted (or a better name)
/ \
Enemy | PlayerCharacter
That's all I can come up with for now.
PS: I note that the class diagrams are bad at the moment, but having worked on this post for about 90 minutes now, I have run out of steam.
Subscribe to:
Posts (Atom)