Well, for those of you who don't know, I live in Joplin, MO, and an EF5 tornado came through on 22 May 2011 @ about 5:30 CDT. Our house is fortunately undamaged, but we went without power for a week, which makes it hard to work on the computer.
However, I have made some improvements to the game editor. The Map drawing feature now works, so it is now possible to create maps using tile-based map editing. Also, the tile importer works, but I'm still trying to figure out how I want the tile editor to work, so for now tiles have to be created in a seperate editor, like MS Paint, and imported.
Next up is collision boundary integration, I think. I'll play that by ear as development requires it.
I hope to have more updates comming soon now that our power is back online!
Monday, May 30, 2011
Monday, May 9, 2011
Game Engine overview
When working on a game, it is important to know how your ideas will be integrated into the whole of the project. With this in mind, I've decided to write a few articles highlighting the internal functioning of the game engine. I'll start with an overview of the core engine, and fill in details as necessary. Keep in mind that these are design concepts, and some of the functionality listed here is not implemented fully yet.
Program start:
Load localization settings
Locate and load startup scripts
Query graphics adapter properties
Set main window settings, and set up graphics/audio device for rendering
Main Engine Loop:
Get keyboard/mouse inputs
Get network packets
Execute scripts
Update sprite animations
Update vectors/state data
Send network packets
Render audio
Render graphics
End Main Engine Loop
Cleanup loaded game resources
Release graphics/audio adapters
And now for the explanations.
Load localization settings:
Different regions of the world process data differently, and display it to users differently. For example, some places use commas for digit grouping, and others use a period. These settings are saved in the operating system, but we have to retrieve them in order to use them. This happens here. Also, translation files are loaded at this point.
Locate and Load startup scripts:
Because I want the engine to be as customizable as possible, all game engine activity will be governed by scripts, including the startup and initialization of the engine itself. The script engine will be responsible for setting up the graphics and audio adapters, including choosing display resolutions and setting audio sample rates.
Query graphics adapter properties:
At this point, the engine will collect a list of adapters and possible resolutions and color depths that can be used.
Set main window settings, and set up graphics/audio device for rendering:
The control of the engine is turned over to the script engine at this point. The script directs setting display properties, and getting the hardware ready for the game.
Get keyboard/mouse inputs:
Once every game frame, keyboard and mouse states are updates, and if a controller/joystick are in use, the states of them are pulled.
Get network packets:
If a script has initiated the network adapters, then at this point any newly received packets are processed, decoded, and the data is fed into the script engine ready for processing.
Execute scripts:
This is where the real work gets done in the engine. The script engine is in charge of loading resources, discarding them, and all internal workings of the game's finite-state machine. This part of the engine is by far the most complex, and therefore I'll write a separate article about it later.
Update sprite animations:
Many of the commands in the script language are dedicated to making it easier to write games. Many of them are aimed at automating many things in the game, including sprite animations. Those are handled here.
Update vectors/state data:
Just like the sprite animations, many commands handle automated motions (vectors). These are updated here.
Send network packets:
If the network is in use, once all of our state data is processed, we then transmit any updates to this to connected client games.
Render audio:
Any sound effects that have been triggered will be started here, and any background music that is playing will be updated as well.
Render graphics:
Now that all of the state data have been updated, we can begin rendering the graphics. This is by far the most processor time consuming part of the game engine. An article will be devoted to this later.
Cleanup loaded game resources:
Once the scripts indicate the game should close, all the resources that have been loaded will be cleaned up, and all processing threads will be asked to close.
Release graphics/audio adapters:
All graphics/audio adapter resources that have been allocated will be released at this point.
I'll write articles later on that cover the more detailed processes, specifically the network engine, graphics rendering, and the script engine.
Program start:
Load localization settings
Locate and load startup scripts
Query graphics adapter properties
Set main window settings, and set up graphics/audio device for rendering
Main Engine Loop:
Get keyboard/mouse inputs
Get network packets
Execute scripts
Update sprite animations
Update vectors/state data
Send network packets
Render audio
Render graphics
End Main Engine Loop
Cleanup loaded game resources
Release graphics/audio adapters
And now for the explanations.
Load localization settings:
Different regions of the world process data differently, and display it to users differently. For example, some places use commas for digit grouping, and others use a period. These settings are saved in the operating system, but we have to retrieve them in order to use them. This happens here. Also, translation files are loaded at this point.
Locate and Load startup scripts:
Because I want the engine to be as customizable as possible, all game engine activity will be governed by scripts, including the startup and initialization of the engine itself. The script engine will be responsible for setting up the graphics and audio adapters, including choosing display resolutions and setting audio sample rates.
Query graphics adapter properties:
At this point, the engine will collect a list of adapters and possible resolutions and color depths that can be used.
Set main window settings, and set up graphics/audio device for rendering:
The control of the engine is turned over to the script engine at this point. The script directs setting display properties, and getting the hardware ready for the game.
Get keyboard/mouse inputs:
Once every game frame, keyboard and mouse states are updates, and if a controller/joystick are in use, the states of them are pulled.
Get network packets:
If a script has initiated the network adapters, then at this point any newly received packets are processed, decoded, and the data is fed into the script engine ready for processing.
Execute scripts:
This is where the real work gets done in the engine. The script engine is in charge of loading resources, discarding them, and all internal workings of the game's finite-state machine. This part of the engine is by far the most complex, and therefore I'll write a separate article about it later.
Update sprite animations:
Many of the commands in the script language are dedicated to making it easier to write games. Many of them are aimed at automating many things in the game, including sprite animations. Those are handled here.
Update vectors/state data:
Just like the sprite animations, many commands handle automated motions (vectors). These are updated here.
Send network packets:
If the network is in use, once all of our state data is processed, we then transmit any updates to this to connected client games.
Render audio:
Any sound effects that have been triggered will be started here, and any background music that is playing will be updated as well.
Render graphics:
Now that all of the state data have been updated, we can begin rendering the graphics. This is by far the most processor time consuming part of the game engine. An article will be devoted to this later.
Cleanup loaded game resources:
Once the scripts indicate the game should close, all the resources that have been loaded will be cleaned up, and all processing threads will be asked to close.
Release graphics/audio adapters:
All graphics/audio adapter resources that have been allocated will be released at this point.
I'll write articles later on that cover the more detailed processes, specifically the network engine, graphics rendering, and the script engine.
Graphics Designers Wanted
Hello again,
I've invited a co-author to join me on this blog: my brother Danny. He has a lot of great ideas for several games that we've wanted to make into a real games for years now. We are going to need graphics, lots of them.
He has all the ideas for how he wants the game to look, and I'm working on making the engine capable of running it. We'll try collaborating via this blog for now, but I'm willing to set up an actual message board forum if enough people request it, or if this blog does not work out well.
Let me know what you think in the comments.
I've invited a co-author to join me on this blog: my brother Danny. He has a lot of great ideas for several games that we've wanted to make into a real games for years now. We are going to need graphics, lots of them.
He has all the ideas for how he wants the game to look, and I'm working on making the engine capable of running it. We'll try collaborating via this blog for now, but I'm willing to set up an actual message board forum if enough people request it, or if this blog does not work out well.
Let me know what you think in the comments.
Sunday, May 8, 2011
VB.Net developer blog
Hello,
I've decided to start a blog where I can post my thoughts and some code related to the VB.Net game engine I'm developing.
For years, I've wanted to make my own video game. I want to make a MMORPG, or possibly an RTS game. However, ideas for such games are hard to come up with. So after giving it much thought, I've realized that it's not so much the game that I want to make, as it is the game engine that I really want to learn how to make.
Now, making a game engine is no trivial task, and I do not take it on lightly. I have given a great deal of thought for how a game engine could be made. Most game engines are targeted toward a specific genera, or type of game. For example, the Unreal engine targets first person shooters. I want my game engine to be generic enough to be used for nearly every conceivable game type. What I don't want is a VB.Net wrapper around an API. Microsoft already created that, and they called it XNA Game Studio. What I want is a game engine that actually automates as much as possible, and can be controlled with a relatively simple scripting language.
Since this is such a massive undertaking, I've decided to start small, and work my way up. In the interest of simplicity, I'll start out with a simple tile engine, and add sprites, keyboard and mouse input. Once this is working properly, I'll put together a network interface for both Client-Server (MMO type games), and peer-to-peer (for Lan type games). And finally, background music and sound effects.
Once this is all working, the engine will be ready to start developing games for.
I already have a good start on all of this, and am working on a game object editor to help simplify the task to testing the engine, and eventually this will be the official game editor for the engine.
Updates as they come...
I've decided to start a blog where I can post my thoughts and some code related to the VB.Net game engine I'm developing.
For years, I've wanted to make my own video game. I want to make a MMORPG, or possibly an RTS game. However, ideas for such games are hard to come up with. So after giving it much thought, I've realized that it's not so much the game that I want to make, as it is the game engine that I really want to learn how to make.
Now, making a game engine is no trivial task, and I do not take it on lightly. I have given a great deal of thought for how a game engine could be made. Most game engines are targeted toward a specific genera, or type of game. For example, the Unreal engine targets first person shooters. I want my game engine to be generic enough to be used for nearly every conceivable game type. What I don't want is a VB.Net wrapper around an API. Microsoft already created that, and they called it XNA Game Studio. What I want is a game engine that actually automates as much as possible, and can be controlled with a relatively simple scripting language.
Since this is such a massive undertaking, I've decided to start small, and work my way up. In the interest of simplicity, I'll start out with a simple tile engine, and add sprites, keyboard and mouse input. Once this is working properly, I'll put together a network interface for both Client-Server (MMO type games), and peer-to-peer (for Lan type games). And finally, background music and sound effects.
Once this is all working, the engine will be ready to start developing games for.
I already have a good start on all of this, and am working on a game object editor to help simplify the task to testing the engine, and eventually this will be the official game editor for the engine.
Updates as they come...
Subscribe to:
Posts (Atom)