Sign in to follow this  
wijnand

Game engine tips and tricks for beginners

Recommended Posts

wijnand    253
Hey there guys, I wrote a small guide on my experiences with making a game engine. Hopefully this helps you :) Any feedback and comments please post them here, I am prob expanding it a bit more to post on SDK's and such :) There have been many threads on a few forums that I visit where people ask questions: How do I make a game? Or even more concretely how and where do I start? I have had experience with making a small 3D engine in C++ and want to give some insight to the people on how to make a 3D engine, where to start. But more fundamentally, the many pitfalls inexperienced programmers might run into. Programming itself is not difficult to understand; indeed reading a C++, Java book might be more than enough to understand the syntax of a code. But sadly there is just more to it then to just read a book. Let’s start with the fundamentals; there are a few things you need to understand before you put a lot of attention into making a 3D engine. A 3D engine is a piece of art, its something you have to spend a lot of time on to make things look good, it’s easy to just dump a 3D model on the screen, the issue is how to move it, how to make sure it doesn’t move like a complete plank. Things like this takes time and patience to understand. Making games is like building a house or even a small model. It’s all about putting together small pieces before working on the looks of a product. All too often have I had people come talk to me and asking me to make a awesome looking game with the looks of unreal, how we should make an MMO. Needless to say you need a lot of dedication and experience to write a good game engine. And it’s always best to start small, and build your way from there. Fundamentally its more important to have a good foundation before expanding your engine, the better your foundation is the more stuff you can do with your engine. This small guide is split up in a few sections. And I will try to discuss each section as best as I can  What programming language should I use? This is a big question asked by many, and the answers are always very different. I will try to look at the facts and how things currently are in the industry. First of all you have a few things to consider in this area: What do you want to program? The reason this question is fundamental is because it dictates how complex your game should be, on what operating system it should run and what things you want to achieve. Its obviously stupid to be programming a 3D Engine in Java if you want to use DirectX. So first you need to think of what for a game you want. The smaller the game is, the more programming languages you can use. Of course not every programming language is really suited for quick and dirty games. C++ This is by far the most popular programming language for games, most programmers use this language because most of the Windows API’s are written in C. This means that when you use DirectX and OpenGL with the WIN32API then you really have not much choice but to use C++. In Linux you would use OpenGL and as you might guess the main library is written in C. A big downfall of C++ is that it is quite low level compared to Java, memory allocation is something you need to do yourself with C++. In my first game engine the memory leaks where all over the place. So you really need to be sure your comfortable writing your first game engine in C++, if you already have a lot of C++ experience out of game programming then you know how the few disadvantages that C++ processes. A great positive point however is that C++ is extremely fast compared to Java and C#, its speed comes with more responsibility to the game programmer though. So only take C++ if you’re willing to learn from these mistakes or if you really want to program a game that you completely want to build yourself in DirectX or another API. There are tools around that help you detect memory leaks, but I seen my program leak 250MB in a minute because we had a few teammates who never destroyed any pointer they made ;) . Java Personally I learned programming using Java as a first, and then moved to C++. A big advantage o Java against C++ is that it tolerates memory mistakes more. It has its own built in Garbage collector that looks for memory that’s no longer being used by the program and removes it. Another advantage is that in Java you can nearly program anything and ensure it is compatible in Linux, Windows and even on a MAC. However with this compatibility comes a price. The speed of a java program is compared to C++ a lot harder to program with performance in mind. Simple games of course are excellent to do in Java it probably is with C# the easiest to use. If you want to make a simple game like blackjack, or even a small adventure RPG then Java is an excellent choice. For more sophisticated 3D designs C++ is suggested although it is possible to do so in Java. But it comes at a price in performance. C# C sharp is the answer of Microsoft to sun’s dominance with Java on the internet. Fundamentally there is not much of a difference between Java and C# infact, if you know one of the languages you can easily program in the other. C# is the only language that also supports DirectX. It has a built in garbage collector as well and is currently being used with Microsoft XNA Studio. Microsoft XNA studio is basically a small programming IDE where you can easily use libraries to make 3D Games for the Xbox360 and Windows. C# was touted as the new DirectX programming language to be used, Microsoft even made a framework available for it, but they stopped developing for it since .NET 2.0 if you want to use the Managed DirectX you need to be sure you know how to program in .NET 1.1 .. Flash Flash is mostly used to show small online animations, it has been used to make small side scroll games, I seen even a few small top down games where you could walk around. The problem however is of course you limit yourself extremely. Of course when you’re a new programmer who needs experience any scripting language is good, it forces you to think on how to solve specific game problems. Something that on each programming language the same. Problem solving is the general time a game developer is working on. How do I make sure that the design and story of the game is best portrayed on someone’s computer? There are a lot of other languages, like Visual Basic, Pascal, powerscript. But to make sure the scope of this small tutorial isn’t too big and bore the reader these are skipped. In general scripting languages can be used to make simple games, but you limit yourself extremely in the sense its hard to programming something yourself in a scripting language. With C++, Java, there are possibilities to make your own functions that are able to do more than the specified api’s you get with each programming language, scripting languages are able to do it, but to a lesser extent. The design A lot of people I know who want to make games comes to me and say hey I want to make an awesome shooter that looks like Fallout, with halflife 2 and Doom mixed together. This is not a design this is an idea. A lot of people think its just snapping your fingers to figure out how to make a game that looks like HAlflife 2. Nothing is more far from the truth then that statement. When you make a gamedesign document you think of a story. You think of something you want the game to do to the user. You set simple goals on what the premises of the game is, what you want the player to be able to do and how for him to beat the game. You cannot start building a house without a good building plan. And a game design document is that. A lot of programmers including me ignore this stage and want to jump straight into programming without thinking of the consequences. A game design document is not more than just a story, and what the game should do. You are marking off the things you want the game to be able to do. A fundamental mistake most beginners make is to just program something and suddenly realize their implementation is completely wrong. You have to ensure that your game design is as complete as possible, the story might not have to be done. But it gives you the idea of what you should consider when making your functional design of your game engine. You know what the designers want, and you have an idea where you should emphasize on the most. Adding too much functionality to your engine is of course also not bad. But the problem is you might end up adding so much items you could use that your engine becomes big and hard to follow and read When someone makes a engine it’s always for one game specifically at first. And when they want to make a new game they try to reuse as much code as possible of their old engine. This means that their engine is already done for most of the part, but some things might be refined and expanded on to fit that specific new game. This means overtime your engine becomes more and more complete. Of course sometimes your games are so fundamentally different that you have to make a completely new engine. You cannot ram a MMO engine into a FPS Game because a lot of the netcode is worthless then. Of course this is all dependant on your game design what you want to happen, and how the technical things are solved. A game design document on average contains this: • Type of game (FPS, racing, strategy etc) • What is the basic story? • What requirements do I have for the engine ( online play?, how many models on the screen) • How should the game interaction be (Scripted, a lot of physics, good AI etc) • Etc. Basically the better you mark off your territory the better you know what to focus your energy on. Making a game engine is all about making small steps. And if you know the steps to take then you are already on the right track. Now comes the technical problem you know what you want the player to see but how do you get it on that screen? Game programming is all about solving this fundamental problem, how do I ensure the engine can specifically handle all the things I want to happen in the game. If you know you want Online play what API should I use Winsock or Directplay? Etc… You need to make these decisions with your team from the start so you know the many pitfalls the game might have on specific areas. IF you for example take multithreading as an requirement because you want 700-1400 objects on the screen fighting each other then you have a good reason for it to be implemented. The downfall is the immense complexity you add to your game. Something most people try to avoid (I am currently writing a Multithreading guide for my project team and will post it online for everyone to read). Of course when you’re not sure of one of these answers you can always post on gamedev for sound advice and also fundamental questions. But it’s always best to do your exploring yourself; the best teacher is making mistakes. DO NOT be afraid to post your UML designs online. People in general love giving advice and also looking at how your trying to solve your own puzzle, there are many roads to rome  Don’t be afraid to show people what you think is a good solution to your problem. You might get some good tips that will save you a lot of headaches in the end. Another fundamental issue that a lot of people have is that they are uncertain or unsure where to begin programming eventhough they have a class diagram, and sequence diagrams etc. The problem is for most people is finding the motivation to spend countless and countless of hours on just writing code with nothing happening yet. A big issue most people basically have is that the time -> reward is just not there.. This is the first sign of a project that you are being overambitious. Small steps are the way that you can keep scope on the project. Having an extensive story line with tons of things you can do in the game is fine LONG term. Short term you need to show quick results to yourself, things that reward you for the hours fo time you spend on it. Not programming 400 hours without seeing a single screen of your character moving around. It grinds you ad makes you think that you are never going to reach your goal. Where do I begin? Ultimately this is of course your own personal preference. I personally always try to cut up the project into small iterations so that I can see the result of my day of coding. Results mean a lot to you morally, you might not know it but nothing is more motivating that seeing your character is getting drawn on the screen one day and the next day he can move forward. Its small things you look at but at least you know your going somewhere with your project. A 3D engine can be roughly split up into these components, this of course is not a complete list, or the “correct” way. Ultimately the game you want to make should decide how your engine is build, but also what it can do. • Rendering • Input • Physics • Sound • Artifical intelligence • Networking You might think that each word you read here is basically quite easy to gasp. But each part of the engine I wrote down is significantly bigger then what you would be expecting. Each part can be seen as a complete master’s degree. So do not overestimate them. This again shows the need for you to set clear goals, and try to chop up the problem and delegate it as much as possible. If you do this correctly then you can let your team mates who want to do physics do that alone. As long as you have a grand design you can easily delegate work and work at a much faster speed then what was earlier planned. Game programming isn’t about knowing everything. Its about delegating things your bad at to people who are good at it. Programming a game always should be focused on getting results. Small games are a good start for any programmer. A game engine is a step ahead of everything. The reason behind it is, most small games can be its own piece of code. But a game engine is something that you can expand, and also use for different type of games. You should be painfully aware that changing your goals and plans midway during development is dangerous. When making a game engine you should have planned the things you want. Adding net play, or even multithreading to your game engine midway in development can mean you have to toss about almost all of your code and start from scratch. A lot of programmers get discouraged when they are in an endless loop of programming with no progress. This is called “Development hell” Some things that can cause you to run into this: • Your design is too ambitious and complicated • You did not take into account what your game engine should do. • You are writing too many things you never done before (Directx 10, Directplay) • Your design was not practical. The fundamental thing why these things go so badly for people is because they are thinking too much on what they want to achieve. Not how they are going to achieve it. Small steps and goals will ensure that you do not lose the scope of your project. Another good thing to do is to write your code In such a fashion that you can easily disconnect it from your engine. The better you manage this the more resilient your code is. And easier it is to make modifications. You should not have a class that’s dependant on 20 other classes to function. A class you make should be a piece of code that is not dependant on 20 other instances, it should be written in this sense that you can cut it out of your code and with small modifications still have the engine running in some form of degree. Of course sometimes you are unable to manage to completely cut code to make something independent, but you should try to do it as much as possible. It means you can easily migrate code to your new engine if you wanted to write a new engine without having to start from scratch. Another important tip is to always comment and document your code well, a lot of people do not document what they are doing, or how they done it, this means that they run themselves into trouble when new members join the team. Good documentation is just as important as good code. A final tip in this section is to never pitch to much change in your engine in small cycles. Have small releases that work and not big releases that give you migraines. For some people that really need some guidance on what to do and where to start writing code: • Write a design document • Make a small concept where your character is draw on on the screen, either in 2D or 3D • Expand your code so that the character moves around the screen • Add collision detection etc At some point in time you should be able to write the rest on your own without guidance but hopefully you learned now that the only thing you should know about writing a game engine is that it’s not something that just comes crapping out of the sky, but its something that you spend a lot of time adding small parts to build in the end a nice game. Without a good foundation your house will crash down. And the same goes for nearly everything. Take small steps, learn from your mistakes and rewrite small parts of the engine where necessary but be sure to show results in the end ;) Wijnand

