Object Oriented Game Programming

Newbie & Debugging Questions
#1

Hey everyone,

I’ll cut right to the chase - I’ve always been an avid gamer and enjoyed my fair share of programming, but what struck me truly as what I wanted, it was a good few years back, the second I laid my eyes on Ludum Dare time lapses, Notch programming his games at some 300wpm, looking at game developers making whatever they wanted whenever they wanted just really, really fascinated me. Ever since then I’ve wanted but one thing - to be able to just develop my own games, and have so much fun doing it, to the standard that I know what I’m doing meaning that the only limitation for me would have to be my imagination. From that day I’ve always been taking in as much as possible from wherever I can, and I have gotten to the skill level where I can successfully bang out a quick window, game loop, tiles, sprites, all with the sort of ChernoProject style of code. However - if I wan’t to make anything more, I have to go searching on the internet and watching many tutorials to get any further - well, at least properly… I’ve made plenty of games however they are often incredibly inefficiently programmed with only a few classes, all jam-packed with thousands of lines of code.

So, I guess my question is, how exactly do I make ‘proper’ games, what are the mandatory rules and restrictions for programming, and what is the theory behind it all? By this I mean, what is the process of level systems, artificial intelligence, how to implement sfx, proper cut-scenes and animations - all the things that one would be expected to know before diving right in and making games?

Thanks a lot for any feedback - all is appreciated.
Sorry for the essay…
Thanks again,
Dylan.
;D

#2

Keep it simple.
Write understandable, maintainable and readable code.
Minimize dependencies.
Stay open minded and self-critical.

All unrelated to any programming paradigm.

#3

It’s also worth noting that code implementing simulation of the game world should be single-threaded.

One is often tempted to implement (movable) game entities as threads.
But this only complicates things without any positive result.

#4

Practice. Keep programming. The only way to learn how to code is by coding. Start small, and give yourself goals to work towards more complicated topics.

Instead of working on entire games, work on smaller “proof of concept” games (which might not even feel like games). For example, if you want to learn about artificial intelligence, start with something very small: The Game of Nim and Mastermind are good examples of where to start. Then work your way up to Tic-Tac-Toe, then Battleship, then checkers, etc. Start smaller than you think is interesting, and take small steps. This process is going to take a long time (think months or years, not days or weeks), so enjoy the process of learning without worrying too much about making it big or being like Notch (he programmed a ton of small games for years before releasing Minecraft).

[quote=“dylanignis,post:1,topic:57681”]
There aren’t any mandatory rules, other than what the compiler complains at you about. The most important thing you can do right now is get something working. Then get something else working. Repeat that process over and over again. Anything you write now will look like garbage to you in six months, and that’s completely normal. It means you’re improving. But it also means that you shouldn’t waste too much time worrying about getting everything right. Just get it working, then move on to the next step.

[quote=“dylanignis,post:1,topic:57681”]
This is a complicated question. There isn’t one theory behind everything. In fact, one of the things that makes programming so fun (and frustrating) is that there are usually a million ways to do any single thing. What’s right for one programmer probably won’t be right for you. You have to try stuff out and see what fits into your brain the best, then go with that. You’re going to end up writing about a million Hello World applications to test out different languages, frameworks, algorithms, approaches, etc. Get comfortable with that. The answer to “which way is better, X or Y” is to try both X and Y and see which you like best.

[quote=“dylanignis,post:1,topic:57681”]
You don’t have to know anything, as long as you start small. Think Pong instead of Mario. This might seem smaller than you think is interesting, but you aren’t going to get anywhere if you try to dive in and be at Notch’s level right away (again, this process will take months or years, not days or weeks). You learn most of this stuff by experience, and the only way to get that experience is by working on smaller projects until you’re more comfortable with larger ones.

We’re all on this exact same journey. Good luck.

#5

One thing I learned from my time on jgo is when you are faced with doing a project and you want it done in a semi timely manor, you need to pick up dependencies and ignore any downsides to using them.

If you are going to write a game engine, be able to read in XML and JSON, etc then your time is wasted and better spent on the actual game.