Getting things started

[Alex]

I've been procrastinating on starting my game for some weeks now. I have made one feeble attempt at just hacking it out, but found the code lacked direction. Then I decided to start designing it with UML first and found the design over-abstracted. Sure, after a few months of programming to the design I will have an engine I could use to fly a nasa space shuttle with, or make a 2D n-tris clone, or whatever, but by that point I know I would have become totally bored with the coding-of-engine aspect of things.

From a technical standpoint, where do successful indie programmers normally begin? Do you say, create a main loop, put in some stubs for the various screens in your game, then create objects as necessary? A (professional) programmer friend of mine repeatedly drummed it into me that this is bad coding practice, that I should design everything to be adaptable, 100% oop, that kind of thing.

I think I'm stuck in a catch 22 - The design phase plus creating an engine based on that design (no game-specific code until after the engine is solid) seems like the sensible, future-safe way to do it, but it kills the fun. The hacky, quick-results approach seems to satisfy my desire to see something I can play as I go along, but I know that once I start on the next game, I will probably have to re-code most of the game since everything is so specific to each project.

I don't even know why I'm posting this other than to vent my own frustration at my inability to get things moving, but if anyone here understands where I'm coming from but managed to move beyond it, your advice would be very welcome.

Thanks

[svero]

Here's what I'd do..

1) Download the popcap framework and have a look at how they do it
2) Download blitzbasic and see how that works
3) Take a look at PTK and Torque other game engine docs

That will give you a general idea of how other engines are organized. You may even want to use one of them for your first game. In fact I recommend it. There's little reason to reinvent the wheel mucking around with UML and engine designs these days. There's too much inexpensive or free stuff available.

[mahlzeit]

The hacky, quick-results approach seems to satisfy my desire to see something I can play as I go along . . .

Do that, then. Real Programmers Don't Design. :)

. . . but I know that once I start on the next game, I will probably have to re-code most of the game since everything is so specific to each project.

You will have to do that either way. It is impossible to build a reusable framework without actually using it. Hack something together for game #1, re-use the bits you can for game #2, repeat for game #3 and #4, and slowly a framework will automatically emerge. Don't try to build everything up front unless you're building a space craft or a nuclear powerplant.

[aiosup]

Do that, then. Real Programmers Don't Design. :)

I wonder if I'll ever see a game in fortran... :P

Hack something together for game #1, re-use the bits you can for game #2, repeat for game #3 and #4, and slowly a framework will automatically emerge. Don't try to build everything up front unless you're building a space craft or a nuclear powerplant.

I guess he could start by hacking some working code for game #1, reuse that code to rewrite parts of game #1 that he thinks could go into games #2..#4, test the rewrites by making game #1 work again, then... well, it's called refactoring: change to better variants once you have the time/will to do it (if it's a pro thing than the first should prevail), but test it in your orig code as much as possible, for you will have some base of comparison in terms of performance/other results...

[MadSage]

For me, coding the engine/framework tends to be the most interesting part, but also the most frustrating part. The game code is easier, and for that reason I often get bored working on it.

I'm still working on my first indie game in my spare time, but it is looking fairly close to completion now, and I have a pretty good engine to speed up development of future games.

Everything was written by me from scratch, with the exception of the sound library. To start with, I had a very basic overview of the engine in mind. Creating a window and the message pump was the obvious starting point. Next came the Direct3D initialization (which had a fixed mode to begin with). I then added sprites and objects to the engine, and began work on the game code. I built the whole thing up as I went along, adding stuff to the engine as I needed it - basically anything I could reuse in future games.

I know a lot of people would disagree with that method, but it works for me, since I get bored so quickly. I'm doing all my own graphics too, which is something I can do when I don't feel like coding. Sure, this method has caused some problems, but everything has gone fairly smoothly and has remained almost bug free so far. There are a couple of sections that need redesigning because they got out of hand, but since I write modular code in C++, its not too much trouble. I think that's the important thing to remember when taking this approach - always write modular code. Then it's easier to add and change bits later.

[Martoon]

Don't try to write an all-encompassing "engine." Too many hobbyist game programmers get bogged down perfecting their engine, and never actually make any kind of game with it. And even if they did get their engine more or less complete, it's going to be an engine for specific types of games - you can't really make a truly general-purpose engine.

Instead, start on a game concept, and start making small, modular pieces with the functionality you need for that game, where each module does some small, specific thing (like initializing Direct3D, or rendering text, or handling input, etc.) That way, even if you quit on one game project, some (or most) of the modules will be usable in your next project, even if it's a different type of game.

I'd also second what svero said, and recommend starting with an existing engine or framework.

[Gnatinator]

Im going to third what svero said and recommend you take a look at some of the solid, existing stuff out there.

Even if you do decide to code everything from scratch, you are going to practically double development time (especially if this is your first game). Take me for example, ive been developing my game for almost 6 months so far (albeit I am also doing the artwork aswell). Started from nothing. It took about two months to get the core engine together, and even now im still implementing stuff as I finish the game.