Share this post


Link to post
Share on other sites
Crazyfool    307
Wow nicely done.

Something I disagree on is how the game design document should be made.

I think story should be a much smaller part than most design documents I hear about, only because in my experiences that is what pepople get held up on. For instance, I've worked on a few small projects, and several wanted tyo have everything neatly planned to the tittle before doing any serious work... it never got done.

I think it will help keep you (and the team) motivated if you get a basic story/era/theme going and start working. As you are working, you should add to the story and such.

Maybe I am alone on this, but the project I'm on now is actully moving qalong because I started coding with a basic story in mind. I didnt have everything planned perfectly (story wise) but I did write down (on paper) the needs, plans and goals of the game.

For example, I wrote a brief list of things I wanted the engine to have. I then went into a lot more detail with each one. After that, I began writing the down right implementaton details of whatever part I was going to work on first.

This may not work for everyone, but it offers me a few advantages. 1) I get to see progress which keeps me motivated, 2) I'm more efficient because I can think about the story/ideas when I cant be at the computer and then code and implement the game while I AM at one.

I think that there will also be a large chunk of the game that has very little to do with the story, and very little to do with some of the game features (for instance, if you want an online rpg that has a max number of players of 8 players, then you can implement the basis of the network with that knowledge only).

Otherwise, very good and helpful.

