Jump to content

  • Log In with Google      Sign In   
  • Create Account


Starting Game Engine


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 isochek   Members   -  Reputation: 107

Like
0Likes
Like

Posted 12 March 2013 - 01:53 PM

Hi guys, 

 

I figured this would be a good place to start a thread about making the jump from "Hello World" to building a game engine.  I don't mean details in what exactly it takes (I don't think) but I'm hoping for a general discussion in this progression.

 

To give a little background about myself, I took C++ classes in high school and afterwards studied the language through books, forums, mentors, etc.  I spent a few years writing custom code for a private Ultima Online shard, a Neverwinter Nights module.  So basically, I have somewhat of an understanding of most c++ basics like variables, building functions, allocating memory, using classes, etc.  I haven't really touched anything in the core of an engine though.  (Most of my programming has been in console applications, which usually turn out to be shitty calculator programs based in the command prompt format.  UGH, so tired of not being able to do anything else!)

 

Now I love programming, but I can't find a bridge that can take me to building applications and GUI (specifically games), and rendering.  Any time I look at source code for a video game (or ANY application for that matter) it's like a completely different language that seemingly isn't using much of what I've learned.  I end up asking myself, do I really know anything about C++?

 

I understand that I need to incorporate a graphics engine like OpenGL and learn about it.  When I start a new codeblocks project, incorporate OpenGL, it loads so many lines of code that I don't even have a clue where to start.  Keep in mind this is just to render a default color pixel triangle.  I ask myself, how do I go about rendering a .bmp for a background, and loading another image to walk around on top of it?  Why must it be thousands of lines of code? Lol.

 

Don't get me wrong, I want to learn how to do it.  I've just no clue where to take the next step after all c++ basics.

 

Could you guys give me any suggestions on how I can improve my c++ past these basics so I can really understand the language?  Hopefully, soon, I can start building a game engine)

 

 

(Oh, by the way...I realize that there are probably millions of tutorials and articles out there, but everything I've found thus far is either too vague, makes too far of a jump to harder stuff, or just doesn't cover what I need to know so thought it might be nice to actually talk to people about my current position.)

 

Thanks.


Edited by isochek, 12 March 2013 - 01:58 PM.


Sponsor:

#2 Nercury   Crossbones+   -  Reputation: 766

Like
8Likes
Like

Posted 12 March 2013 - 02:33 PM

The best way to learn how to make game engine is to make a game. Now I need to apply this wisdom to myself smile.png

 

Don't get me wrong, I want to learn how to do it. I've just no clue where to take the next step after all c++ basics.

 

My lecturer a few years ago gave me a few tasks:

 

Basics:

- Render a triangle, triangle with texture, make triangle spin.

- Bonus points: do it with shaders too.

 

Matrices and delta time:

- Make an Earth model that has a Moon and turns around the Sun. This small solar system model should have correct rotation based on the real world data. You should be able to speed-up/slow-down the time. Models can be simple wireframe or solid color.

- Bonus: texture them, add correct light.

 

3D basics:

- Render a globe (or any curved model) with a texture correctly applied. Then make it smooth by using the correct normals.

- Render a model loaded from a file. File format is not important. Animate it: make it move/spin.

- Make a few kind of lights: a spotlight, point light, sun light.

- Make an object cast a shadow.

- Implement basic collision for something.

- Make a camera, which is switchable between three modes: FP walk, FP fly, examine (you turn around the target, or third person).

- Bonus points if you do it with shaders.

- Bonus points: make the same object cast shadows for all light types.

- Bonus points: make the shadow nicely blur and fade out in a distance.

 

By the time you finish this, you will have a much better understanding of many things, which will help you in many aspects of games programming. You can even do these things as part of some small game(s), to make it less boring. All of this can be done with the tools of your choice.


Edited by Nercury, 13 March 2013 - 06:55 AM.


#3 GeneralQuery   Crossbones+   -  Reputation: 1263

Like
6Likes
Like

Posted 12 March 2013 - 02:43 PM

Short answer: you don't jump from "Hello World" to writing game engines. What is your primary focus? Is it to make games or are you more interested in the programming side of things?



#4 CC Ricers   Members   -  Reputation: 623

Like
3Likes
Like

Posted 12 March 2013 - 02:58 PM

You gotta walk before you run. Learning the basics of C++ is trivial, but applying it to real-world applications, not so much.

 