Bottom line is that you will probably be developing the engine just as much as the actual game. And if you personally do not want to develop an engine, you really should just use an existing solution.

Myself, I think I will be switching to torque after I am done my current game.

[Alex]

Yep torque looks like the way to go, now if only I had a credit card! Thanks for the replys, despite the fact that I'd like to code the whole thing from ground up so its all "mine", it wouldn't be as if anything I did would be particularly groundbreaking, and potential employers would probably think me an idiot for re-inventing the wheel :)

Does getting the torque license require any previous licenses? Their licensing system is kinda confusing, theres no clear indication as to what previous licenses you must hold to get something. How about the torque 2D license - Can I get that for $100 too, without getting the TGE?

Thanks heaps.

Oh one last thing, can I program using C++ and torque in Dev-CPP? Will I need any specialised tools?

[Teeth]

Try torque first. It may not be what you're expecting it to be. Most of your game will be done in TorqueScript, for example, and ripping bits out of the game engine in C++ is nigh-on impossible. Don't buy Torque and then realise you don't want it having spent some time using it. Download the demo first.

[Alex]

I've looked at the demos they're pretty cool, I was wondering what happens if I pay for an early adopter release... Do I automatically get the final release when that comes out? I haven't found any info on GG about that.

Anyway I've all but abandoned writing my own game engine. Sure, I *could* do it (yeh, thats what they all say), but I don't *need* to.

[MrPhil]

I'd recommend a start with T2D or if you really want to do TGE then learn it using the book 3D Game Programming All in One

The book comes with a CD that has a trial version of TGE you can use with the tutorials in the book.

[Alex]

Thanks I'll add that book to my to-buy list :)

[Alex]

Okay here goes... $100 smackaroos, I hope this thing works, I'm buying an indie license for torque 2D.

Are there any other books that you guys can reccomend as far as game design / programming goes? I'm not sure if I can trust Amazon's "People who bought this book also bought..." list.

Thanks for the help, I'm sure I can procrastinate and ruminate over which option would be best, but stuff it, I'm getting torque 2D and I'm gonna use it. I trust youse guys!

[Sharpfish]

One of the best books I have seen all-round is "Core techniques and algorithms in games programming" but It may not be much use for Tourque-esq stuff (it basically covers a lot more low level stuff that Tourqe already has done for you). If you know programming already then a general games design text may be more helpful. If you are using Tourque then the book already mentioned is probably good because it USES it and will accelerate your learning of that if not "games programming" per se.

Don't forget to use the internet (flipcode,gamedev,gamasutra etc) for lots of free sources of info.

[James C. Smith]

I would just start messing around with anything and plan to throw it away. If you have never written a PC game before using modern graphics and OSes, you are not going to be able to start with a plan for a specific game and finish with a shippable game. You have to try a few things first to learn a long the way. Just try to use an existing framework to make a stupidly simple game that you don’t plan to ship. Or get the source to a working game and modify a few things to get a feel for how things work. After you have your bearings you can start over with YOUR game idea.

[Alex]

Extremely low level stuff like graphics routines and buffers for sound and all that stuff - I have a working knowledge of but would rather not go there... The most recent stuff I've made a playable game in would have to be Ogre3D, but I had to implement my own event lists and so on, it worked quite well but once I'd made a basic framework I realised just how much freakin work it would take to get it to a stage where a fully functional game could be built with it. I've got torque2d now and compared to what I've been doing, torquescript looks quite straightforward (refreshingly so). Now I can create objects, assign controls to them, collision detection, the works, without having to wonder whether the actionlistener or whatever is registered for that particular subclass of world_object. I'm going to have a lot of fun with this toy!

Of course my first game will probably be breakout. Sorry, but thats the way it goes.

--edit : Yes, I hated every moment of programming the game engine. I just want to make games! Now I am a torque fanboy, can I buy a tee-shirt??? Just kidding.

[aiosup]

I would just start messing around with anything and plan to throw it away. If you have never written a PC game before using modern graphics and OSes, you are not going to be able to start with a plan for a specific game and finish with a shippable game. You have to try a few things first to learn a long the way. Just try to use an existing framework to make a stupidly simple game that you don’t plan to ship. Or get the source to a working game and modify a few things to get a feel for how things work. After you have your bearings you can start over with YOUR game idea.

From another point of view, making something just to learn typically does not force you to think about the right solutions, as you tend to do things just to see them working.

I would advise you to make a simple portfolio game -- you are learning, but you need to make it top-class, as if you'd sell it. The major difference between what you do with a portfolio game and a shippable game is that for the former you can go for a total remake of another game, or for a very simple idea, while for the latter you would have to come up with something... well, we don't know what that means, but sellable anyway :) btw, people in the rendering area typically follow this way, so why wouldn't a programmer?

[Alex]

Thanks again for the suggestions, I've taken them all on board, I reckon I'll be able to handle things from here on, but if I have any more questions or things to show off or just want to be an opinionated prick, I'll be back :)

Btw, even if you plan on writing your own engine, Torque is worth getting just to see how its done.