Getting things started

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.

 

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

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.

 

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

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...

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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?