One thing that all good game engines require is scripting support. Scripting is even useful for non game engine programs. Currently, there are limited options available in this department for most VB.net developers.
I started off using an extremely limited script system based on select-case and integer lists.
Basically, I have something like this:
'A single command line
Structure Command
Dim OpCode As Integer 'OpCode is the instruction to be executed
Dim Param() As Integer 'Param() is an optional list of arguments the command needs
End Structure
'A single user variable
Structure Variable
Dim VarName As String 'VarName is the name of the variable
Dim Data As Integer 'Data is the information stored in the user variable
End Structure
'A script, including local variables, code, and program counter
Structure ScriptObject
Dim Code() As Command 'List of commands the script is composed of
Dim Variables() As Variable 'List of variables used by the script
Dim PC As Integer 'Points to the next line of code to be executed
End Structure
Sub ExecuteScript(ByRef Script As ScriptObject)
With Sript.Code(PC)
Select .OpCode
Case 1 'Move a sprite Param(0) to location (X, Y), X=Param(1), Y=Param(2)
GPU.Sprites(.Param(0)).Location = New Point(.Param(1), .Param(2))
PC += 1
Case 2 'Sets Sprite Param(0), Visibility(Param(1) [0=False, 1=True])
GPU.Sprites(.Param(0)).Visible = IIf(Param(1) = 1, True, False)
PC += 1
Case Else
Throw New Exception("Command not implemented yet.")
End Select
End With
End Sub
As you can see, this method should work just fine, so long as the script engine doesn't need to be too terribly complex, and the number of OpCodes (possible different commands) is relatively limited. Now the real problem starts showing up when you try to implement Sprites, Meshes, animation, sound effects, network communications, background music, keyboard mouse and control input, reading and writing files, conditional branching, looping, and any number things that need to be implemented. Now consider writing scripts for this engine using columns of numbers, with no labels or other indications whatsoever for what they are for or do. Brings me to mind of early machine code programming (bleh). What happens when you make a typo on one of the switch statements, and the wrong command is selected, or not executed at all? Terribly difficult debugging, is what!
What I needed was a human readable, more flexible, and easier to work with scripting language. There are many different scripting languages available. Many game engines use LUA for its brevity and flexibility. However, LUA is extremely complex to implement. I thought I would start off small with an older, simpler language. For example, C.
So, now I'm working on a brand-new script engine based on C. C by itself is probably not sufficient to control a game engine, but I could easily add API extensions to give the script language control over elements of the game.
I would like the game engine to provide access to primitives, such as loading and displaying images, playing sounds, making tcp/ip connections to send and receive data, loading meshes and world grids, that sort of thing.
In my previous script methods, I would need to program every kind of function and command, every kind of game engine object, and every data processing method, into the game engine itself. This would greatly limit the things that can be done with the game engine to only the things I program it to be able to do...specifically, it would limit the game engine to only the things that I can imagine it should be able to do.
Offloading all of that processing to a C script would simplify developing the game engine, and more importantly it would allow the scripter to determine what the game engine can do instead of just me. Implementing a powerful scripting language would enable the game engine to run any kind of game the game designer can imagine.
But, how does one implement something so complex as C? I'd be lying if I wrote that I have all the answers to that, but I'm working on it. I'll be analyzing this problem over the next several weeks, and as I start to make breakthroughs, I'll be posting them here!
Saturday, December 31, 2011
Sunday, October 16, 2011
Full screen support!
Hooray! Update!
I've been very busy at work and school lately, but have managed to squeeze in some time to code. It took a great deal of work, but I finally managed to get VB.NET and XNA to play nicely in Full Screen mode. This process required me to build a formless class that inherits and implements XNA.Game. Unfortunately, this also means that it no longer inherits Windows.Form, so many of the things that I were doing for input and rendering are obsolete and no longer function. Oh well; by implementing XNA.Game the performance of the engine went WAY up, so that's good.
In the mean time, development of the game editor had to be suspended while I rework some of the code for the engine; no sense writing an editor for an engine that is about to be overhauled, now is there? But don't worry! While the engine is getting an overhaul, I'm removing many of the debug code I had to put in while in early development and implementing a new network engine I've been working on. Instead of only using TCP for network connections, I'm planning on a hybrid of TCP and UDP; TCP for game content distribution (such as downloading updates from a website or other server), and UDP for game client data (such as player movement updates, and other in-game network traffic). The general scripting language I'm working on has not changed much other than adding in a few new commands here and there, but I'm considering adding LUA support down the road. This will depend on developer interest, as personally I don't care at the moment what scripting language it uses, so long as it works!
More updates to come as development continues...
I've been very busy at work and school lately, but have managed to squeeze in some time to code. It took a great deal of work, but I finally managed to get VB.NET and XNA to play nicely in Full Screen mode. This process required me to build a formless class that inherits and implements XNA.Game. Unfortunately, this also means that it no longer inherits Windows.Form, so many of the things that I were doing for input and rendering are obsolete and no longer function. Oh well; by implementing XNA.Game the performance of the engine went WAY up, so that's good.
In the mean time, development of the game editor had to be suspended while I rework some of the code for the engine; no sense writing an editor for an engine that is about to be overhauled, now is there? But don't worry! While the engine is getting an overhaul, I'm removing many of the debug code I had to put in while in early development and implementing a new network engine I've been working on. Instead of only using TCP for network connections, I'm planning on a hybrid of TCP and UDP; TCP for game content distribution (such as downloading updates from a website or other server), and UDP for game client data (such as player movement updates, and other in-game network traffic). The general scripting language I'm working on has not changed much other than adding in a few new commands here and there, but I'm considering adding LUA support down the road. This will depend on developer interest, as personally I don't care at the moment what scripting language it uses, so long as it works!
More updates to come as development continues...
Sunday, June 26, 2011
Game Editor Development preview!
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.
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.
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.
Monday, May 30, 2011
Back up and running!
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!
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 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)