starting from scratch

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • starting from scratch

      Hello everyone, let me get the intro out of the way, I'm new to programming and even newer to game programming. I have a working knowledge of c++ and just started into game programming. I've written a couple of 2d games (an asteroids clone and a parrallax scrolling shooter) and bought GCC4 recently to expand on what I've learnt. The thing is I'd like to start my engine from scratch and wondered if there was a bit of skeleton code to start from, ie just an initial setup without all of the GCC dependancies. Then I could go through the book a step at a time adding as i go along. Perhaps this is not the best way to go through the book and if not perhaps someone could give me some tips on how to progress from the beginning of the book. So far I have an empty solution-project setup the way the book suggests with the directory structure in place like I said I'm new to this so a little help on how to get started is all I need.

      thanx
    • Actually, I might have some advice as I tried doing the same. When I first began my "game programmer" career (as a hobbyist) I wanted to create my own engine from the get go, but soon found out that it's not a possible task for ONE person.

      I will give you the advice that saved me from wasting time and helped me (still does) to not give up.

      "MAKE A GAME!!!!!! Stop buying books on Amazon, quit skipping over the Math concepts so you don't rely on these stupid Math libraries. But most importantly; start NOW!".

      It might not sound like much, but this is what keeps me going. Like Rez said on a thread here, many newbies start buying books after books in search of the PERFECT one that will solve the unsolvable. Well, the truth is, this is a horrible hole to fall into.

      For example, these are the books I currently own;

      GCC4
      Frank De Luna's DX11 and DX10
      AI For Games (IAN Millington)
      C++ for game Programmers(Dickheiser)(Best book EVER!!)
      Design Patterns(the holy grail)
      3D Math Primer for graphics and game Development 2nd
      Josuttis STL Book
      Effective C++ (Like three of these)
      Introduction to C++ from blah To blah (like 9 different editions, including Bjarnes') (not an actual name)
      Game Engine Architecture(2 of these, can't find them though)
      Petzold's Windows Programming(Great Also)
      Modern C++(not an easy read for me!)
      C++ templates
      .... I guess I better stop before Mike or Rez block me.

      I still have a couple more I can list but hopefully you got the point. Out of all the above books I'probably read about 3 cover to cover, about 2 I read only half, and the rest I only slightly touched and then found out I was over my head, i.e. Effective C++ Series(

      You see, all these books can surely help you make your engine, and they definitely are a must have(most of them anyways), but are you really going to learn well and not overload yourself with data? Probably not! Just start coding, or even better go to the drawing board and THEN code something.

      The best thing is that you are on this forum and you can learn from the experts(shout out to Rez and MrMike) and also let us try your game. Maybe we see something you don't see and even help you fix it, and the chain of events that will eventually lead you to the path that will lead you to be a great game programmer begins.

      PS. I'm not affiliated with none of these Authors..
      Intel i7 3930k
      8GB Mushkin LP @ 2133 mhz
      GTX 680
      Asus Rampage IV Extreme
      Corsair 650w
    • I don't quite agree with hondero in that its impossible for one person to make an engine, it is really what you want the engine to do. For instance the GCC engine has quite a bit of 3D specific things that can complicate the engine way more than a 2D engine can. I began
      working on my engine to work with 2D and 3D, although at the same time I needed to prepare the Engine to be used for a 2D game, which I hoped to use to make my game in school, it took me 3 months with my school work load to have an engine ready to use (however with bugs here and there). If I had to worry about 3D rendering optimizations and such I would never get it done in the timeframe for my game project.

      If the scope of your engine is not to make a fancy first person shooter, but instead a more simple 2D platformer, or puzzle (like me), than you could definitely pull it off. Mind you I have been programming C++ for 9 years now with 4 of them being extremely serious and the other 5 as a hobby, and it took me 3 months plus more time from past experimenting with various components.

      I think what an Engine means to me is, a collection of tools that are reusable from game to game, you may have to swap things out here and there, but in the end, it is constructed in a way that you are able to create games more, and worry about re-writing code less.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • I agree with what you said mholley519, I guess I should've rephrased my answer to specify when creating an engine of high quality.

      Also, don't forget you have MANY years of experience in C++, which Ribbs does not. That alone is a game breaker for Ribbs.

      I suggest he picks up a good 3d programming book (either opengl or Dx) and from there to start practicing creating small game engines (games). And with GCC4 by his side he couldn't go wrong.

      PS. I definitely agree with you on the 3d part, it makes it a lot more complicated. However, for me 2D is just boring!
      Intel i7 3930k
      8GB Mushkin LP @ 2133 mhz
      GTX 680
      Asus Rampage IV Extreme
      Corsair 650w
    • The real question is: what do you want to do? Do you want to join the games industry and be a professional game programmer like me, or Mike before his fall to The Dark Side? Or would you rather go the indie route and play around with some cool ideas?

      It's funny, I agree with both mholley & hondero on this. It really depends on what kind of person you are. For some people, mholey's advice is completely wrong and they should absolutely not follow it. These are the types of people who never finish projects and may not understand the scope of building an engine. These are the types of people that should concentrate on making a game and finishing it at all costs. They should completely ignore any concept of an engine. When they're done with the game, they should go back and extract out the useful bits for the next game. Then they should do the exact same thing: make a game without worrying about the engine until the very end. For this type of person, just finishing something is the most important thing of all. If they don't finish, they never will.

      There's another type of person for which hondero's advice is completely wrong. This is the type of person who really needs to focus on architecture. It's the type of person who wants to take their time so that once the engine is done, they can crank out several of those types of games. People who like experimenting can benefit from this as well, but they have to be disciplined to actually finish the engine. Real engines, even indie ones, take a LONG time to build (years). My engine is about 45,000 lines of code and it's still not fully complete, although it's most of the way there. I just finished a little simulation side project with it.

      So it's hard to really say which side to follow. The bottom line is that you need something no matter what path you follow. A professional studio is going to want to see demos tailored to the position you want. AI programmers want to see AI and simulation demos. Graphics programmers want to see cool 3D graphics tech like hair/cloth demos. Gameplay programmers want to see some cool piece of fun gameplay you captured.

      And if you want to go the indie route, you need to get something done just so you can submit it the IDGA, Steam, XBLA, or wherever you plan on selling it.

      Hope that helps!

      -Rez
    • In response to OP:
      Since you have working C++ knowledge and have made a couple of 2D games, I suggest experimenting with 3D in throwaway projects before starting with the book's code. If you want to use DX like the book does, install the DX SDK which includes the DX sample browser. Within this sample browser, Tutorial 01: Direct3D 11 Basics is a great place to start. Install Project and run it then read through the source and research what you don't understand. You can also reference the book (ch 5) to relate the two.

      Once you're sure you understand everything, move on to Tutorial 02: Rendering a Triangle and repeat. It's also very good practice to experiment wherever possible. For example, in the triangle tutorial, try to figure out how to change the color of the triangle, how to draw a second triangle in such a way that the two form a quad, etc. (All the above, including the book's code can easily be applied with OpenGL if you're interested in that instead. Or both... )
    • Hey guys, thanks for the response. I have fallen into the trap of buying book after book and doing so much reading that I seem to have gotten a lot of unusable knowledge - or I should say, I think I understand the content, move on and then find i in fact didn't quite understand, so I have to go back. I own most of the books you mention (hondero) and I now only use for reference. Also as mholley mentions, I do have a preference for 2d games because I can get a reasonable working project going pretty quickly, unlike 3d, which takes so long to get anything reasonably interesting going on - this may be the wrong way to think but like Rez (props to you and Mike for this book) says, I guess I'm the type of person who wants to go the indie route and just want to present my ideas as simple as possible to just be fun and not neccessarily the next big thing in 3d games. I had gotten used to the books which start off with a basic window, followed by directX window, followed by 3d shapes, followed by.... Well I think you know what I mean. So with GCC4, I was hoping to follow that a bit but expand on those concepts with the ideas regarding 'Initialization 101' and Chapter 7, but not sure that I can do that without having to get to grips with Chapters 3, 4 and 6 first. Maybe I'm showing my inexperience but thats just the way I'm used to doing things - get something on screen then get technical afterwards - I really appreciate the words of advice you guys have offered and will endeavour to not rush so much, However I have so many ideas that I can visualise code for but don't have the framework to carry them off it gets a bit frustrating, still, with waht I've read in these replies I think I have a way of moving forward.
      Thanks again.
      ribbs23

      ps. I would like to post my game exe and some code so you can see my coding style is very much like pseudo code - not very sophisticated - Can I post a folder with exe somewhere?

      The post was edited 1 time, last by ribbs23 ().

    • Originally posted by ribbs23
      Hey guys, thanks for the response. I have fallen into the trap of buying book after book and doing so much reading that I seem to have gotten a lot of unusable knowledge - or I should say, I think I understand the content, move on and then find i in fact didn't quite understand, so I have to go back. I own most of the books you mention (hondero) and I now only use for reference. Also as mholley mentions, I do have a preference for 2d games because I can get a reasonable working project going pretty quickly, unlike 3d, which takes so long to get anything reasonably interesting going on - this may be the wrong way to think but like Rez (props to you and Mike for this book) says, I guess I'm the type of person who wants to go the indie route and just want to present my ideas as simple as possible to just be fun and not neccessarily the next big thing in 3d games. I had gotten used to the books which start off with a basic window, followed by directX window, followed by 3d shapes, followed by.... Well I think you know what I mean. So with GCC4, I was hoping to follow that a bit but expand on those concepts with the ideas regarding 'Initialization 101' and Chapter 7, but not sure that I can do that without having to get to grips with Chapters 3, 4 and 6 first. Maybe I'm showing my inexperience but thats just the way I'm used to doing things - get something on screen then get technical afterwards - I really appreciate the words of advice you guys have offered and will endeavour to not rush so much, However I have so many ideas that I can visualise code for but don't have the framework to carry them off it gets a bit frustrating, still, with waht I've read in these replies I think I have a way of moving forward.
      Thanks again.
      ribbs23

      ps. I would like to post my game exe and some code so you can see my coding style is very much like pseudo code - not very sophisticated - Can I post a folder with exe somewhere?


      2D games are just as good as 3D games. I'm an AI programmer and don't really enjoy graphics programming, so all of my side projects are 2D. Unless your goal is to be a graphics or physics programmer (or you just enjoy it), you don't really need to make a 3D game.

      If you're looking for a place to start, I would go through the few chapters where we talk about the application / logic / view architecture and built that as your initial framework. Then use it to make a game without worrying too much about architecture. Next, build some other piece of architecture into the engine and build another game with it. Since you fall into the "read everything and build very little" trap, I think the important thing is to finish projects.

      There's no place to post executables on the forum since that would open up quite a security hole, but you can either post code here or you can post something on an external site and put the link here. I'm happy to do a code review.

      -Rez
    • Speaking of code reviews Rez, did you get a chance to take a look at mine?
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Did you post one? I must have completely missed it! Sorry about that! Sometimes things slip through the cracks so definitely feel free to bug me about it if you don't hear from me.

      Can you point me to it? I'll check it out right now (I'm just finishing up one for kaykry right now).

      -Rez
    • This is the SVN

      When I asked you for it I was having issues with performance, I have actually resolved them by switching physics engines to Chipmunk, which works better with a lot of rigid bodies which are close in shape and size. Also I have been working with dividing certain tasks into multiple threads, which at seems to level things out well. Before it was reaching something like 150,000 FPS with a small amount of actors, then drop to something like 5 fps with alot, now it starts out evenly at about 600 FPS on my machine and shows very little drop in framerate.

      I guess at the time I knew exactly what I wanted you to take a look at, however now I am unsure. I would say I know alot of systems which could be done much better my next time around, some systems take up quite a bit of cpu time, while others I have fairly well optimized. If you still want to take a quick look you can, however I know you don't have tons of time to work with, and just jumping into an engine without anywhere to start is likely more work than you intend to do.

      The project we are working on as you will see in the SVN is Orbito, our class had 3 teams in our first term who had to each come up with a game idea, then pitch it to our teachers and program chair as if they were investors, receive there feedback etc. We were then supposed to polish up the idea and represent it 3 months later (which was right before Christmas break). This second term, all 2 other game ideas were scrapped and the teams broke apart and reassembled into 3 new teams/game ideas, our teams game 'Orbito' got chosen as well as another game in our class. As Orbito was an idea I had years ago, and I have the most coding experience I was also given the opportunity to work as the lead of the project as well as programming lead, and I'll have to direct the first term students as well to help make this game. So it is soon to fill up with a decent sized team of artists and programmers (for a small indie game).

      Thanks for the offer of looking through the code, if you do end up skimming through it, let me know what you think and if there is anything I can improve on.

      *Edit*
      When I mean dividing tasks into multiple threads, I don't mean setting sub-system updates to there own thread, but instead dividing a single task into multiple chunks, and allowing multiple threads to chew away on it, and when they have all completed, moving on with the main loop
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz

      The post was edited 1 time, last by mholley519 ().

    • I'm not sure how useful it'll be for me to just start poking randomly at the code. If there's a system you want feedback on, or you're interested in stylistic comments, I'm happy to do a more in-depth review. For now, here are a handful of things I noticed while just browsing through the code.

      * You OrbitoGame folder lives with the rest of your engine. In general, it's best to have the engine and the game application live totally separate lives and be completely different projects. My repository is set up to have my engine folder live next to the top-level folders of my game projects. It is it's own project and each game just includes the same vcxproj file in their solution. The advantage to this is that as my engine improves, all my games get the benefit of that improvement. Of course, it does mean that my engine can out-grow games I haven't touched in a while, but I get around that by branching the engine and game code whenever I release something. That way, I can always go back to a working build if I need to tweak something and don't want to deal with making it compoatible with the current iteration of the engine.

      * In general, it looks like the game-specific code is pretty light, which is good. You want the engine to do most of the leg-work while the game-specific code only does stuff that is truly unique to that game.

      * Your LeonsTutorialScript.lua file could use a little work. One thing it doesn't talk about is the "local" keyword, which is very important. Lua always defaults to global scope unless you use the local keyword. Furthermore, local variables are always faster. When you reference a variable in Lua, it will first look in local scope, then function scope, then global scope. In fact, a common optmization in Lua is this:

      Source Code

      1. function SortAllTable()
      2. local sort = table.sort; -- cache the table.sort function for faster access
      3. for i = 1, #tableOfTables do
      4. sort(tableOfTables[i];
      5. end
      6. end


      This can help in the case of very large loops. Either way, you should prefer local variables to global variables.

      * While you do appear to have some interfaces set up, there seems to be a lack of abstraction when it comes to third-party libs. For example, CApplication decalares an SDL_Surface pointer right there in the class. This is a double-edged sword. On one hand, it's more convenient to have it right there, especially when compared to having to deal with writing an abstraction layer. Writing an abstraction layer can be a lot of work. However, you're also tightly coupling SDL to your engine. In order to remove it, you'd have to go through the engine and fix every reference. This isn't a big deal when your engine is only a few thousands lines, but it can be a deal-breaker when it gets bigger. It took us months to abstract all the Direct3D code in Rat Race behind a nice abstraction layer in order to get it running on PS3. Once it was done, we could switch them at will and adding support for new renderers was fairly simple (we had three or four going at one point). I do the same thing in my own engine with Direct3D. Switching to OpenGL would just require me to fill out an OpenGL-specific implementation of my RenderSkin interface. Although, in fairness, I took a similar approach as you for Lua. My LuaPlus integration is mostly hidden behind typedef's, but I happily call LuaPlus-specific functions all over my code. I decided that it wasn't worth fully abstracting. I'll pay the cost for that decision if I ever try to rip out LuaPlus or change scripting languages. I chose not to abstract it because I use Lua as my core data language instead of XML, so I'd have to rewrite all of that logic anyway. It didn't seem to buy me much, unlike being able to switch renderers.

      Hope that helps! If you want anything more specific, let me know.

      -Rez
    • Yeah I have been slowly restructuring my entire folder layout, and I planned on moving OrbitoGame as you mentioned.

      LeonsTutorialScript.lua was part of me and him video chatting about Lua, I did mention 'local' to him however some was in this file, some in chat box, some lua stuff in the c++ code (like exposures) , I had left that test script for him to look back at later, unfortunately it didn't all get saved there.

      There is actually 2 versions of my engine, my big engine code named 'Lumberjack' and my lite engine for Orbito, my thought process here was, I had an upcoming project to work on that required an engine to be up and working fast. In the lumberjack engine almost everything is completely abstracted, and it was really nice to use, however in getting all of this to work right, and experimenting with it, I was focusing more on having a flexible engine, rather then working on what was needed for this project. So I cloned my repo, widdled it down to its bare bones, and came up with something that was definitely not flexible to a wide range of setups, however is giving me more time to work on the game. When this project is done we will be working with the Unreal Engine I believe (hopefully unity instead though) on a 3D project, which will give me a chance to reboot my engine and rework things based on what I have learned building this one. I think if I kept going with the big engine to be used on Orbito I wouldn't have it ready in time and I would be focusing on little things with the engine rather then finishing the game (which is important lol).

      Thanks for the feedback, I do have some systems I wan't to rework however I think I have some good ideas to make them faster, when that's done I will let you know which ones to take a look at.

      *Edit*
      I just looked through that script again, I did mention it,

      local tempNum = num; -- In Lua EVERYTHING is global, even if its in a function or for loop, unless you declare it 'local'

      It's hard to read though as I was commenting everything out as I showed him different things, I skipped over it the first time I looked as well lol
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz

      The post was edited 1 time, last by mholley519 ().

    • Originally posted by mholley519
      There is actually 2 versions of my engine, my big engine code named 'Lumberjack' and my lite engine for Orbito, my thought process here was, I had an upcoming project to work on that required an engine to be up and working fast. In the lumberjack engine almost everything is completely abstracted, and it was really nice to use, however in getting all of this to work right, and experimenting with it, I was focusing more on having a flexible engine, rather then working on what was needed for this project. So I cloned my repo, widdled it down to its bare bones, and came up with something that was definitely not flexible to a wide range of setups, however is giving me more time to work on the game. When this project is done we will be working with the Unreal Engine I believe (hopefully unity instead though) on a 3D project, which will give me a chance to reboot my engine and rework things based on what I have learned building this one. I think if I kept going with the big engine to be used on Orbito I wouldn't have it ready in time and I would be focusing on little things with the engine rather then finishing the game (which is important lol).

      Yeah, that makes sense. Sometimes you just need to get it done. ;)


      Thanks for the feedback, I do have some systems I wan't to rework however I think I have some good ideas to make them faster, when that's done I will let you know which ones to take a look at.

      Sounds good. :)


      *Edit*
      I just looked through that script again, I did mention it,

      local tempNum = num; -- In Lua EVERYTHING is global, even if its in a function or for loop, unless you declare it 'local'

      It's hard to read though as I was commenting everything out as I showed him different things, I skipped over it the first time I looked as well lol

      Yeah, I completely missed that. To be honest, I didn't dig in there too much. I was mostly curious what scripts you had. I've seen a lot of people integrate a scripting language but then not really use it.

      I just finished my latest project a couple of days ago, which is a small simulation game. I just ran my line counter script and I have 2605 lines of C++ and 4738 lines of Lua. I'd say about 1000 lines of that C++ will end up getting rolled into my core engine. The rest is just the boiler-plate for my game-specific Application and Logic classes and some game-specific events & processes, mostly used to handle performance-intensive stuff or to notify the engine of something. Actually, as I look through the code now, I think a lot of the C++ will be rolled into either the engine or the genre layer I use to handle genre-specific stuff.

      Anyway, that's the general breakdown I like to see. The code that's not time-critical lives in Lua while the time-critical and engine-related code lives in C++. If I had done the entire thing in C++, it would have taken me a lot longer and been half-again as much code.

      -Rez
    • Hey guys, after taking in the replies I received, I went back to GCC4 and took another look at Chapter 2, and I must've missed it the first time - trying to get to the coding parts - but it says it all just in those first few paragraphs, and Rez I came back to the forum to acknowledge what I'd missed and I see you sent another reply advising that that's where I should start - must be a sign - So once again, thanks for the wise words and advice. This is a great forum supporting a great book, I have a clearer outlook on how to progress.

      Thanks

      ribbs23
    • I have been trying to expose as much as possible to script as I can, sometimes I will do some game logic code and realize that it only happens occasionally, and would be better in Lua. I ended up using the Lua function environments I mentioned a while back, and they are working quite well, I have the option to still use the global Lua table as well, but these Lua function environments are pretty cool.

      I am under the impression that when something is not declared local in the function environment, it still is only global to that environment, I have used this to add some cool features to my engines scripting.

      For instance in BasicAtom.lua there are currently several functions that will be called similarily to Unity script, an Init function when it is created, an update function every frame, a shutdown, and then other callback functions such as collision enter and exit.

      I have also set it up so that when a script environment is created, a new variable named 'this' will be set with the value of the lua actor representation. This is proving to be really useful, the only thing is that LuaPlus has issues with the gcc compiler which Josh Jensen has told me is fixed in the nextgen branch of his code but I haven't had access to it yet, I haven't found that Luabind implements it , and I don't know enough about the underworkings of Lua's c api to figure it out myself yet.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • RE: starting from scratch

      Originally posted by ribbs23
      Hello everyone, let me get the intro out of the way, I'm new to programming and even newer to game programming. I have a working knowledge of c++ and just started into game programming. I've written a couple of 2d games (an asteroids clone and a parrallax scrolling shooter) and bought GCC4 recently to expand on what I've learnt. The thing is I'd like to start my engine from scratch and wondered if there was a bit of skeleton code to start from, ie just an initial setup without all of the GCC dependancies. Then I could go through the book a step at a time adding as i go along. Perhaps this is not the best way to go through the book and if not perhaps someone could give me some tips on how to progress from the beginning of the book. So far I have an empty solution-project setup the way the book suggests with the directory structure in place like I said I'm new to this so a little help on how to get started is all I need.

      thanx


      I think you should start with your empty project and work on components one step at a time.

      - Write an input handler (for keyboard)
      - Write a visual console (for debugging purpose)
      ...

      add components one at a time, each component will be your milestone. When you have an issue just go back in the book and check the specific chapter.

      Build your own stuff. When it breaks, you will know what to improve.
      MCSE/MCDBA/Programmer C,C++,PERL,PHP