• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
zeeli

How to create a game engine

27 posts in this topic

I've been searching information about game engines and developing a game engines alot lately, but I haven't found any good tutorial/article yet, that would contain the basics of engine programming and maybe about engine design etc.. I have the solid knowlegde of C++ basics and I would like to find out how to create an engine and I don't have much exp. about graphics programming yet. so.. do you recommend any tutorials, maybe a book..?
0

Share this post


Link to post
Share on other sites
First off, get solid knowledge of Advanced C++. Only having the basics will make things exceptionally more difficult.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by zeeli
what do you mean by advanced c++

Templates, STL, iterators, exception handling, functors, inheritance, ploymorphism, virual classes and the cost of using them, operator overloading, understanding of temporaries, smart pointers, memory management...
0

Share this post


Link to post
Share on other sites
Quote:
Original post by zeeli
what do you mean by advanced c++


Well, you said you have a good understanding of C++ basics. This implies that there are 'not basic' things you don't know or aren't comfortable with. These advanced topics [such as the ones listed by T1Oracle] make the difficult task of making a computer game plausible.
0

Share this post


Link to post
Share on other sites
If you have a good understanding of how to program with cpp you should start working on a small project.
0

Share this post


Link to post
Share on other sites
If you're comfortable with most of the concepts mentioned above, the best way to start writing an engine is to 1) try it yourself to work out where the difficulties lie and 2) examine the source code of some existing engines for solutions to these problems.

Engines worth a look include Wild Magic, OGRE and Irrlicht, amongst others. Also have a look at the Enginuity article on GameDev.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by zeeli
but I haven't found any good tutorial/article yet, that would contain the basics of engine programming and maybe about engine design etc..


Speaking of which, me and a couple of mates have got together and came up with a game engine design, and we are documenting it, writing an article on it, why we designed and made it the way we did. Read some books on object orientated design to get you off the ground, and draw LOTS of diagrams, work out exactly what you want your engine to do, and all the usual blah.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by T1Oracle
Templates, STL, iterators, exception handling, functors, inheritance, ploymorphism, virual classes and the cost of using them, operator overloading, understanding of temporaries, smart pointers, memory management...


well.. thats what i meant about c++ basics :)
0

Share this post


Link to post
Share on other sites
Well, you talk about design. I always believed that design doesn't have much to do with programming language (actually they do, but souldn't have to).
So, the first question should be 'do I know what an engine is/does?' and then you ask yourself 'what i want my engine to do?'.
When i first thought of it, after reading tutorials on graphics programming (actually they tell you one way to do some technique, nothing to do with a whole engine) I bought 'Game Engine Design' book and looked at WildMagic source code to understand how to separate the parts of an engine. Then I started to look for engine's source code and documentation (mainly OGRE and NeoEngine) to get insights on some aspects of the rendering engine.

But what finally has teached me how to design an engine is to make lots of bad designs. One thing you learn when you fail is what don't work :) Actually, in software design, you can do almost everything in many ways (in game engines you have that real-time constraint, but who cares? ;)
Design is iterative, so, don't stick with a design, definitely you'll have to go back and redesign.


