The Game Editor has some a long way, but it still has a long way to go. If you are curious about how it is coming along, you are welcomed to download the development preview from the following link:
Game Editor Development Preview
Please keep in mind a few things when you download and test this out. You will need the .NET Framework 3.5 client installed for the software to run. You can get this from Microsoft at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21
Additionally, this is a development preview, so functionality of the software is a work in progress. Many functions and menu items are non-functional, so if you click them and they do nothing, that's why. Saving and Opening projects is very experimental, so many times it won't work properly. There is also the possibility of the publish game function damaging files or folders wherever you point it to compile to...I wouldn't recommend using it. It does warn you that the contents of the provided folder will be deleted, so you will be informed before anything dangerous happens.
Well, that's enough dire warnings. Download the engine and play around with it! There is no in-program help available, so just experiment. I'll give you one heads up about the map editor. To select what tiles get painted where on the map editor, you must first create a tile set and import images into it. Then click to select a tile and then click to paint that tile in the map editor. There is a lot of broken functionality there, and I'm working on that soon.
Sunday, June 26, 2011
Saturday, June 25, 2011
Game Editor Update
Development on the game editor has been chugging along nicely now.
The editor breaks the game down into logical folders. These folders are there only to help conceptualize the game you are making, and don't actually have any bearing on the engine itself. Here's how it is coming together so far.
General: Here you adjust basic editor settings such as the preferred file export format, and the start up script.
Tile sets: Here you import tiles for use in maps and just about all other rendering in the game. Images linked into collections to help you organize your media. There are no such things at tile sets once the game has been compiled, as the engine will see it all as a list of images in the end.
Maps: Depending on what kind of game you are making, maps will be used in different ways. For most game types, maps will be the levels, world, or zones of the game. Your characters and other in game objects will be oriented on a map, and the player will see the maps like zones in your game. Maps are a grid of tiles. Think of a Chess board, except of any arbitrary number of rows and columns, and each "block" can be colored by a tile from a tile set to construct the world, piece by piece.
Sprites: think of sprites as animated objects. You can use a sprite for your characters, or for buildings, monsters, trees, or even entire levels if you so choose. Sprites consume much more processing time in the game engine to handle than maps, so if you are planing on making a world out of sprites, consider maps instead... Sprites are built up of animation sequences, each with its own name. Each animation sequence has a list of directions associated with it, and each direction has a list of images. For example, say you want your main character to walk north, you would set your sprite to use animation sequence "Walk" and direction "North", then tell it where to go. The sprite will automatically animate the movement based on the images associated with this sprite. There is more to it than that, but you probably get the idea well enough for now.
Sounds: Every good game has sound in one way or another. Sounds can be anything from sound effects of gun shuts, sword slashes, car tire screeches, or explosions. The background music for the town your character walks around in will be considered a sound too.
Scripts: here is the real meat and potatoes of your game. Scripts are responsible for every conceivable action that your game will take. A start up script (Which you specify in the general options) will be responsible for loading up basic resources needed by your game, such as main menus, character animations, sprites, etc. The scripts will be responsible for coordinating everything that goes on in the game, and a powerful language is being developed to make this process as simple as possible, while still allowing the greatest flexibility. Many more of these blog posts are to come that will talk about scripts, so stay tuned.
The game editor also now supports saving and loading project files. Nothing ruins my day more than building a sample game, testing it out, needing to make one change, but being required to develop the sample game all over again from scratch because there is no save/load button. Well, now there is, and it works quite well.
More is to come on the editor, as development continues. Stay tuned!
The editor breaks the game down into logical folders. These folders are there only to help conceptualize the game you are making, and don't actually have any bearing on the engine itself. Here's how it is coming together so far.
General: Here you adjust basic editor settings such as the preferred file export format, and the start up script.
Tile sets: Here you import tiles for use in maps and just about all other rendering in the game. Images linked into collections to help you organize your media. There are no such things at tile sets once the game has been compiled, as the engine will see it all as a list of images in the end.
Maps: Depending on what kind of game you are making, maps will be used in different ways. For most game types, maps will be the levels, world, or zones of the game. Your characters and other in game objects will be oriented on a map, and the player will see the maps like zones in your game. Maps are a grid of tiles. Think of a Chess board, except of any arbitrary number of rows and columns, and each "block" can be colored by a tile from a tile set to construct the world, piece by piece.
Sprites: think of sprites as animated objects. You can use a sprite for your characters, or for buildings, monsters, trees, or even entire levels if you so choose. Sprites consume much more processing time in the game engine to handle than maps, so if you are planing on making a world out of sprites, consider maps instead... Sprites are built up of animation sequences, each with its own name. Each animation sequence has a list of directions associated with it, and each direction has a list of images. For example, say you want your main character to walk north, you would set your sprite to use animation sequence "Walk" and direction "North", then tell it where to go. The sprite will automatically animate the movement based on the images associated with this sprite. There is more to it than that, but you probably get the idea well enough for now.
Sounds: Every good game has sound in one way or another. Sounds can be anything from sound effects of gun shuts, sword slashes, car tire screeches, or explosions. The background music for the town your character walks around in will be considered a sound too.
Scripts: here is the real meat and potatoes of your game. Scripts are responsible for every conceivable action that your game will take. A start up script (Which you specify in the general options) will be responsible for loading up basic resources needed by your game, such as main menus, character animations, sprites, etc. The scripts will be responsible for coordinating everything that goes on in the game, and a powerful language is being developed to make this process as simple as possible, while still allowing the greatest flexibility. Many more of these blog posts are to come that will talk about scripts, so stay tuned.
The game editor also now supports saving and loading project files. Nothing ruins my day more than building a sample game, testing it out, needing to make one change, but being required to develop the sample game all over again from scratch because there is no save/load button. Well, now there is, and it works quite well.
More is to come on the editor, as development continues. Stay tuned!
Friday, June 24, 2011
Game Editor
My original plan was to write the game engine, then create a game editor that would assist developers in creating games for said engine. However, it is hard to write a game engine when all of the test data (levels, characters, scripts, animations, etc) all have to be hand created for each test build, and as you might imagine, it gets tedious too.
It seems only logical that I should develop the game editor alongside the game engine, that way I can be sure they are compatible with each other. Most importantly, I can create test game object in the editor, and then run them in the game engine and make sure everything is working as expected.
Therefore, I've decided to temporarily suspend the development of the game engine until after the game editor catches up with it. I'm not TOO far along that it will significantly delay anything, and the way I look at it, nobody will be able to make anything for the engine without an editor anyway, so you'd have to wait anyhow.
The good news is, I have a really good idea for how I want this editor to work. I'm thinking about making it a model form, meaning that it can have children windows. The main windows will have a tree view on the left with categories of objects, like windows explorer folder view. To do anything, you would open a folder for an object type (such as tile sets), then a list would appear under that of tile sets you've created and saved. You could double click one to open it up, then import images into the set.
After a tile set has been created, you can create a new map. To draw tiles onto the new map, click the tile you want to paint in the tile set window, then click to draw that tile in the map editor.
Sprites will be similar, except they will be broken down into actions (such as walking, standing, attacking, getting hit, dying, etc) and then further into directions (north, south, east, west, etc). Then you will import a series of images that will be looped for each direction. There are a lot of options here that will need to be set, such as where in the image does the characters feet stand at, and what color should be regarded as transparent.
Scripts are possibly the hardest thing to implement. Instead of making you type in scripts in the low level game scripting language (not fun, by the way), you will be presented with a text editor, and you can type in an actual scripting language. This gets compiled into the low level language when the game is packaged for deployment (compiled).
The beauty of this is instead of referring to objects by their game engine ID number, you will be able to declare variables of each game engine class type, such as a character sprite, or a map, and refer to them as such in the scripts. You will be able to refer to maps, sprites, etc, using the names you gave them in the editor (such as world.map, OzarkCanyon.map, hero.spr, and such), instead of assigning a file name to a register index, and having to refer to it as some abstract number from there on out.
For right now, I'm aiming to get at least the functionality down that I have been able to manually code in notepad, and make it so that the editor can save and load projects so I can continue working on them after stopping and closing the editor session.
Once this is accomplished, I will return to developing the engine, one little piece at a time. Only at that point, I'll be able to test these components As I develop them.
It seems only logical that I should develop the game editor alongside the game engine, that way I can be sure they are compatible with each other. Most importantly, I can create test game object in the editor, and then run them in the game engine and make sure everything is working as expected.
Therefore, I've decided to temporarily suspend the development of the game engine until after the game editor catches up with it. I'm not TOO far along that it will significantly delay anything, and the way I look at it, nobody will be able to make anything for the engine without an editor anyway, so you'd have to wait anyhow.
The good news is, I have a really good idea for how I want this editor to work. I'm thinking about making it a model form, meaning that it can have children windows. The main windows will have a tree view on the left with categories of objects, like windows explorer folder view. To do anything, you would open a folder for an object type (such as tile sets), then a list would appear under that of tile sets you've created and saved. You could double click one to open it up, then import images into the set.
After a tile set has been created, you can create a new map. To draw tiles onto the new map, click the tile you want to paint in the tile set window, then click to draw that tile in the map editor.
Sprites will be similar, except they will be broken down into actions (such as walking, standing, attacking, getting hit, dying, etc) and then further into directions (north, south, east, west, etc). Then you will import a series of images that will be looped for each direction. There are a lot of options here that will need to be set, such as where in the image does the characters feet stand at, and what color should be regarded as transparent.
Scripts are possibly the hardest thing to implement. Instead of making you type in scripts in the low level game scripting language (not fun, by the way), you will be presented with a text editor, and you can type in an actual scripting language. This gets compiled into the low level language when the game is packaged for deployment (compiled).
The beauty of this is instead of referring to objects by their game engine ID number, you will be able to declare variables of each game engine class type, such as a character sprite, or a map, and refer to them as such in the scripts. You will be able to refer to maps, sprites, etc, using the names you gave them in the editor (such as world.map, OzarkCanyon.map, hero.spr, and such), instead of assigning a file name to a register index, and having to refer to it as some abstract number from there on out.
For right now, I'm aiming to get at least the functionality down that I have been able to manually code in notepad, and make it so that the editor can save and load projects so I can continue working on them after stopping and closing the editor session.
Once this is accomplished, I will return to developing the engine, one little piece at a time. Only at that point, I'll be able to test these components As I develop them.
Subscribe to:
Posts (Atom)