Sign in to follow this  
joanusdmentia

Game engine design & motivation

Recommended Posts

I have an incredibly bad habit of not bothering to sit down, plan and design before hitting the keyboard and coding. I'll try and stick it out every now and then, but my impatience has always gotten the better of me and the few scraps of paper on which my excuse for a design was on get tossed into the corner. As a result, we can all guess how many games I've managed to produce :) Well I'm starting to get sick of having short term results but not getting any results in the long term. It's certainly not for a lack of skill, to be honest I consider myself a damn good programmer and the code I do produce tends to be fairly well structured. The problem is that because I don't have it all down in front of me I tend to loose focus, go off on tangents and before I realize it I've gotten so sick of going around in circles that I just delete it and start again. So this time....(come on, say it with me [smile])...this time it'll be different, or at least that's what I'll keep telling myself. I'm going to put the keyboard down and actually design my engine, aptly named the Kaos engine. The way in which it will be different though is different...hmm, too many differents....anyway, this will be purely an exercise in game engine design. In other words, there will be no limiting factors on the design such as 1 person not realistically being able to do it in anything under 10 years. [smile] I've decided on genre...good ol' FPS, although I'm going to try and keep the engine as general as I can, this will be my main focus. I've decided on language and platform...C# and Windows, keeping any Windows specific code together so I can at least entertain the idea of cross-platform if Mono proves to be viable for games. I'm still undecided as to whether I should go with an OpenGL (probably through Tao if I do) or managed DX, any advice here would be appreciated (I've worked with both). Keeping true to form with FPSs I always want to allow for a multiplayer, most likely client/server but I've also been thinking about distributing some processing to clients such as running the AI and physics on several different clients. AI will be agent based and controlling avatars in the world through the same interface as user input so this shouldn't cause any major dramas, however I'm unsure about whether it's better to run physics and general game logic on client or server (or both?). Another issue with multiplayer will be the paths that data takes through the engine. For example, when the user moves forward will the movement code update the scenegraph and tell the server? Should the movement code just tell the server? (I can already see pitfalls with this one) Should the scenegraph be responsible for informing the server of any local changes? I'm leaning towards the later approach, although filtering unnecessary data might prove interesting. Now while this is all very preliminary I'd appreciate comments on my thoughts to date, but that's not really the main reason I'm posting. What I'm wondering is how the hell do you keep motivated during the design phase, when the best you're getting out of it is nothing more out of it than a couple of UML drawings?

Share this post


Link to post
Share on other sites
Yeah, me too. I'm 14 so I don't really feel like designing either. My engine is very well structured and I would say that I am by now a pro, but I find just adding more features to my engine is much more fun than making a game!

Share this post


Link to post
Share on other sites
You may find this discussion useful.

All I can speak about is my own experience, I've tried creating 3 engines now and I must say that they all ended up as a failure. They spiralled out of control fairly quickly and worse, my coding styles changed mid-way through so I ended up with strange code. By trying to make it as generic as possible I fell apart quickly. Personally, I'd suggest (based on my own experience and advice offered in the thread I just linked) that instead of trying to build the all encompassing engine, you build up your library of common components that can be reused across games. I'd also say that you build a 'game' and not an 'engine', mainly because you will have focus and see your results immediately. Building a game also allows you to build the important glue code between systems, often this is the part in my engine designs that has come unstuck.

In the words of a personal hero of mine, Chris Hargrove - author of the Code on the Cob series and engine guy supreme...

Quote:

It is actually possible (and quite feasible) to combine both the "only coding what you need to" approach and the "building an engine/framework/infrastructure" approach. The catch is that you can't combine them in the same system for the same project. It takes multiple projects, and the experience of those multiple projects, to allow this to happen effectively.


Basically he's hinting that you will find it difficult to start straight out on an engine without a game to work towards, essentially your generic engine is evolved over time by reusing common components created in past projects.

Hope this helps and good luck in whichever way you try to do things. [smile]

Share this post


Link to post
Share on other sites
I've been designing my engine for the last 7 months. I only wrote the first line of code I'll be using in the thing two days ago. The massive amount of planning I've done has given me a much better picture of how this thing will actually work. Quite frankly, I don't think I could have written an engine that would have functioned at any reasonable level without doing this planning. I felt I "knew enough" to start doing the coding about 3 months back, but I decided to hold off and do it right. Well, in that time I've totally redesigned half the engine. While there were a few critical flaws I resolved, most of the work was simply improvements in the core design. I thought of much better ways of doing a lot of things, and I worked those into the engine. I also expanded my knowledge and planning in areas that were a little bit brief in the design specs, and that allowed me to get a better appreciation of how that component should interface with the rest of the engine.

Had I started coding, I would've run into these issues during the build phase, and while it's not too hard to change some specs when they're on paper, it would have been a nightmare to change the code. I basically would have had to scrap most of it and start again, as many of these were at the core of my design.


As for keeping yourself motivated, well I've always been a very motivated person, but I must say, working for months and months on end, and only having a stack of notes to show for it does test your resolve, especially when you've got another guy on the team showing off the music he's done, or the models he's built, and all you can say is "I got more stuff designed today". I really want this thing to be done right though, so I want to do it once, and do it thoroughly. Besides, I figure every minute I spend in design is four I save in the build process, so it's good to remember the planning will pay off later on.

Share this post


Link to post
Share on other sites
Planning beforehand should be done on a very high level, because it's really hard to get all the nitty gritty details right before you set off coding an engine. My last engine is being written as a basic system framework with external libraries (plugin-style) to do all the specific operations. For example, by using the same display-, shader-, texture- and image-libs and just changing the world representation from say BSP/PVS to top-down isometric, I got a new base to work on for a new type of game. This is useful for networking too, because if I figure out a better way to route information between clients and servers, I update the external networking libraries and so the game plus the engine are all left intact. This is of course possible in pretty much any well-designed engine, the key is to make modules communicate rather than merge them and communication is a part of plugins.
Either, try to figure everything out now to the bone and make sure your solution will work in all cases, or start out with a clever idea and hope it could be easy to change ([smile]), or design your engine to easily allow switching networking code.

Share this post


Link to post
Share on other sites
Quote:
Original post by evolutional
You may find this discussion useful.

For some reason I wasn't following that one, thanks.

Quote:
Original post by evolutional
All I can speak about is my own experience, I've tried creating 3 engines now and I must say that they all ended up as a failure. They spiralled out of control fairly quickly and worse, my coding styles changed mid-way through so I ended up with strange code. By trying to make it as generic as possible I fell apart quickly. Personally, I'd suggest (based on my own experience and advice offered in the thread I just linked) that instead of trying to build the all encompassing engine, you build up your library of common components that can be reused across games.

As a general rule I manage to avoid the "I want my engine to do everything from solitare to HL2", however I do tend to be a bit of a perfectionist. I've lost count of the number of times I've written, re-written, deleted and written again, restructured and changed interface for just a bloody Matrix class! For this reason trying to build up a library of components is actually a step backwards for me, I'd end up doing nothing but rewritting the same code over and over to get it that little bit better (not necessarily performance-wise either).

Quote:
Original post by evolutional
I'd also say that you build a 'game' and not an 'engine', mainly because you will have focus and see your results immediately. Building a game also allows you to build the important glue code between systems, often this is the part in my engine designs that has come unstuck.

Personally I'm more drawn towards the creation of the engine than the game itself. Besides, I'm making this purely a design exercise as an attempt to force myself to sit down and actually design rather than code, so either way there'll be no pretty pictures on the monitor to look at....and no, UML diagrams do *not* count as pretty pictures :)


Quote:
Original post by Nemesis2k2
I've been designing my engine for the last 7 months. I only wrote the first line of code I'll be using in the thing two days ago. The massive amount of planning I've done has given me a much better picture of how this thing will actually work. Quite frankly, I don't think I could have written an engine that would have functioned at any reasonable level without doing this planning.

7 months, no code...you're not helping :P

Quote:
Original post by Nemesis2k2
I felt I "knew enough" to start doing the coding about 3 months back

Boy, does *that* one sound familiar :)
I don't think it's so much a case of "knowing enough", but rather knowing to step back and look at the bigger picture. As much as you try you're never going to be able to do that without doing all of the planning before hand so that it's there in front of you when you need it, and despite my continued efforts to disprove this I've failed miserably :)

Share this post


Link to post
Share on other sites
joanusdmentia,
I decided to do the same exact thing you are and I have the same problem with keeping myself motivated through the design process. The solution that works be for me is the thing that someone already suggested. Which is to write a game and design the components to be very reusable. That seems to work the best for me.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this