PS: if you want a good book about software design, get 'Code Complete'. It teached me a lot of things (but don't become too dogmatic ;)
0

Share this post


Link to post
Share on other sites
Get Jet3D and Quake2 engines and study those. I recommend against C++/STL/OOP right now because that is a chore in itself and not needed. The problem with engines is that they have zillion parts and until you read the code flow you won't understand the design decisions. Quake2 is engine that is separated from editor while Jet3D interacts with the engine. So those are two different styles. Besides, in both of them there is some really clever code to pick up along the way. Might also want to check out quake3/doom3 but they're probably too advanced in many areas from the simpler q2/jet engines. In q3/d3 you got subdivision surfaces + advanced renderer system, etc.
0

Share this post


Link to post
Share on other sites
I'd have to disagree with the advice to avoid the OOP and C++ Standard Library (aka STL). For a beginner I would say OOP (at least at the most basic level) would be easier to understand because it's higher level and easier to conceptualize a problem. And well, I kind-of agree with the STL being more trouble than its worth for beginners, but the converse can be argued, and because of that, deciding whether or not it should be learnt is moot; it's a key part of C++, without it C++ would be a real nightmare, and finally the STL is just too usfull and important a tool to ignore - practice makes perfect [wink]
0

Share this post


Link to post
Share on other sites
I don't think studying quake engines is a good example of 'How to create a game engine' for anyone that has not done it a few times at least.
Object-oriented engines are a lotta more understandable and you can make easily a conceptual scheme of the engine's architecture. Nowadays, engines are so complicated and do lots of things that if you don't have any high-level view of the whole, you'll get insane.
0

Share this post


Link to post
Share on other sites
I also disagree with the avoid the STL advice. If you're going to try to make an engine, do that. Don't waste your time writing [and debugging] data structures and algorithms that already exist in the language.
0

Share this post


Link to post
Share on other sites
Look for a book on the subject like game coding complete & Programming a Multiplayer FPS in Direct X or look at someones source code
Quote:
Original post by JD
Get Jet3D

Personnally I recommend that you stay away from the quake engines. The quake engines have poor coding conventions and are full of unnecessary optimization code.
0

Share this post


Link to post
Share on other sites
^ I thought the same when I saw the code but I figured Id Software had to have some great reason for it.
0

Share this post


Link to post
Share on other sites
I've decided to buy books (when I get some money ;P) "Programming a Multiplayer FPS in Direct X" and
"Programming Role-playing Games with DirectX 8.0"

are those books good? at least they cover engine creation and directX..
0

Share this post


Link to post
Share on other sites
Well.. You may want to grab an open-source engine and try to implement something simple.. Maybe just a model viewer to start with. That should help you understand what tasks an engine/gameOS does.
0

Share this post


Link to post
Share on other sites
Definitely stay away from the open-sourced Quake engines. As mentioned above, they are not good examples of game engine design.

I'd also suggest to stay away from any existing game engine source code. Source code is an implementation detail. It won't help you understand a design. It will only hide the "forest for the trees."

The problem I find with most game engines, particularly engines that were designed in a vacuum and have not been used to ship serious, commercial games, is that they suffer from either over-design or a strong bottom-up design.

Over-designed engines try to be all things to all people. I generally feel that if you're calling something a "game engine" you're drawing a line in the sand and saying that this "bucket of bits" is good for a fairly narrow goal. I've seen many engines that over generalize to the point of essentially becoming a virtual machine. Except they're not that flexible, or powerful. The result is abstraction without effectively narrowing the problem domain (or doing so trivially).

Bottom-up design is also prevalent due to the programmer's natural tendancies. We want to sit down and start programming and start seeing tangible results. It's hard to get that instant gratification without starting at the bottom and working up. But this is a hard course to stay as your goal remains a game engine (or a game!), yet you'll spend an incredible amount of time filling out details and implementing tech that you've not yet defined whether or not you'll need it.

Returning to my first point on over-designed engines: think of a game engine as a tool. You don't want a hammer, a screwdriver and a chainsaw all combined into a single tool just because you may or may not need those. In fact, if you're a plumber you'll likely only need one of them, and your clearing a bunch of trees (so that you can see the forest, of course) you'll not find much use for the hammer...

...If you're wanting to make a 2D isometric game, create a 2D isometric game engine. Don't create a general purpose "game engine" and then, using the game engine, build your 2D isometric game on top of that.

My personal approach I've been applying lately has been to approach the task from the user's perspective (even if the user is you). I'm sure this is called customer-focused design or something like that. The important point is that any time that you're designing a tool you begin by asking yourself, "What do I want my experience to be?" Do the same thing with a game engine: ask yourself, when the engine is finished and done, when I become a user of the game engine, what do I want the experience to be?
2

Share this post


Link to post
Share on other sites
^ It sounds like your going to the opposite extreme. If you ever work on more than one project or come up a new idea late in the design, that over-specialized engine design may turn around and bite you. I think that only the things that you're 90% sure will stay the same should be designed with a narrow focus. Futhermore I believe that there should always be room left for expansion when it doesn't harm performance. If you can make something more abstract and fexible without conflicting with your ultimate implementation plans, then that abstraction should at least be attempted. As sure as anyone ever is about the end goal of a project, there are almost always new unpredictable ideas that come up later.
0

Share this post


Link to post
Share on other sites
This is the best tutorial that i have seen that teach the fundation for build 2d and 3d games:

http://www.tar.hu/gamealgorithms/index.html


0

Share this post


Link to post
Share on other sites
Perhaps it would be easier for you to write a few games before deciding to create an engine. From my understanding, many engines are created from reusable code modules that have evolved over time. Eventually, all of the code modules "click" together to form a simple layer of abstraction - which is then considered to be the engine.

If you don't know what you need your engine to do to begin with, you're driving blind. Sure you might learn alot, but you won't have anything to show for it.
0

Share this post


Link to post
Share on other sites
Hi

I also suggest you not to use any existing engine for learning. Ogre, Irilicht, Crystal Space are all great things but full of code that you wont use in your game. First of all make decission of what kind of game you are developing. It is not reasonable to use Quake 3 engine for logical game [smile]. Over years I saw lot of engines, I tried to implement them for my own games, BUT I always made a whole thing from the scratch, because I needed special approach for my development.
For start get familiar with core c++, then make next step to DirectX or OpenGL.
Try to make some simple 2D things, some simple 3D things and after getting some expirience points and being 10th level programmer [smile] make a simple core of engine you want to make. Then you will know the right way.
For OpenGL look at NeHe site, and for DirectX just download DirectX SDK it is full of examples. If you have ATI also download ATI SDK (I don't know about nVidia but I think nVidia have their own SDK).
Look, feel, understand and learn.
0

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  
Followers 0