The biggest hindrance in making a game engine is finding time. I essentially have none. I have no time for this blog or for fixing bugs or adding features to my game engine. I'm not sure what the solution is.
I can say with some certainty that the approach I've taken of making the uber engine from start to finish is probably not the right one. I'm going on 9 months of this current engine iteration and although I think it's got good points it's not functional. Physics breaks and I'm redoing the camera system for the millionth time sigh...
Probably it's smarter to work with an existing engine and build in the points that you want to focus on. I think most people focus on gameplay. I suspect I will never get that far. Maybe one day.
If anyone was following this blog because they wanted to learn about engine development they should probably be discouraged reading this. Good thing nobody follows it.
Monday, June 22, 2009
Tuesday, May 19, 2009
Ping
Hello world. It's been several months since my last post but it's time to try again. I keep meaning to update this but it's hard to find time.
This is a link to my current engine development. I think it's pretty cool but it obviously has a long way to go. Hopefully people can start to see how a game can be made with it.
http://www.wuala.com/GarethCox/hulkengine/hulkengine%20May%2019%202009.avi
Cheers
This is a link to my current engine development. I think it's pretty cool but it obviously has a long way to go. Hopefully people can start to see how a game can be made with it.
http://www.wuala.com/GarethCox/hulkengine/hulkengine%20May%2019%202009.avi
Cheers
Monday, January 12, 2009
Engine Design
Ultimately I want to use the Hulkengine to very rapidly make games like the recent remake of bionic commando or galaga etc. Too that end I've focused on simplicity as the driving motivation. Performance and flexibility are secondary issues. This is not to say that I don't consider performance or flexibility because I do. Too much as a matter of fact. It is just that when push comes to shove simplicity comes first. In the battle between flexibility and performance again performance comes in second. My thinking is that so long as the game engine is of reasonable quality I will be hard pressed to get enough content to truly push the performace envelope. Plus if I try to push the performance envelope I will never actually create anything. You can only push the performance/technology envelope if you focus on one particular area. As the sole author of the entire hulkengine that is not feasible.
So how do I keep my engine simple? Well the basic answer is to write lots of little libraries that do one thing. Then take those little libraries and put them under unit test so that I have some moderate assurance of their functionality. I'll admit I use unit tests almost as documentation on how to use my libraries more so than for verification. This is mostly because I'm new to the unit test world and because I'm lazy. Whenever I discover a bug or think there might be a bug I usually write a unit test to look for it. Writing unit tests has changed the way I code and I believe mostly for the better. Point is you should use unit testing.
The libraries themselves are as self contained as possible. Some like the math and data libary I use in other libs but generally I prefer to duplicate code rather than add dependancies. That's right. I'll say it again. I prefer to duplicate code rather than add dependancy. This is a recent fad with me but I think it makes sense. I want each of my libraries to be self contained packets of functionality. If library A depends on B and B on C and so on then any time I write an application I have to link to every single thing. I suppose this isn't the end of the world but it's complicated and over time increasing dependancy between the two libs will make them uttery inseperable. Alternatively you can interface everything and have complexity and waste where none is needed. I think the phobia against code duplication is well founded but my desire for libs with zero or very limited dependancy is stronger.
Wrap each library in a namespace. This makes it very simple to know where code is coming from. Along with header paths and namespaces code becomes significantly simpler and easier to trace. Unfortunately namespaces tend to temp you to name things the same across projects. So I might have graphics::allocator interface and scene::allocator interface. Unfortunately this doesn't play nice with visual assist so despite the fact that with the namespace it's reduntant I would recomend still prefixing your classes. I don't but then I pay the price when visual assist fails. It's annoying and often I wish I had bit the bullet and prefixed classes. On a quick note get visual assist if you use visual studio. It's a time saver.
Consider what the API is for your library. You don't want to expose any more than is absolutely necessary. This is a great way to simplify your code. You can have some fantastical scene graph lib but if you create a clean API to use that library then you've really accomplished something. Try to export handles to objects rather than objects themselves when possible. So if you have a graphics library that loads textures don't expose the texture pointer external to the library. Expose a handle for tracking that texture and manage the texture internal to the lib. That said do not not use singletons or globals in your library. This will be a non-starter on many projects so make sure that you allow users to create and maintain your manager structures.
Ok well I'll continue this post later. This is tiring.
Gareth
So how do I keep my engine simple? Well the basic answer is to write lots of little libraries that do one thing. Then take those little libraries and put them under unit test so that I have some moderate assurance of their functionality. I'll admit I use unit tests almost as documentation on how to use my libraries more so than for verification. This is mostly because I'm new to the unit test world and because I'm lazy. Whenever I discover a bug or think there might be a bug I usually write a unit test to look for it. Writing unit tests has changed the way I code and I believe mostly for the better. Point is you should use unit testing.
The libraries themselves are as self contained as possible. Some like the math and data libary I use in other libs but generally I prefer to duplicate code rather than add dependancies. That's right. I'll say it again. I prefer to duplicate code rather than add dependancy. This is a recent fad with me but I think it makes sense. I want each of my libraries to be self contained packets of functionality. If library A depends on B and B on C and so on then any time I write an application I have to link to every single thing. I suppose this isn't the end of the world but it's complicated and over time increasing dependancy between the two libs will make them uttery inseperable. Alternatively you can interface everything and have complexity and waste where none is needed. I think the phobia against code duplication is well founded but my desire for libs with zero or very limited dependancy is stronger.
Wrap each library in a namespace. This makes it very simple to know where code is coming from. Along with header paths and namespaces code becomes significantly simpler and easier to trace. Unfortunately namespaces tend to temp you to name things the same across projects. So I might have graphics::allocator interface and scene::allocator interface. Unfortunately this doesn't play nice with visual assist so despite the fact that with the namespace it's reduntant I would recomend still prefixing your classes. I don't but then I pay the price when visual assist fails. It's annoying and often I wish I had bit the bullet and prefixed classes. On a quick note get visual assist if you use visual studio. It's a time saver.
Consider what the API is for your library. You don't want to expose any more than is absolutely necessary. This is a great way to simplify your code. You can have some fantastical scene graph lib but if you create a clean API to use that library then you've really accomplished something. Try to export handles to objects rather than objects themselves when possible. So if you have a graphics library that loads textures don't expose the texture pointer external to the library. Expose a handle for tracking that texture and manage the texture internal to the lib. That said do not not use singletons or globals in your library. This will be a non-starter on many projects so make sure that you allow users to create and maintain your manager structures.
Ok well I'll continue this post later. This is tiring.
Gareth
Subscribe to:
Comments (Atom)