Applying what you learned, code simple console window games all by yourself if you haven't already, instead of trying to modify someone else's more complex code. You should try to make games like Hangman, Tic Tac Toe, or a small text RPG if you're feeling a bit more ambitious.

 

I once tried to follow a SDL tutorial before completely understanding pointers or objects and classes. Classes aren't a hard requirement with using SDL but the tutorial used them so it went way over my head. Understanding these concepts comes quicker in smaller console programs so you aren't distracted by with things that are API specific like setting up a window or rendering a model on the screen.

 

If you feel ready to go into graphics, use SDL, SFML or something similar. Then go with the basic 2D games (Pong or Snake are good ones).


My development blog: Electronic Meteor

#5 isochek   Members   -  Reputation: 107

Like
0Likes
Like

Posted 12 March 2013 - 02:59 PM

Thanks for the input guys.

 

GeneralQuery, I have to say my primary focus is the programming aspect, working on AI, etc.  I'd love to spend time developing an engine similar to Ultima Online (or RunUO),  I'd contract someone to design a model package and particle effects with maybe a couple hundred designs, and do most of the coding on my own.  

 

(I'm considering going back to college to get a degree in software development and maybe find an actual career in programming).



#6 orizvi   Members   -  Reputation: 276

Like
0Likes
Like

Posted 12 March 2013 - 03:49 PM

Graphics are probably the shiniest and most visible sign of progress - but don't forget that there is an audio system, game logic, physics, input output, file loading, networking, and whatever else your game will require. If you're still not super comfortable with your language of choice - start by implementing simpler systems. By the time you've implemented those other systems, at least the complexity of the language will no longer be a constant stumbling block because figuring out 3D APIs and linear algebra and everything else needed for 3D graphics is complicated enough on its own.


Edited by orizvi, 12 March 2013 - 03:49 PM.


#7 GeneralQuery   Crossbones+   -  Reputation: 1263

Like
0Likes
Like

Posted 12 March 2013 - 03:55 PM

You've probably already figured out that there's going to be a good few steps between where you are now and where you want to be but I'd suggest winding your expectations back even further and start afresh. You say you have some basic programming experience. That's a good start as you're probably already familiar with some of the fundamentals but I have to ask, why C++? In my opinion it's a language fraught with problems as a first language as there are better, more noob-friendly languages that are great to cut your teeth on to get a handle on the programming fundamentals. Python gets touted a lot on here as being a good introductory language but I have no first hand experience with it so really can't recommend it either way. From what I've seen though it looks very forgiving, easy to grasp and has a wealth of libraries to do a lot of the heavy lifting (think mindless boilerplate code) to actually get things done. Graphics, sound, UI, networking, all that sort of stuff. Getting things done is fun, the theoretical understanding is of course important but it takes a back seat to enjoying yourself in those precarious early steps. Anyway, whatever language you choose (and I'm sure you'll get some good recommendations from other members) these are some things to bear in mind.

 

After getting reasonabley comfortable with a language there's no set path but it's usually just pushing yourself to doing a project/game (no matter how basic) you misguidedly think is within your current reach, messing it up, figuring out how you messed it up and then repeating this process until you have a level of confidence and competency to make something of merit (set aside a good few years for this). Start off really basic with something like a number guessing game then work your way up. Try a small very basic text adventure game, pong, tic tac toe, and so on. There's no real point it attempting to forecast a multi-month/year learning schedule as I'm sure your questions and expectations will change as you go along but I'd recommend getting your hands on one of the existing game engines (Unity, UDK, that sort of thing) and using them in the meantime to make some games to supplement your programming learning. It's useful to get a feel for being on the other end of the stick with regards to game engines but realistically you can put your goal of rolling your own on the back burner for now and start with baby steps.

 

The mantra "make games, not engines" gets repeated a lot here but it's good advice. When thinking of goals in terms of "game engines" (and believe me, it gets mentioned a lot on this forum) it really misses the point. An engine of any scale is really the accumulation of tried and tested solutions to problems that you can confidently expect to encounter. Problems you've encountered through experience of making games. You see the horse/cart problem with a beginner thinking in terms of game engines? I see it as more of a philosophical difference of approaches rather than "engines=bad".



#8 landagen   Members   -  Reputation: 376

Like
0Likes
Like

Posted 12 March 2013 - 03:59 PM

The more libraries and APIs your program must rely on to get it working, the more difficult it is going to be in figuring out on how to proceed.  I would suggest a game or some other thing that relies very little on other libraries other than the standard libraries.  This will limit the amount of things you have to learn at the same time.  You should understand pointers, parameters, classes including virtual methods, what an abstract class is, namespaces, a basic understanding of templates, etc.  You should also understand some of the basic containers like vector, list, etc.  A good understand of input and output (such as from a file system) will definitely be useful.  One of the more confusing things with c++ is there is always a bunch of ways to do the same things and they each have their pros and cons.  Just pick one and don't worry about the choice you made for now as long as you can understand how to use it. 

 

I would suggest starting with a small text based game.  While it won't be great eye candy, you could still try out different game mechanics.  The feedback to the user will just be in text form.  First start off making it turn-based, then try to convert it to real-time.  Add in things like saving your progress and restoring.  Focus on trying to reuse as much code as you can throughout the process.  Don't be afraid to redesign things that don't work, but don't spin your wheels re-designing over and over again getting nothing done.  Sometimes good enough is just that.  Once you have a playable text based proof-of-concept that it is real-time, add a window to the mix and pick your render api (DirectX or OpenGL).  At this point you could also look into the route of using a library such as SDL, SFML, etc.  There are a lot out there so don't spend too much time fretting over which one to choose.  If you can, keep your console window so you still see the text interaction and just add some graphics to supplement the game.  As you add more graphics and animation, you can start relying on the console window less and less and focus more and more on the graphics.

 

In the end, your game should just kind of grow organically and morph into your end goal.  This will maximize your learning and minimize your frustration.  It will also give you something to look at and pat yourself on the back more often than not. 





#9 Nercury   Crossbones+   -  Reputation: 766

Like
0Likes
Like

Posted 12 March 2013 - 04:01 PM

Graphics are probably the shiniest and most visible sign of progress - but don't forget that there is an audio system, game logic, physics, input output, file loading, networking, and whatever else your game will require. If you're still not super comfortable with your language of choice - start by implementing simpler systems. By the time you've implemented those other systems, at least the complexity of the language will no longer be a constant stumbling block because figuring out 3D APIs and linear algebra and everything else needed for 3D graphics is complicated enough on its own.

 

What do you mean super-comfortable? I am programming with PHP for more than 4 years, and I am nowhere near super-comfortable with it. It is even harder to get comfortable with C++. Those three tasks I mentioned were given to more than 50 students and 95% of them finished them. There were various languages: C#, Java, Python, C++ being the most popular. Loads of bad, inefficient, incorrect, crashing, lagging code was written. The most important thing: these tasks served as an initial steps towards something better. Have fun hacking!



#10 Heaven   Members   -  Reputation: 478

Like
0Likes
Like

Posted 12 March 2013 - 08:55 PM

http://nehe.gamedev.net

 

Start with Lesson 1: http://nehe.gamedev.net/tutorial/creating_an_opengl_window_%28win32%29/13001/

 

Assuming you're developing for Windows.

 

Depending on how many of the tuts you go through you'll end up being able to render pretty much anything you want (text, tiles, models, etc.). Which is a huge start towards getting a game going. I liked them not only for that but also for the Win32 code it steps you through. Basic window creation, basic input, etc.

 

When you're ready to add sound I'd suggest OpenAL. It's got similar syntax to OpenGL.

 

My biggest hurdle right now is multiplayer. I'm trying to wrap my head (and classes heh) around Winsock.

 

Anyway good luck! Game programming is fun and rewarding if you stick with it.

 

Take care.


Florida, USA
Current Project
Jesus is LORD!

#11 Mathimetric   Members   -  Reputation: 133

Like
0Likes
Like

Posted 15 March 2013 - 10:09 AM

for starters with openGL, you should attempt learning the basics through use of books.

my library of book phocus is :

 

beginning OpenGL game programming : dave astle , kevin hawkins

more open gl programming game programming : dave astle editor

data structures & other objects using C++ 3rd edition

 

you should also have a good book for c/c++ standard as used reference to coding.

having a good understanding of data structures, OOP, classes, standard lib functions, macros,

exetra is a must.

 

as for loading images the true vision extension ".tga" file is mostly or mainly used for textures because of its

qualities of holding alpha values and color values, "RGBA"



#12 Mathimetric   Members   -  Reputation: 133

Like
0Likes
Like

Posted 15 March 2013 - 10:37 AM

here is a link to them

 

http://glbook.gamedev.net/GLBOOK/glbook.gamedev.net/index.html






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS