Sign in to follow this  

Graphics Engine Coding

This topic is 3874 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So here's the deal. I'd like to write a graphics engine from scratch. I'm not exactly interested in the gameplay aspect of it, but only in the experience I'll gain from writing something like that. I've done OpenGL before, written things such as terrain generators, hierarchical animation and various other crap without using anything but simple OpenGL, but it's nothing I'd be proud to show. I've also used Ogre for quite a while, and I like it to a certain extent, but using it is really no good for someone trying to get experience in the low level details. I'd like to write something that would follow healthy principles of engineering and that I could work on over time to expand it, to include shaders that I'd write myself, scripting, a console and other goodies that will make it a serious project. I don't really have any problems with writing anything complex and even if it is hardcore, that's good because I'll get to learn something interesting :) My real issue is what I want to write it in a proper way, not hack together some code and realize months later that the initial design totally sucked. It's impossible to come up with a good and flexible design for a thing such as a 3d engine when you have never done it before. I've been looking around for good resources for how to face this big task, hoping to find textbooks that would pertty much guide me in this task, but not exactly write it for me :P I found this book, even though i don't know if it's any decent: http://www.amazon.com/Game-Engine-Design-Second-Interactive/dp/0122290631/ref=pd_bbs_sr_2/102-0830581-3467301?ie=UTF8&s=books&qid=1178635351&sr=8-2 I would really appreciate if you guys could give me a few tips for where to start and where I could find resources for this. Things such as online guides and books would be fantastic. Thanks for your time, sorry for the long read :) Psicho.

Share this post


Link to post
Share on other sites
Yep I actually have designed my own 3D engine and I have that book.

That is a good one.

If you don't want to copy some one else's design though, approach it by looking at the reasons for the engine in the first place, the problems it is meant to solve, namely:

- Scene Management
- State Management

Those are pretty much the 2 big ones.

Then of course provide things like logging, texture management, timing, some sort of 2D windowing, some sort of either scripting or event system for game control, and you've got a basic engine.

Researching how those big two are suppose to work, then implementing stuff around them is generally a good idea.

Think of the Engine as an Operating system, it is there hide certain difficulties from the game programmers.

Share this post


Link to post
Share on other sites
Awesome tips, thx :)

So would it still make sense in your opinion to go through that book to see what approach the author is taking, or is his way somehow not too modern or just good in general?

Share this post


Link to post
Share on other sites
Quote:

I'm not exactly interested in the gameplay aspect of it

This is like saying you want to make a car, but aren't really keen on the drivability of it.

Quote:

My real issue is what I want to write it in a proper way, not hack together some code and realize months later that the initial design totally sucked.

Your design will suck. Live with it. You cannot get it right the first time.

Quote:

It's impossible to come up with a good and flexible design for a thing such as a 3d engine when you have never done it before.

Exactly. This directly contradicts what you just said though -- if you know its not possible to get it right the first time, why worry so much about it? That's what refactoring is for.

Quote:

I would really appreciate if you guys could give me a few tips for where to start and where I could find resources for this. Things such as online guides and books would be fantastic.

Eberly's book is an interesting read, but by no means definitive. There is no one way to build an engine properly; in fact, in the absence of requirements, you can't build a useful engine at all.

