31 replies to this topic

[RubyNL]

A little tip. If you're gonna make a game, first make some smaller, simpler games in the same genre. By simple I mean especially the graphics. Good graphics are pretty hard to archieve, most game studio's have whole teams of artists for character and level creation, and in my experience, good graphics are one of the hardest things to archieve (together with a general fun game experience: making the whole game not too hard or too easy, not confusing the player, and keep rewarding the player without giving him more of the same every time).

The first small game will probably be a mess, maybe you won't even finish it. But, as a result, you will have a better idea of the structure the program needs to have. Sometimes, when you're able to implement a new feature in your old engine, you will think 'OMG, if I redesigned the whole thing it would be so much easier!'. Keep your old projects, and comment everything well, so you have usable source to consult or even use directly if you're having trouble. Also, think about splitting things up in classes, if this doesn't hurt the readability or performance of your game. Also save useful functions in a seperate file.
For me, this way of working results in much cleaner and faster code. Please note I didn't ever code a big game, so I don't know how well this way of working scales with the projects, possibly this is too much work for big projects.

Last thing. You've probably heard this before or thought of it yourself, but seperate your engine from the levels, graphics, and gameplay as much as possible. It will be easier to make special effects (graphical effects or gameplay-wise, for exception, inversing the gravity will be easier when you have some force vectors instead of a hardcoded "player.y += 5;" each frame (as a figure of speech)). This can cost a little bit of performance, but things like this can usually be done pretty efficient. Else you just have to find a balance, or try both ways and then decide what's the way to go.

Good luck

[fruki]

Trying to avoid the flame war going on here: Flixel and Actionscript.

I'm a very hardcore C++ programmer (I'm working in the industry for about a month with 8 years of indie game development) and in all that time the only moment where I went "what the fuck" was when I was using Flixel and Actionscript. It was a marvellous moment of joy to see in a week of work a game I could show everyone. In C++, Java, etc you are going to find yourself fighting the game mechanics AND the language, libraries, compilers, etc. With Flixel and Actionscript you are going to get going like a champ in no time. Learn the basics, classes, accessors everything and at the same time make a game fun and fast. For me the motivation is key and specially at the beginning so I'm recommending it to all new people to programming. Also try to make a pong or something along these lines to get going. If you think it's aiming too low, then it shouldn't take you more than a week shouldn't it? ;) And after that you can try new things.

That said, XNA and C# is fast too, Unity 3D is also kind of good for experimentation although I wouldn't recommend it because it has no real practical use in a professional career.

After your first game, review the technology and try different things.

Edited by fruki, 04 July 2012 - 05:19 PM.

[Mike Bossy]

First things first congrats on listening to your gut. Too many people stick with a job/field/career just because they have time invested in it. If you get deep into something and realize that you're not going to be happy doing it then you should find something else. Life is way too short to be stuck doing things you don't like. If you like the idea of coding and making games then dive on in.

There are a million different approaches to learning to code and a million different technologies. The key is to keep learning new things and keep iterating on what you're doing. No one ever gets to the point where they have learned everything about software engineering. If game development is what you think is going to be your passion then try something like Unity where you'll pick up the basics of C#. If you still have that passion after learning the ropes then I would suggest diving into C/C++ next since that will give you the strongest base for jumping to any other language since it's nice and close to the bare metal. Of course that's just what would work for me. Everyone is different.

Best of luck in the new endeavor and enjoy the ride.

[kunos]

well my take on the subject is that when you are learning your first programming language it doesn't really matter which one you learn because you'll be overwhelmed by it anyway. So many new informations and a need to build a "programming brain" by understanding how a program works are going to make the languages look pretty much the same. Once you've learned to program, applying the same concepts to different languages will become easier and easier.
To make your learning process as easy and smooth as possible you need to choose the path of least resistance in the available technology.. my first suggestion would be to forget about Android or mobiles for the time being, and learn whatever language you want on the PC, setting up and deploying to phones is not something you should bother with right now.
So yes, Java / Eclipse is very good to get started, I personally think C# / Visual Studio is a superior combo from whatever point of view you want to look at it, but again, the bottleneck is you, so don't waste too much time picking languages, if you have Eclipse ready to go, go with it, get a good book (the Thinking in Java book is old but still good and free to download in PDF) and get your basics right.
One thing to avoid is to just go through the book for years in a passive way.. after the first couple of weeks while you get acquainted with the compiler, the error messages and the build system in general, always work in parallel with your own mini projects and the book. The point is not to replicate the book's example, the point is to constantly understand the concepts expressed in the books and how these can actually make it possible to get your projects done.

Work your way up but don't be scared to try to do things.. I wrote a 2D tennis game in C back in the day with a single "step" function some thousands of lines long with the entire program in one huge .c file

Edited by kunos, 04 July 2012 - 11:17 PM.

[JDGamedev]

The Croaker,

I'm in no way a professional game developer yet, I'm just working on that part myself, so keep that in mind. I just figured another point of view couldn't hurt. Also, my point of view is probably pretty different than most of the people on this forum.

First of all, if you want to make games as a career, it will probably take you many years before you consider yourself "successful." The learning part will take quite a while as well as figuring out how to make money.

I would HIGHLY recommend you read the book Crush It written by Gary Vaynerchuk before you do anything else. It may seem unrelated right now, but once you read the book I think you'll have a different outlook on how you can make game development a career. You might also want to consider what the goal is for your career. Do you want to make games as an indie company and distribute them on your own, do you want to work in an office for a commercial gaming company and collect a paycheck, or would you like to do something completely different.

As far as what language to learn, I completely disagree with just about everyone who posted here. I think it is almost negligible. I spent wayyyyy too much time trying to answer this question myself. What I should have done was just pick one and program my ass off. Now I feel like I'm behind because I spent so much time trying other languages out and searching for advice via forums and reddit. Just pick one that you enjoy or know a bit about, and learn something everyday.

What I think my biggest problem is when trying to learn to make games is that I'm focusing too much on the long term future. Right now, it really doesn't matter. What matters is making the game I'm working on or maybe just learning one concept right here and right now.

Anyway, my final piece of advice and a sort of TL:DR section is this:

Don't worry about what will happen in 5 years, just focus on getting a little bit better everytime you program. Start making a game TODAY no matter how simple it is. Don't quit programming if it is something you enjoy. No matter what anyone else tells you.

I wish you the best. Game development is fun as hell!

[Shippou]

People seem to make it sound like in C/C++ you could potentially blow your PC up in a puff of purple smoke. Don't let the word "dangerous" scare you forever into higher level languages such as python or java. Dangerous simply means if your program compiles fine but behaves wrong you'll get a little popup telling you the program hung. Big deal. It used to be worse with blue screen of death (even that wasn't lethal to HW) but that currently requires bad kernel code (drivers)

One bad line of code from a novice, can cause permanent damage to the OS in C++ . Hands down, it's not a very user friendly language to learn.
Java is a safe language for some one who doesn't know how to code, to play around with, however the language can get very abstract. "Learning Online" can be frustrating as well.
To learn the basics of how to program, go with < pick one or more > Python, C#, Ruby, Lua ..... All those languages ( and a lot more I didn't list ) will teach you the basics.

I just don't recommend C++ or Java to someone who doesn't know the basics of coding.

[Fredericvo]

LOL tell me a bad line that'll blow up my windows. User code not kernel code.

[DevLiquidKnight]

One bad line of code from a novice, can cause permanent damage to the OS in C++ .

Every program runs in its own address space and one program cannot access any other programs address space, this is called paging. If you try to access an address in memory that your program cannot read it will cause a segmentation or page fault and your program will crash. No damage will occur.

[Shippou]

LOL tell me a bad line that'll blow up my windows. User code not kernel code.

It's a bit complicated, and out of scope for this topic.

[kunos]

One bad line of code from a novice, can cause permanent damage to the OS in C++ .

huh? Come again?

You can't possibly be serious.

[Inukai]

LOL tell me a bad line that'll blow up my windows. User code not kernel code.

It's a bit complicated, and out of scope for this topic.

How can a single line of code be complicated?

[M6dEEp]

...

Google dislikes people who develop for Android, and provides them with terrible tools for programming. All people I have known who have worked on Android NDK have gone mad except one, and that is just because he is a “special” person who likes debugging with sprintf() and #if 0 instead of using breakpoints and watchpoints.

It really isn’t a joke. One of my coworkers confessed yesterday that since he got tasked with Android programming it is the first time in 5 or 6 years at this company that he has considered quitting. The other one literally has some kind of addiction to debugging, and so he is happy with Android programming.
Because that is basically all you are doing when working with the NDK. Pure raw unabridged debugging, and nothing else. Not moving forward, just debugging.
...


L. Spiro

I know this may be off topic, but this post is priceless