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.
Thanks.
Thanks.
This discussion has been closed.
Comments
http://www.3dbuzz.com/training/bundle/c-plus-plus-complete
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 ! :)
http://www.3dbuzz.com/training/bundle/mathematics-bundle-volumes-iiii
I hope that helps.
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?
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.
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.
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.
[size = 6][url = http://www.makegamessa.com/discussion/535/zx-official-demo#Item_15]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 :)
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.
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).
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?
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.
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 ! :)
My game was also made in Game Maker
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.
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 (http://gamedev.stackexchange.com/) is probably a better place for in-depth C++ questions.
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).
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 )
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!
:P
PS. Thanks for the cool link :D
A bit more on topic : @fanie
Firstly 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.
Secondly
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 code...do 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.
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++.
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.
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...
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?
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.
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).
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).
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.
--
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:
"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:
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 side....best of both worlds :)
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.
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.
@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.
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.