The best path towards developing an engine is to develop some games, and apply iterative refinement to the framework underlying those games. They don't need to be big games, they just need to be something playable. To sit down and try to design an engine from scratch in isolation is folly -- doubly so if you've never built any sort of functional game (or aspect of a game covered by what your engine is attempting to address, if it's something like a graphics engine). Now, you do seem to have done that already, so you're good on that point.

Without something to make use of of the engine, you can't really tell if in practice it will be as generalized, functional, abstract, useful, whatever you want. You'll just have some academic pondering and that might very well fall completely apart when you actually try to use it. You will find those most of the major middleware engines began life not as isolated engines but frameworks underlying games that were refactored into generality.

The best way to build an engine is thus to refactor it out from underneath of a number of (probably smaller) games -- or perhaps tech demos, if you're trying for a smaller scope (graphics, physics, etc) engine versus a full-on game engine solution.

I recently wrote up a similar reply to a similar question which might contain some additional information. Let me see if I can recover it from my history before I repeat myself.

EDIT:
I can't find it, perhaps I was dreaming. However, here are two threads where I expound upon some other points (the issue of building-from-games and the issue of being afraid to get the design wrong and being afraid of refactoring):
On refactoring.
On fabricating game engines from whole cloth.

The major reasons just building the engine in isolation doesn't tend to work out is that you have no metrics for measuring any goals: you don't know how usable the engine actually is if nothing is using it; you don't know how reusable the engine actually is until you reuse it. You don't know how generalized the design is until you try to apply it to a variety of practical situations. Concrete games provide you a means of defining small pockets of requirements as well as stable testing environments. You build one game with an eye towards keeping your graphics engine distinct from any game logic -- you build simple games so your development time is not disproportionally spent on the game logic versus the engine itself. Once you've done that, you look at your results and split the game logic away (but don't discard it, it's still a useful test), then try and build a different game, reusing as much of your functionality as you can and possibility expanding on it.

This approach is much more agile, much more education, and results in more interesting products as well as a proven stable, functional, useful framework, which eventually grows into an engine. It forces you to learn from your mistakes rather than trying to pretend like mistakes cannot be made, which only harms you.

In closing, I'll note that you could probably get by without building games for a graphics engine -- you could build yourself some tech demos, instead. Small applications demonstrating specific techniques, et cetera. I don't, however, recommend this, because it doesn't force you to look at your design in the large, only in the small; using a game will help keep you tuned towards the resuability of the framework and the abstraction away from the domain-specific logic of the game -- it will help teach you about decoupling your subsystems, essentially. The domain-specific logic of technical demos tend to be the same logic as that of the underlying framework (graphics, in this case), which can result in bleeding through of dependencies, assumptions and implementation details if you're not extra careful, and you won't necessarily notice this bleedthrough until you try to finally build a useful product with it, at which point it may be too late to staunch without major refactoring.

Also (yeah yeah, this is really the end, I promise), I'd note that even if you don't intend for this to ever be production-ready or available to the public, the experience you gain doing things this way will still more practical and applicable and useful than going the "build in isolation" route.

[Edited by - jpetrie on May 8, 2007 12:53:17 PM]

Share this post


Link to post
Share on other sites
Good points there. When I say no gameplay I mean that I'm not interested in making a game, but more of a tech demo. I don't mind having the basic FPS functionality in it, such as say, being able to run around the environment or display a character model (maybe with animation, but that's still in a very far future). What I don't need is an actual complete game product.

Also, as I said, I agree that it's impossible to get it right the first time, but it does not hurt to start on a good path (note: I'm not saying on the "right" path :P )

Share this post


Link to post
Share on other sites
Okay. I was editing while you posted, so just so you don't miss it, this is the section I added (which mentions the tech demo approach and a few disadvantages):

Quote:

In closing, I'll note that you could probably get by without building games for a graphics engine -- you could build yourself some tech demos, instead. Small applications demonstrating specific techniques, et cetera. I don't, however, recommend this, because it doesn't force you to look at your design in the large, only in the small; using a game will help keep you tuned towards the resuability of the framework and the abstraction away from the domain-specific logic of the game -- it will help teach you about decoupling your subsystems, essentially. The domain-specific logic of technical demos tend to be the same logic as that of the underlying framework (graphics, in this case), which can result in bleeding through of dependencies, assumptions and implementation details if you're not extra careful, and you won't necessarily notice this bleedthrough until you try to finally build a useful product with it, at which point it may be too late to staunch without major refactoring.

Also (yeah yeah, this is really the end, I promise), I'd note that even if you don't intend for this to ever be production-ready or available to the public, the experience you gain doing things this way will still more practical and applicable and useful than going the "build in isolation" route.


I do tend to obsessively edit my posts, heh. Anyways, good luck.

Share this post


Link to post
Share on other sites
I'm reminded of a saying which goes something like "Success comes through experience; experience comes through failure."

There's never been a human being who walked this earth past, present or future, who got something like this right the first time. It seems you've accepted this, but I alsways find that quote usefull to keep in the back of my mind.


As an example, when I was 14 or so I wrote my first RPG engine in QuickBASIC. The main drawing routine consisted of a rather large SWITCH statement, and everytime I added a tile to my tileset I had to update that switch with a new case for that tile. It worked flawlessly, but it wasn't an elegant solution. When I learned about segments and near pointers a little down the road, I applied that knowlege toward version 2, which ended up being 4x more usable with only half the code overall (version 2 included many other such refactorings.) Even today, 10 years later, I count that time as one of the most rewarding and formative experiences I've been through on my path to becoming a programmer. I learned a great deal about good design by writing my first engine as well as I was able at the time, and then improving on that months later.

As I look back now, I'm actually amazed by portions of that codebase. I see elements of OOP and design patterns, both of which I had no formal knowlege of at the time. Its pretty well structured and modular, even despite the fact that it's QuickBASIC code, most of which is ugly as sin (and some claim its flat out impossible to produce good code in it.) That said, there are other portions which still could stand some improvement.


Anyhow, the long and the short of what you should attempt is this: Do the best you can, then make it better.

Share this post


Link to post
Share on other sites
I've been working on a graphics engine for a long while, and I'll second much of what was said here.

This isn't intended to be an insult to you, but believe me, your first engine WILL suck :P . This is because it's very complicated and a learning process. You'll think you'll have a well planned design, but then you'll learn something new or your style will change, and your plan will then mean nothing. What ravyne2001 said about experience coming through failure is very true.

This has been particularly true for me, as I have no formal graphics programming training, so while I consider myself to be a competent programmer, I learn new things every day (though I suspect that's true for experts as well). And a good example of style changing: I recently cured myself of singletonitis, and that itself required a rewrite.

But if you're persistent, it's very gratifying. My advice is just to keep your code modular so it can be easily reused. Then for each new version, you're not so much rewriting as refactoring. And each new version will be better than the last, as you'll be building on the experience and skills you've gained.

And there's nothing at all wrong with writing an graphics engine, while not being interested in writing a full game. I'm like that too; I prefer working at a lower level. The most I do is write very simple games and tech demos for debugging.

Share this post


Link to post
Share on other sites
If you wanna get a idea of a good low level engine, check out ravuya's lab site.
He has an engine called propane injector that is IIRC, meant for games however, he is using OpenGL for the graphics part so it could be useful for you. He has the source and docs on the classes. Here is the direct link to the download page.

http://ravuya.ballofdoom.com/propaneinjector.php

I hoped that helped.

~Mad_Coder

Share this post


Link to post
Share on other sites

This topic is 3874 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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