Starting game programing

edited in General
Hi guys. I dont know if this is the right place for questions but I did register on this site because it is local. OK. I realy do need some advice on game programing and the whole learnig curve. Do any one have some advice on who to ask or where to get some extra help in SA? I mean like someone that can explain. I did start off with c++ DirectX 10 and have a couple of books but some stuff is still not clear. I'm completely new in the game making comunity and so on so please excuse.


  • edited
    I would recommend checking out's training course linked below:

    They are very very in depth about programming and making games, there are a lot of hours of training there but speaking from my experience it is totally worth it.I went through a good 30-40 hours of the Xna Xtreme 101 series and found that they explained things better than some of the books that I had bought.

    And if your math is crappy (as mine is :_: ) then they have a Mathematics bundle too yay ! :)

    I hope that helps.
    Thanked by 1Blanky
  • Hi @fanie, welcome to the community. :)

    May I ask what it is that you want to do exactly? I mean, do you want to learn how to program as a means to an end for creating games?
  • You can start at the FAQ:

    C++ is a hard language to learn if you don't have any experience. If you haven't programmed before, try something like GameMaker. Most of us here use Unity so we don't have to worry with as many nitty-gritty low level stuff as you would when using C++ and DirectX.
  • Thanks guys. It realy helps. Rigormortis, yes I do want to learn how to program and creating games. I am not like total noob with programming itself like the language and stuff. I did do programming at school in Delphi so the conversion to c++ was not that bad. I can say right, I do know how to program your normal every day app. What I’ve been doing the last, say, 4 months was trying to implement DirectX. I’ve progressed to me being able to texture any object (not loaded mesh) and light it. But like I’ve said, there are still some grey areas. But thanks a lot for the help. I sure do appreciate it. Rigormortis, I hope I understood your question correctly
  • O yes, the reason for me choosing c++ is because that was the only language with enough learning material available on the net. I did try Delphi at first but there was no media available, or lets say not enoug:-)
  • edited
    Ok, I just wanted to make sure that your interest was in making games and not in making game engines.(not saying one is better or worse, just wanted to know how to answer your question. :) )

    I recommend you download Gamemaker and Unity and poke around in those. Gamemaker is a 2D engine, and unity is a 3D engine. Both of them have free versions. There are a lot of tutorials and information on those two engines and since most people here use those two engines you can get more help from us.

    The reason you should start with engines is because you don't need to worry about implementing directX and things like that, you can immediately start making games.

    Also, if you are based near Joh'burg or Cape Town you should try and get down to the community meetups.
  • @fanie I agree with @Rigormortis that you should probably dive into Game Maker or Unity before attempting programming an engine (forgive my presumption if this is not in fact what your intentions are.) This however should not discourage you from ever attempting to code something from scratch, as this will give you much more flexibility (and I am totally envious of professional programmers). Jonathan Blow (Braid) and Tommy Refenes (Super Meat Boy) coded their games from the ground up and this sees to have worked out well for them. Just note, it is extremely easy to get caught up in the minutiae of engine building and thus not actually get to game design. I have witnessed this before. Nonetheless, good luck on whatever path you take and I hope to see you at the community meetups.
  • @fanie I would totally recommend Jonathan Blows talk (with slide show) on 'How to Program Independant Games'. It's fantastic advice on determining what to prioritize. He's insights are especially helpful, particularly on the subject of 'optimization.' It was a little hard for me to grasp some of the technicalities of his talk due to me not having a programming/computer science background, but it is a great talk anyway. Hope you find it useful.
  • I also suggest looking at GameMaker or Unity3D (or Unreal if you're hard-set on C++). Besides the fact that you'll be making games a lot faster you'll learning how these great engines manage textures, models and other tricks so you can implement them yourself in DirectX or OpenGL; but why roll your own when the professionals use these tools as well.
    Thanked by 1retroFuture
  • Thanks again guys. I do appreciate your comments. I did have a look at game maker when I started off on my “trying to program a game” journey . But I was kind of disappointed:-) Haha. I wanted to do the real thing haha (I’m not saying that GameMaker isn’t the real thing). I did dive into some of 3DBuzz’s tutorials (that MrNexy suggested) and its awesome. Rigormortis, I’ll sure will go check out Unity thanks a lot. retroFuture, I do like the more flexibility part haha. What I did up until now is that I’ve created a game engine and I’m re-using it in all my demo’s without re-programming it. Sure development is going on as I progress but I’m trying to focus on building a game. Thanks again guys. You gave me enough resources to study to keep me busy a long time :-) haha.
    Thanked by 1MrNexy
  • edited
    To drive the point a little more...

    Unity and Gamemaker all the way! Unity can be coded with C#, which seems like a dumbed down version of C++ (or less hardcore, at least), but trust me, it is C++ infused with magic. Very awesome stuff and loads of info online about it (this is coming from someone who dislikes Microsoft as much as the next dev)! If you want a nice mix of proper solid coding and an engine that'll do all the dredge work for you, go Unity with C#. Making an engine can be satisfying from a technical point of view, i.e. figuring out how it all works, and there are arguments that making your own to suit your needs is better than a one-size-fits-all solution like Unity. Thing is, Unity does fit almost all sizes and mostly fits it better than a tailor made suit.

    [edit] p.s: Unity *IS* the real thing :p many many companies/studios use it to make real games with real profit. Fortunately, anyone can get the Unity 'basic' version, which is free. The pro version has a few extra nice features that are important for a dev company or some advanced techniques, but the free version is fully capable of making top quality games.
  • @fanie, Just to get over the "real thing" issue, check out this demo made by a local dev:

    [size = 6][url =]zX Demo Thread[/url]

    You can also check out this video:

    once a game is made it's the real thing. Regardless of how you made it. Keep that in mind :)
  • Personally, I only dance to one song and when I do, I never wear shoes. Otherwise it's not the real thing.

    The above statement is what many people who want to get into making games have started sounding like to me. It's almost like a conspiracy theory people learn by osmosis in bad comp-sci classes.
    Thanked by 2retroFuture hanli
  • edited
    I'm not sure if it's pertinent, but a lot of the big guys kind of give off the big c++ programming vibe:
    Epic's Mark Rein said:
    Unreal 4 is architecture powered PC and console gaming and scales all the way from high-end next generation console down through PC developed titles for mobile and the web. It's written in C++ which is not only the de-facto language of AAA game development, but the de-facto language of programming. All the major applications and operating systems themselves are written in C++. It's the language that more people know than any other.
    Not that C++ is the worst thing ever or whatever, but it is kind of comp-sci gymnastics for Carmacklings with the most brain-biceps. Or at least, it seems like there's a lot of engine coding endorsements coming down from people who Carmacklings respect.

    Anyway... I'm not really contesting Mark Rein's knowledge or his statement. I guess I'm saying I can understand why comp-sci sorts might have a mindset of GameMaker or Unity or C# not being the real thing (since, if you're listening to Rein, he kind of implies they're not the real thing, as a head of UDK should).
    Thanked by 1retroFuture
  • I'm guessing that the average player probably doesn't give 2 shits about what coding language/framework has been used to develop the game they are playing. Showing off ones coding skills will ultimately mean nothing if the game itself sucks bum.

    I actually get somewhat annoyed at the insinuation that "Game Maker / Unity / Flixel / Stencyl /insert gamedev framework here" is not the real thing. The proof is in the final product. Is it a well-designed, playable, polished work of art... or is it a turd built on a custom engine?
  • So yeah, to address the original post for a sec: If you want to get into making games, start making games.

    Let me re-iterate: START MAKING GAMES!

    Fretting over which language to learn before you're magically allowed to make games by the tech cabal in the sky is not making games, it's inventing reasons not to try and moving your goalposts when you actually do. Fretting over which game to make because you'll only get one chance at this thing so you'll have to do it right isn't making games, it's misunderstanding how often you need to fail horribly before you can succeed. Fretting over if you should show people what you're working on or not because they might steal your awesome concept isn't making games, it's killing your games before anyone gets to play them and only hours and hours of play and feedback can make games good.

    @fanie: You say you know Pascal syntax from Delphi? Sweet, Game Maker has support for Pascal-like syntax. Pick that up and make Tetris. I do not care how easy you think it is, just make Tetris. You'll find that all the things you thought were important are actually easy and all the things you thought were easy are incredibly hard. That's a good thing. Go do good things.
  • More important than what language you are using is how well you understand the principals and concepts of OOP , people will switch languages and learn new syntax when they have to.If you don't have a proper understanding of OOP principals and concepts then you're going to have a bad time.

    I started out learning C# about a year ago and since then I've switched over to UnrealScript(essentially C++ lite) and even learned ActionScript2(which is more Java based). Whatever language you choose to learn first you must keep in mind , that this is not going to be the only one you'll learn to use if you are determined to develop games.

    Make good games regardless of the engine you are using and have fun ! :)
  • Ok thanx guys. Enough with this “game programming language engine” discussion. I’m going with c++ and directX and my question was, is there any one, on this forum, that can help me with some small difficulties that I encounter? And that all in c++. Just that. Thanx again for all your comments:-)
  • @disleksia said

    @fanie: You say you know Pascal syntax from Delphi? Sweet, Game Maker has support for Pascal-like syntax. Pick that up and make Tetris. I do not care how easy you think it is, just make Tetris. You'll find that all the things you thought were important are actually easy and all the things you thought were easy are incredibly hard. That's a good thing. Go do good things.
    I second that. I also learned Pascal in school, and if anything Game Maker is actually easier than Pascal. Game Maker can be used to build your prototype. If you really want to, you can port that over to another engine. But for the mean-time, learning how to make games with Game Maker is the easiest solution for a novice programmer. It allows you to build you game without having to stress too much about other factors.

    My game was also made in Game Maker
  • edited
    fanie said:
    . I’m going with c++ and directX and my question was, is there any one, on this forum, that can help me with some small difficulties that I encounter?
    Maybe... but not really that likely. I mean, I think the Ninja crash guys dealt with making a game in XNA (though that's C# and DirectX), and some people here have made games in C++ back in the day (myself included).

    But programming forums are a better place to go for C++ and DirectX information. It's not really a sensible path to making games in this country.
  • I'm not a big fan of the group mentality that gamemaker/unity is the only way to make a game (even though I believe it is the best way) - look at this cool game: guess what it was written in? QBASIC! So it goes to show that you can use any tech you want and still make a cool game. Of course some ways are (way, way) harder than others. For example, Roller Coaster Tycoon was written almost entirely in assembly.

    Still though, almost all of us are interested more in making cool games than programming for games, you can try ask here, we might be able to help but stack exchange ( is probably a better place for in-depth C++ questions.
    Thanked by 1EvanGreenwood
  • @raithza No one is saying that Game Maker / Unity is the only way to go, there is no 'group mentality.' You made the point in your post where you state "almost all of us are interested more in making cool games than programming for games"
  • edited
    @RetroFuture I think @Raithza may be partially suffering from some overexposure to my third-party development evangelism rants (which are a real thing/ordeal), which he witness a lot more of than most (since he works with me).

    I think it's fair to say though that there is a bit of a reactionary movement in South African game development against building one's own engine. Historically a lot of money/time has been wasted on that, which isn't to say that all engine development in South Africa in the future will be a waste, rather that there may be some over-correction (in sentiment at least).

    Although that isn't to say that I think correcting against spending time building engines (instead of building games) is a bad thing. In fact I'd pretty happily say that third party development tools ARE the only way to go (if you want to make games in this country).
  • edited
    For the ... err ... lulz/record/hamsters, I can help out with some C++ programming, I have quite a bit of experience with it. I don't know DirectX but I do know OpenGL which shares a lot of conceptual framework at least. Note that I'll try help, I can't promise, and I do seem to be the only one putting my hand up [edit, plus one or two more I see now] :p You'd def find better luck on programming forums.

    It is also from my C++ experience that I'd strongly suggest C#, I also used to be C++ all the way, it is the more difficult option (more challenging, one might spin it), and if you want to make a game engine in order to learn the ins and outs of rendering operations, 4x4 transformation matricies, texture buffer objects, memory and everything else that isn't directly 'game making', knock yourself out! C++ will knock you out for your trouble anyway :p but it's a great way to really harden your programming-foo and get a deep understanding of engine components and how computer machines work deep down. It won't really help you make games but it is really fun if you like programming and computer systems/mechanisms in general.

    *** For the rest of this post, sound the C#-is-great warcry! ***

    C# is an awesome language, and raxter-the-hardcore-programmer-from-3-years-ago would hate me right now for saying it. It has all the great things of C#, like strong typing, object orientation, generic typing, inheritance, blah blah blah. But also has all the nasty bits of C++ taken out, horrid pointer/reference syntax, proper virtual classes (seriously, C++ is terrible under the hood with this, or at least was when I last checked), it has orgasmic 'function pointer' capabilities and easier memory management (that you can manipulate if you so desire).

    Not saying you have to use it, but I really recommend it if you want a modern language with modern features that is still solid as a rock (solid as in not a scripting-esque language, i.e. no fluffly variable types and code scopes that venture to the nether regions of your project, etc etc etc).

    Either way, as long as your are having fun and learning ^_^ just make sure you are clear with yourself what it is you want to learn or achieve (or be like me 4 years ago, ignore all the advice and do what you want... because... fuck the police :p )
    Thanked by 1creative630
  • edited
    @BlackShipsFilltheSky I have seen that local sentiment does not recommend engine development, which I largely agree with, but I would also not say that it is of no value. If a developer already has a custom engine, then by all means use it. I think the main concern (to my mind anyway) is that programmers can spend months, even years building elaborate engines packed with all kinds of clever scripts and routines that ultimately don't result in a playable game and only serve to impress other programmers. I will however once again link to Jonathan Blows "How to Program Independent Games" talk and slideshow, particularly to show how to avoid the many pitfalls that can befall a developer indoctrinated with bad Comp-Sci 'wisdom'.
    Thanked by 1raxter
  • Lol I'm also going the c++, SDL and OpenGL route and it's been 2 years now of making my own engine and game but I'm starting to realize more and more I like the nity grity stuff but what I really want to do is make games! not engines yet this time spent learning I would not trade in for anything :)
  • edited
    @LittleBear In spite of the opinions I have expressed so far on game engine development, I am massively jealous of those who have the programming know-how to build one. They could probably come up with 10 solutions in 1 day for a problem that would stump a novice script monkey like me for a week.
  • @retroFuture: While I agree, I've also seen the other end of things, where people with technical know-how can sometimes over-complicate things trying to do it the "right" way. Fling Fu was a fantastic example, where Herman made a super awesome prototype without actually knowing that one could nest if statements...

    Several of us were all like, how the hell did you get procedural walking to work? And he was like, trololol, all I did was turn on physics, and fix the head height... and all of the "walking" was the physics just falling into place the whole time. It worked great!

    Thanked by 1retroFuture
  • @Elyaradine A truly great point you've just made :)
  • edited
    @Elyaradine ...and I'll state again, Jonathan Blow discusses how 'the right way' can often be at odds reality.
  • edited
    @retroFuture Don't sell yourself short dude what Elyaradine says is true I might look at a problem one way and your way might be alot better than mine that happens alot on the technical side trust me that's one thing I have learnt well, I have checked out game maker when it was like v4 or something way back when but it just doesn't feel right to me but I have seen poeple come up with amazing games using it. Is it just me or does it seem you have to pay for every add on in Unity? Sorry for the q don't have alot of knowlidge about Unity :/

    PS. Thanks for the cool link :D
    Thanked by 1retroFuture
  • @Elyaradine & @retroFuture, I often fell into this trap of doing things "the right way". Recently I have come to think of the right way, as the way that actually works....whatever form that might take. It's easier to improve something done the "wrong way" and actually having something to test with and build on, than spending so much time planning the "right way" only to think there might be a better way and not having something at the end of the day.

    A bit more on topic : @fanie

    fanie said:
    Enough with this “game programming language engine” discussion.
    You can't tell the internet what to do :P

    But seriously, the reason everybody is discussing this is because they want to help you make the best decision on your journey to creating games. The problem is that the journey to creating games and the one to creating game engines are a bit different. If you want to create games, and want a path of least resistance then an engine(any one that suits your needs) is probably the best way to go. Unity and Gamemaker are popular choices because of the flexibility they provide and the vast amount of information you can find for using them. Hence the arguments for using engines.

    If you are starting out I suggest you expose yourself to as many things as possible. This kinda works in all walks of life. If you want to start building stuff in introductory stuff in every language you can find. The reason for this is that you want to find the language that makes you the most productive, especially if your starting out and can easily lose motivation. C++ is in generally not the best for starting out because it's notorious for being difficult on beginners. So try a bit of everything and see what suits you best. That way when you decide on a specific tech/language it will be a better informed decision.
    Thanked by 1retroFuture
  • fanie said:
    I’m going with c++ and directX
    This kind of comment makes me die a little inside.

    If what you really want is to make games, use the tools that are available.

    I always liken engine programming to trying to write a book by carving the words into a tree with a rock, despite the existence of pens and paper. Game development is the only field were people refuse to use tools for no apparent reason. You 'll never see a builder refuse to use a hammer or a screwdriver because "it's not the real thing".

    And if engine programming is what you really want to do, I would certainly recommend Java or C# over C++.
    Thanked by 1retroFuture
  • @Squidcor: I started developing games in C++ and OpenGL. I did that for years and even pushed a nifty game or two out that way. Sure it isn't the fastest way to develop something but writing my own engines has made me the programmer I am today. I did switch to Unity a month ago but the experience I gained in writing my own physics systems, lighting engines and just general game engines as a whole has left me with a skill that gives me an edge over many other developers.

    People who want to make games in C++ should not make you die a little inside, it should encourage you to know that SA is on the road to gaining another indie.
  • edited
    I think the reason this discussion pops up so often and yet seems to be so utterly ineffective most of the time is down to simple perspective differences:

    A newbie/hopeful game developer approaches the idea of game development from the point of view of a single task that needs a certain amount of mastery: Program a game on specific hardware. There's a lot of noise out there in the general gaming scene about the tools that specific high-profile developers and studios use, but that's marketing noise and not actually relevant technical information. So, hopeful game developers see a simple list of things to achieve: Learn specific tool that's bullet-pointed on the back of game boxes, code an "engine" because that's what all games need (again, according to game boxes and the press) and then have an awesome game idea to put in there! Yay! Game complete!

    The problem is that this isn't the actual path of game development at all... Much like how a professional soccer player, let's say Ronaldo, plays with specific boots and everyone knows this because they're luminous fuchsia and have lighting-bolt shaped blades (fuck you, Nike). This is a marketing smokescreen to make people WANT those stupid boots, Ronaldo would out-play the hell out of you barefoot and on broken glass because he's simply that fucking good, it makes no difference what footwear or boot he's wearing. Other good footballers know this, but there are still hordes and hordes of youngsters that badger their financial support sacks (read: parents) for those lightning boots that will make them pros.

    Exactly the same thing happens with C++ and rolling your own low-level code in game development, except it's worse because the skills are so obfuscated. You have to be pretty good at programming to see why John Carmack's code is so wonderfully optimised, you can't just open up the DOOM source and marvel at it without a ton of effort going into cultivating that understanding. It's that perspective that the sorts of advice you're hearing here is coming from... And the key thing to remember here is that these people HAVE MADE GAMES, so they're not talking out of their butts.

    So, perhaps I can suggest a different way to talk about this stuff: A series of things to understand before making your own games becomes a reality.

    1. You need to understand what existing games are doing in their code. If you don't, how could you ever hope to build your own games? Even if you want to do something completely different (like deferred shading a few years back - oh S.T.A.L.K.E.R you broken dreamland) you still need to understand what's going on in modern normal games right now in order to know what would actually be different! How do you do this? Take apart existing games, read up on source articles, re-compile old open-source games.

    2. You need to understand what game engines and systems are out there and how to use them. How else do you expect to be able to produce your own version of an engine? Would you trust a plumber who had never used a wrench before, but arrived at your house with a drop-forge and some molten steel so that he could make custom tools to fit your pipes? What do you do to learn this stuff? The same thing you do for the next point...

    3. You need to understand the differences between game logic and game support systems. Game logic is fantastically complex and will differ wildly from game to game, meaning it will always involve solving a set of problems that's vastly unlike any other set as a whole. Game logic is rarely documented anywhere. Game support systems are generalisable systems that people know how to write, they're implementations of common algorithms with names like Carmack's Reverse (a way of calculating shadow-volume intersections for vertex shadow calculations) in many ways implementing your own versions of those algs is a good way to learn, but it's never going to help you get any closer to developing a game, because none of that is useful for gameplay. How do you learn this stuff? Mod games, mess with scripting systems, use every engine or framework you can find for a week at a time, spot the similarities and spot the design decisions devs were able to make for their underlying systems based on the kind of game they were making.

    4. Realise that there is no way using a tool that isn't "the real thing" is going to make you a worse coder. You'll naturally extend yourself to harder algorithms because you'll be producing stuff that's more interesting to OTHER PEOPLE (because, truth be told, nobody really cares about that spinning triangle but you) - give people a game to play and watch their reaction, that kind of rewarding experience drives you to try even harder next time. And even if you do come up with a fun game in some "easy mode" tool, FUCKING YAY! You just made something that people like, win! You can always re-code that game in C++ or whatever other language you want, which will then be a focused exercise of you only learning that language, instead of having to try to be superman and learn a language and make a game at the same time.

    5. Acknowledge that your first game isn't going to sell. That's ok, nobody's first game sells. Get over that idea now so that you don't hamstring yourself with the dual mental traps of "I have only 1 shot at this, so I'm going to keep working on this crap game that I hate because I have to make it better or I'll be a failure" and "I'm going to waste loads of learning time thinking about how awesome having a yacht would be and worry about what I need to do to get on Steam or the Android Marketplace or iOS that I'm never going to actually work on the actual game at all". How do you not do that? You learn to fail fast and fail gloriously, make horrible games and SHOW THEM TO OTHER PEOPLE! See what sticks, throw out prototypes as fast as possible and be incredibly sarcastic in the "Oh, man, that'll never actually work if I do it that way..." fashion.

    6. Give yourself a fucking medal for reading this far. How do you do that? Go out and make a game. It can be chalk on a table, cardboard and dice, assembler on an amiga or drag and drop in Scratch. JUST MAKE A GAME and then play it with people.

    I wish people would stop wasting time focusing on silly things like C++. A game originally made in Game Maker inspired the general manager of Mythic Entertainment to show Aeq and I around EA's HQ last week. Don't worry, we didn't tell him it wasn't actually the real thing...
  • @bigbadwofl: I'm curious as to what that edge you're talking about is? I worry that technical proficiency in a language people don't actually have to use to make games might be a bit of a tautological advantage ;)
  • @dislekcia: I am not flaunting proficiency in C++ as an edge. I'm referring more to knowledge of how the underlying systems work (Lighting, physics, game loops , etc...)

    Do you feel that someone who has used a tool all his life vs. someone who started out writing his own engines has the same skill-level and will produce the same results?
  • edited
    @BigBadWolf I'd argue that someone who used a third party software their whole career would have a distinct advantage over someone who's worked on their own engines. In that they would have more experience designing gameplay.

    I'd love to take back the time I spent learning C++ and SDL/OpenGL. Even though I made games, and those games landed me a full time game development job which led to starting my own company. I think if I'd used Game Maker instead, I'd have reached the same point, but I'd have more useful skills today.

    In my experience most technical challenges are solved spaces, and they're only going to be more solved, and the solutions easier to find, in the future. Obviously there are situations when you HAVE to develop some custom system, but the time for that is when you don't have better options.
    Thanked by 1retroFuture
  • @BlackShipsFilltheSky: That's an interesting point. I've never thought about it from that angle. I agree that someone who has only used a tool has more experience in designing gameplay. I've only ever thought about it from the perspective of programming expertise, not actually designing games.

    So I think I'll step down, using a tool right from the start might be the better alternative regardless of the person (if your goal is to only make games as fast as possible).
  • edited
    @Bigbadwolf I might be taking a fairly brutal view of game development though.

    Solving puzzles is fun, I can understand the joy of mastering technical challenges, and having diverse skills, even if you don't always use them or need them, isn't a bad thing.

    And there is a reason why the IGF have a technical excellence prize. I wouldn't want to discourage exploring technical challenges in interesting new ways (only exploring already solved and trivial technical challenges and being held back by handicapping yourself).
  • I've only ever thought about it from the perspective of programming expertise, not actually designing games.
    That right there is the difference. If you want to make games, the design skills are what you need to be working on. How you get the triangles on the screen is irrelevant.
  • I for one can see the advantages of using either way, but I have HUGE tendencies toward the one building a better foundation (think long term, not only short to medium term)

    Develop yourself by building your foundation the bottom-up way:

    You could tackle problems and develop your proficiencies from either top down or bottom up. In the technical fields, like sciences and engineering, the bottom up is preferred and enforced.

    Developing any software (e.g. engines) contains a lot of design, good structured design hopefully. Creating your own engines and makes everything work together gives you really good design experience.

    If you venture into any academic or technical field, you will notice that a lot of practices, design, methods, etc. is attained from other fields or used in other fields.

    Sure, to be a game designer in the short run choosing the means which will give you the most experience about designing games might appear best (this is not the only aspect of creating games, believe it or not. software architecture, software engineering methodologies, software design, coding, maintenance.)

    I never heard of any developer that prefers a project manager, software architect, software designer or manger that has no programming experience. From my experience (which I am under the impression that this is a very common believed) the project has greater chance of success if they do have software development experience.

    Why do you think that Computer science students to learn assembly? Why do mechanical and industrial engineering students learn chemistry in their first year? It is to build a strong foundation. Fanie, seeing that you place importance on the whole learning curve, keep this in mind.

    Build a strong foundation from the bottom up.
    Learn your environment and tools before you go to the top and start building there.

    If you would build from the top down, there is bound to be gaps in your knowledge that will haunt you, these are weak points in your foundation. E.g.: If you got an idea of an awesome light effect that you want to implement that would make your game give your game a real awesome feel, and you cannot find an already existing effect in the tool. You, out of a lack of basic knowledge of creating your own (lack of confidence), will probably compromise and go with the tool's standard option, thus, drop the quality of your product drastically to what it could have been.
    Having never created an engine and only using tools will limit your knowledge about the engines and what the engines can do, if they cannot do it, how you can implement it (again improving the quality of your product!).

    Sure if we all had awesome programmers who knew all these stuff already, we could just concentrate on game designing. But that is not the case, sadly or not, depends on what gives you kicks (I for one love developing, architecting and designing games).

    Your ability is limited by your knowledge. Let’s say you have a lot of knowledge in physics engines, your games will probably have awesome physics. Let’s say you have a lot of knowledge in art and sharers, your game will probably have an awesome appearance. This is because you know your tools and what they can do really well.
    The gaps in your foundation (education) will cause you to compromise quality and greater awesomeness for that which matches your abilities.

    Want to make games with awesome physics, sound, 3D looks etc? Start by building your own engines rather, play around experiment, and don’t fear anything because of a lack of knowledge; you being here and wanting to learn game programming and learn correctly tells me that you will do great at not fearing to learn something new due to a lack of knowledge.
    Advice like: use tools rather, could thus possibly be the wrong advice, you have to consider the persons purpose and existing knowledge.

    (fanie mentioned in his second post that he wants to learn how to program, and in his fourth post it became evident that he wasn't into the whole, drag here and there and BAM there is your game (he was disappointed by his experience with gamemaker for what seems to be exactly this reason. )

    Giving someone who loves game developing and have a desire to program and building engines advice to rather use a tool that takes this away from him could cause the person to lose his passion he had doing stuff he doesn't like as much. Care is needed to give the right advice to the person. In fanie's first post he mentioned that he needed advice on game programming and the whole learning curve.

    In school your foundation was built from the bottom up, the same with university. School and universities curriculums are made by people who specialize in educational development. Learning from the bottom up is your safest bet. Baby steps.

    tl;dr: Fanie, Take the advice which will build your foundation the best. My advice is develop yourself from the bottom up, if designing games is where your passion lies, do yourself a favour and create some game engines, play around without tools every now and then, else C++ (if you get frustrated and unmotivated, switch to something like C# for a while) and OpenGL / DirectX. Develop your own engines. You will have a greater sense of pride and achievement in your product.
  • @Blanky: Thanks for taking the time to type out what I was too lazy to do.
  • edited
    I kinda saw that @fanie was talking about game programming from the get-go, so I pretty much assumed he wasn't talking about actually making fun games so much as building game tech, and left it at that.

    But I feel @Blanky's post is rooted in a fundamental misunderstanding that conflates game programming with game design, and this misunderstanding is pretty much what causes us all to be raging at each other. >_<


    It's been described that a game can be broken down into (at least) four pillars:
    • mechanics (the abstract space that contains rules, goals, and a psychological push toward engagement)
    • technology (the implementation, and the interface through which the player interacts with the game mechanics)
    • aesthetics (the visuals and audio that help describe what is going on in the game)
    • story (the world in which the game exists)

    "I want to learn C++ and DX11/OGL, because by writing my own renderer and shaders I'll be able to be an awesome artist!" would totally make me rage. You become an awesome artist by practising making art, not by making game engines. Experienced game artists can tailor their art to fit any game engine, while still maintaining its beauty. The gorgeous work in new engines like the new Unreal and CryEngine tech demos are made possible by powerful new technology, but made beautiful by artists.

    "I want to learn C++ and DX11/OGL, because by writing my own voxel-based procedural terrain editor I'll be able to be an awesome game writer!" would make game writers rage. You craft captivating worlds by learning what kinds of grand narratives are able to draw people in; how to develop interest and depth in stories and characters, and to translate these powerfully emotional concepts into visuals, audio or words.

    "I want to learn C++ and DX11/OGL, because by writing my own physics I'll be able to be an awesome game designer!" makes game designers rage. Programming experience is absolutely helpful (just as any experience in art or writing are), but the actual game mechanics are independent of all of them, and can be implemented in card games, board games, the Starcraft2 World Editor, a piece of paper, a conversation, a ball, a pair of swords, or some chalk on a pavement. If it's a _game designer_ that one wants to be, then it's just as ludicrous to focus on making an engine from the ground up to learn game design as it is for any of the other above fields.

    "I want to learn C++ and DX11/OGL, because by writing my own tech I'll be an awesome game programmer!" This is about the only path that makes sense.

    These are separate and distinct! If you're on a really small team, then the lines can definitely be blurred, but for the sake of learning stuff, it's really useful to know that they're different, so that you doesn't spend a great deal of effort learning one of them while mistakenly thinking that you are learning something else.

    Of course, if you enjoy programming real-time renderers, then go for it! :D :D :D Just be absolutely clear about what you're actually going to be learning, because it's going to be years before you scratch the surface of actually designing games. So, in the context of @Blanky's post:
    tl;dr: @Fanie, Take the advice which will build your foundation the best. My advice is develop yourself from the bottom up, if designing games programming real time renderers is where your passion lies, do yourself a favour and create some game engines, play around without tools every now and then, else C++ (if you get frustrated and unmotivated, switch to something like C# for a while) and OpenGL / DirectX.
    Thanked by 2Blanky mattbenic
  • Thanks for the comments. Blanky, you got the point of my question 100%. Thanks for that. Realy did inspire me to keep on learning what I like to learn. And just, may be another misunderstanding, is that yes, I DO WANT TO CREATE GAMES. But by the way Blanky explained. From the bottom up to the top. And like Blanky mentioned, I’m not going to be scared by a lack of knowledge. C++ is what I’ve chosen solely because there is a lot of media available on the net to learn from. And it isn’t that bad at all. Yes I did do a bit c# and yes it is easier to use but not enough 3D material on the net that I know of. Elyaradine, thanks for that graph on the four pieces of a game. I’ll go and read about it.
    Thanked by 2hanli Blanky
  • @fanie, although I agree with @blanky that knowing more is better than knowing less, I don't think building engines is learning game design from the ground up. If you really want to start learning game design from the ground up start creating analogue games(board games). You will learn an awesome amount of game design and there is literary no technical barrier to start making them. (I assume that you can read and write...because of your posts and stuff :P)

    That being said, I think the best advice I can give you at the moment actually goes back to what I said about exposing yourself too as much different things as possible. Forget about labels and what you want to "become". Go through this thread...try to pick out all the things people suggested you use. Pick up the free copies of the engines, get some compilers for all the languages and try to find some cool blogs or tutorials to work through for everything. Maybe even a book or two.

    Then, when you've got your list of potential stuff to learn start with the first one and spend an hour with it. Go through the whole list like this and once you've gone through them all eliminate the one you least like to work with, whether it's an engine or a language. Keep doing this until you've crossed of everything from your list. At the end you will have learned a lot of different things, but more importantly you will have found what you LIKE the most.

    Though if you already know you like programming the most I suggest doing the engine stuff you like so much and still creating board games on the of both worlds :)
  • edited
    @Blanky I'd love to know if you're actually making games that use those skills that you say are so important. Otherwise I'm going to have to call you out and say, please don't give destructive advice. Especially because it's the advice Fanie wants to hear.

    Unless Fanie's goal is to be a hobbyist, or move overseas and work in AAA (or really large Indie), (neither one of which is going to benefit South African game development), the stuff you're suggesting he do is going to be totally impractical.

    No game studios in South Africa code their own engines or use C++. And that's not going to change any time soon. It's simply WAY too expensive. And it's only going to be worse idea in the future.

    Getting those sorts of skills is going to put Fanie in a position where he'll be unable to use his skillset in this country, so we may lose another promising programmer.

    It's 2013. Things aren't moving towards more game developers doing low level work. Maybe if this was 2006 that kind of experience would be practical, but indie game development is only going to get more third party based from here.

    And while he is developing his low level coding skills other developers will be practicing skills that actually lead to better games. He'll end up overqualified but underexperienced, if he stays on that course, and that's a crappy situation.

    Ironically you suggest that learning the low level stuff is a good long term investment, I only see the opposite as true.
  • @BlackShipsFilltheSky: If I had started gamedev by using a tool, I wouldn't have stuck with it as long as I have. Ultimately, regardless of how false the mindset may be, when starting out in gamedev, lots of people feel that using a tool will not teach them the fundamentals of what game development is. Note, I didn't say game design and also note that 'what game development is' might not be a skill you need in the industry any more. But if that's what excites fanie, then so be it. Maybe he isn't a game developer then, maybe he's a technical person who'll find out he doesn't want to write games at all. He'll find that out for himself sooner or later.

    Developers are stubborn and they will ultimately do whatever they want. Sure we can guide them, but haranguing them on why their ideas are silly will only serve to alienate them. This is a very opinionated forum (and that's good) but it's also a forum where there is more bickering than actual posts on games being developed by the forum users. This lends an air of futility to much of the bickering.

    @fanie will take the route he wants to and when he hits a stumbling block he will remember the advice he got here and will be able to make an educated choice on whether to move over to a tool or not.

    Lastly, @Blanky is allowed to give advice you feel is destructive since that is the way he thinks and that's ok. More voices are good regardless of whether you agree with it.
    Thanked by 2hanli Blanky
  • @Elyaradine: I would vote for your post to be a sticky in a “New to creating games post”. It is a really good and helpful post to people new to creating games direction. Did you get the four pillars from the book: The Art of Game Design> Thanks for correcting that part of my post. I believe it to be more accurate now.

    @bigbadwofl: You made some good points there.

    @BlackShipsFilltheSky: I apologize if any of my advice is destructive, this is really not what I want to do as I know how badly it can affect people. "Especially because it's the advice Fanie wants to hear." This alone should give you a good indication where the persons passion lies. Leading Fanie to sources where he might find even greater passion is better (who knows, he might love game designing so much that he never wants to write any code in his life again). But the passion part is the key. Where there is passion there is motivation and bounds of creativity. Destructive advice can stifle this, I do not want to be a stifler.

    Fanie seems to have much of the same interests than me, it is thus easy to help him, as for 'destructive' advice, I am not destroyed yet, and I do my best to follow and live my own advice as I am sure most of you do. That is probably why he feels so strongly about my advice, it seems to appeal to his interest and the way he wants to learn.

    "Otherwise I'm going to have to call you out and say, please don't give destructive advice."
    Most of the people in my friends circle, academic circle and work environment develop in C++. I make games in C++ primarily. It is a personal opinion of mine that people fear C++ unnecessarily (I have no evidence to back this up, thus, personal opinion). I hope that this gives you some peace at least about the "destructive" advice part.

    On the 'destructive advice' if I were not to have made games in C++, could I request more evidence to back up your opinion? Opinions don’t mean much without the right industry experience and evidence to back it up. I am aware that giving advice about a field where one has no experience is dangerous and should be avoided, but this is not evidence that it is destructive.

    Each person is unique, and because of this, there isn't a “one opinion/advice is best for all” solution. Finding out what the person wants (where his passion lays) will lead you to the advice that will make him tick, enjoy what he is doing, find the information he wants faster.

    I Have a friend who tried game developing to learn programming. He doesn't have much interest in game development. Telling him to concentrate on game designing would not be teh advice he wants to hear.

    @Rigormortis: I like your idea about: "exposing yourself too as much different things as possible" but I do believe at the point where fanie is, he will probably need more of a foundation first and some experience first. I read a study a while back that showed that learning using ‘multitasking’ (taking on a lot of different things at the same time) is much slower than isolating a task and focusing on that. Focus is very important when it comes to learning fast and qualitative. Once he has the foundation, experimentation will be of much more value, he will have something concrete to compare his experiments against.
    Thanked by 1hanli
  • Maybe he isn't a game developer then, maybe he's a technical person who'll find out he doesn't want to write games at all. He'll find that out for himself sooner or later.
    Except what he believes he's doing as "writing games" won't actually be the reality of writing games. Meaning any decision based on that assumption is going to be a real shame.
    Lastly, @Blanky is allowed to give advice you feel is destructive since that is the way he thinks and that's ok. More voices are good regardless of whether you agree with it.
    Surely any opinion needs to be defended? Simply saying something doesn't make anything right, nor useful. Yes, people can say what they want (within reason/laws/etc) but other people had damn well better be asking those people to back up their opinions when they don't make sense. I think it's perfectly valid to ask @Blanky if he's ever made any games: If he hasn't, then his opinion on how games are made is tarnished by neither wisdom nor experience.

    If a Homeopath tells me to do something when I'm sick, there's no way I'd take that as seriously as a trained doctor's perspective.
This discussion has been closed.