Share this post


Link to post
Share on other sites
gharen2    520
That's a very thoughtfull post. I just have a few critiques, if that's alright.

C++
- You can use the winapi from .net languages quite easily.
- Calling c++ "extremely fast compared to c#" is contentious. C++ is generally faster only if you're an expert who knows enough low level details to be able to optimize their code. For most programmers (even many professional ones I bet), there will be little difference in performance if a game is written in c# or c++.

C#
- You can use managed directx with the .net framework 2.0. You're not limited to 1.1. Managed directx will continue to live for a good while yet, as many programmers, while respecting Xna, aren't willing to completely switch to it, for various reasons that are discussed throughout these forums. Even if Microsoft stops supporting managed directx, you can bet that an open source alternative will appear with an active community around it.

Otherwise, well done!

Share this post


Link to post
Share on other sites
JBS103    168
Very good write up. I, and everyone else I'm sure, appreciate it!

While I will start by saying that I agree flash is limited in some aspects, there is still a wealth of things to do (and a lot of fun involved) with Actionscript. Personally, I don't find it to be so "heavy", or daunting, on the user like some of the other more traditional methods and languages. I would add that if you are into the "instant gratification", then Flash is one of the better routes to go. If you become proficient with the program and scripting, you can pump out some fun, simple, and extremely clean games in a little amount of time. It is something to consider depending on the scope of your goals and of course it all varies from person to person.

Share this post


Link to post
Share on other sites
wijnand    253
I think story should be a much smaller part than most design documents I hear about, only because in my experiences that is what pepople get held up on. For instance, I've worked on a few small projects, and several wanted tyo have everything neatly planned to the tittle before doing any serious work... it never got done.


Well i am more saying it should be a small idea, not an entire planned out idea. But having a good story in mind usually means you know what for technical things you need to take care of :)

Thank ofr the comments guys i will most liekly append what i wrote lateron today got work now and I overslept ;)

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