next »

[Topogram]

Hi,

I'm an experienced programmer (medical imaging, simulation software, etc) but have never made a game. I have a game idea in my head that I've wanted to make for years and I've finally decided to use my free time to work on it. The game is a Space Empires IV / Galactic Civ type game (i.e: turn-based 4X).

I'm not interested in which game engine to use - that doesn't matter. What I need help with is physically where to start? The game is loosely formed in my head but as a complex project I'm not sure where to begin.

Should I start with the title screen? Should I sketch out every screen on pencil and paper first? Shall I do the artwork? Should I sit and write the interesting logic to randomise the location of star systems in the galaxy?

I'm looking for advice from experienced game developers as to where a sensible starting place might be.

[ThemsAllTook]

I usually like to start with a prototype of the most interesting or unique part of the game. Whatever makes it stand out as an idea, or the thing you're most excited about. Once you have an interactive version of that core idea, the rest of the game can be built around it. If the core turns out not to work like it does in your mind, then you haven't wasted a bunch of time up front building parts of the game that don't have to do with it. If it does work out, it'll tend to end up as the most polished part of the game, since it's had the most iteration time on it.

[Deckhead]

Hi,

I'm an experienced programmer (medical imaging, simulation software, etc) but have never made a game. I have a game idea in my head that I've wanted to make for years and I've finally decided to use my free time to work on it. The game is a Space Empires IV / Galactic Civ type game (i.e: turn-based 4X).

I'm not interested in which game engine to use - that doesn't matter. What I need help with is physically where to start? The game is loosely formed in my head but as a complex project I'm not sure where to begin.

Should I start with the title screen? Should I sketch out every screen on pencil and paper first? Shall I do the artwork? Should I sit and write the interesting logic to randomise the location of star systems in the galaxy?

I'm looking for advice from experienced game developers as to where a sensible starting place might be.

Making a 4X is a big undertaking. You say you're an experienced programmer, but considering you've never made a game before, the scope of your projects ideas might surprise you once you get started. With that in mind I'd suggest you plan ahead, also write a complete Game Design Document, and finally get yourself comfortable with the time needed to get it done.

In my opinion, that's where you start. Once you've got a Game Design Document, it won't really matter much where you start the programming, because it will quickly come together. However, it's a good idea to try for a "vertical slice"; that'll help with motivation to also acts as a prototype to see if what you're doing is fun or not (4X is always fun though, right?).

Good luck. Like I said, a 4X is a big undertaking. I really can't stress enough the need to plan a game of that size out first.

[Topogram]

Thanks for the tips - very sensible. The linked posts and articles are very insightful. I have an outline of a game design document but I think I need to spend some time fleshing it out.

Parallel to writing the document, I've decided to take ThemsAllTook tip too and work on the star map component of the game as it's a fun logical challenge.

[-Ross]

Step 1: Read this: https://makegames.tumblr.com/post/1136623767/finishing-a-game

For 2: don't make any graphics. Just use squares and circles and stuff until you have something working. Oh, you can add bits and pieces if you like, or mock up the overall art direction, but trying to do details and final art in the early stages is just procrastination and a waste of time. (Unless you're working with a dedicated artist who would have nothing to do otherwise?)

3. Don't spend too much time planning, building underlying systems, writing game design documents...Sure, planning is fun! You get to think about how awesome your game will be without doing any of the hard work! Yes, you need a general plan, but don't confuse planning with actually making games. You can easily spend days, weeks, months...years planning, and never actually accomplish anything (but you will have fun).

Basically, you can't know what your needs will be or what problems you will run into until you actually make the thing. Overly-specific plans, or underlying code "systems" will generally need to be thrown out or extensively modified a few times before they match your needs in reality.

4. Don't start with your dream project. Seriously, even if you think "I just want to do a very simplified 4x!" No. You have no experience. You will spend a year on it and still not have a playable game. You'll be exhausted, frustrated, you'll hate the project, and your dream will be dead.


Enough about what NOT to do...Where to start?

5. Start with something small that sounds fun. If your dream project is a serious goal, you will get it done sooner and more easily by putting it aside and doing at least 1 tiny project first (but preferably 2 or more). You don't have to do Pong or something that would be boring, maybe take a tiny (tiny!) piece of your 4X idea and make a little game out of it. Maybe something like Qonk. Something like Ocean Tribes is already too big.

6. Try to get something that works as quickly as possible. In the first day you should have something that moves around on screen from player input. After a week of work you should have some kind of meaningful interaction (maybe you have one, invincible unit that can move around and beat up randomly-spawned enemy units). Even if it's not exactly what you planned to make, it's easier to fix & change something that exists than to struggle to make it just right on the first try.

7. Do it quick and dirty, then fix it.

[-Ross]

Regarding the time frame: For a "serious" project, like what you are considering, take a look at this Cogmind blog post, he's the only one I know of who really has good stats.

As an example of a very small game, the third link in my signature is one that I made. It took me pretty close to 220 hours.

- That was after ~4 years of fiddling around with game engines and about 30 little prototypes of games and several other game-related projects.
- I was very comfortable with the engine and language I was using, I had a workflow, a decent object editor, and some tested underlying libraries ready.
- I was mostly ripping off another game, so for the most part I knew exactly what to do. I didn't spend much time working out design decisions.
- The game was basically complete at around 130 hours and I started getting outside playtesters. The next ~70 hours was improving and reworking things, tweaking balance, and adding content and convenience features. The last ~20 hours was after release, fixing some little bugs and making small improvements in response to player feedback.

[Deckhead]

3. Don't spend too much time planning, building underlying systems, writing game design documents...Sure, planning is fun! You get to think about how awesome your game will be without doing any of the hard work! Yes, you need a general plan, but don't confuse planning with actually making games. You can easily spend days, weeks, months...years planning, and never actually accomplish anything (but you will have fun).

Basically, you can't know what your needs will be or what problems you will run into until you actually make the thing. Overly-specific plans, or underlying code "systems" will generally need to be thrown out or extensively modified a few times before they match your needs in reality.

This doesn't make sense. The reason you "can't" know what your game needs is because you didn't take the time to plan it out. The person is talking about a 4X game, not a simple game where you dodge bullets or shoot asteroids.

Planning and making a game design document is "actually making a game" and it's hard work. Thee reason you think otherwise is because you haven't put in the required work to see it any other way. None of your systems will be thrown out or extensively revised if you plan it out. If this hasn't worked for you in thee past it's likely that you don't know how to plan things out.

You'll be doomed to simple games if you continue to see planning and up-front design as a waste of time. Anyone who wants to make a complex 4X can, if they plan it out and stick to their plan.

[TonyLi]

When you're just getting started in game development, even if you're an experienced programmer from another field, it's not worthwhile to write a big game design document yet. There's just too much game-specific learning to do first. Make small "island" prototypes of features that you're not 100% sure how to implement yet and features that are interesting or unique about your idea. Even experienced game programmers do this before writing or contributing to a GDD, especially if they're crossing into a genre they haven't worked in before. This will give you the background to know what you're doing when/if you write a GDD. And you never know which of those island prototypes can end up being a small game by itself. Bringing a tiny game all the way to release entails a whole other set of learning opportunities.

[Deckhead]

When you're just getting started in game development, even if you're an experienced programmer from another field, it's not worthwhile to write a big game design document yet. There's just too much game-specific learning to do first. Make small "island" prototypes of features that you're not 100% sure how to implement yet and features that are interesting or unique about your idea. Even experienced game programmers do this before writing or contributing to a GDD, especially if they're crossing into a genre they haven't worked in before. This will give you the background to know what you're doing when/if you write a GDD. And you never know which of those island prototypes can end up being a small game by itself. Bringing a tiny game all the way to release entails a whole other set of learning opportunities.

This is, in general, good advice, but the OP has said he wants to make his dream 4X game. This can be accomplished. From memory, GalCiv was made by Stardock with zero experience making games and they ended up with what is the quintessential example of 4X.

If OP wants to, he can make this game without making prior small games and prototypes. He just needs to do it incrementally. And the best way to do that, is to have a solid list of features, know exactly how resource management and the core gameloop of his 4X is going to work, the stats he needs to track etc. If it's "easy" to think up all this stuff then once it's thought up it's also "easy" to implement in code.

The reason would-be game developers fail to make a large project as their first game, in my opinion, is primarily lack of planning and loss of motivation when they don't get quick results. If OP can recognise this and accept it, he can manage it and accomplish his goals. If you only need to worry about implementing ideas already thought-through, implementation is easy. Every software developer knows this (in my subjective opinion at least).

However, making small games and prototypes is the best way to get started; if you can't handle the amount of planning, forethought, and motivation needed to tackle a larger project straight out of the gate. Which is probably the majority of people. Not passing judgement, I just think it's important that people learn to accept what they can and can't do and how they need to get there.

[Demi Dawnfall]

I think the difficulty with giving any definitive advice is that there's so many correct ways to go about the process whose results will hinge entirely on the type of person you are. In the spirit of giving advice that is most universally helpful, I personally advise 'failing faster' but that 'as long as you're doing something toward the goal, you'll learn and make better choices.' The correct path comes from knowing your own style of development and until you take some steps into development, you won't really know what's best for you.

If you learn that you can plan and dream forever without ever getting anything done, it might be best to hit the ground running and collect some information on your stats, aiming toward smaller goals, as -Ross or TonyLi has noted. If you're someone who tends toward just struggling along, thinking only a step ahead, it might be best to take Deckhead's advice and get a solid plan in order.

There's lots of other little tidbits one could take from this, especially the part about understanding and polishing your core gameplay loop. I think we all can agree that having that solid foundation is always the way to go. But my advice boils down to... if you're doing something to start out, you're doing the right thing. You can't make something if you're not making it. If you don't feel you're making progress toward your goal, changing tactics to see a different angle might help.

[-Ross]

Uh, wow, that got personal.

@Deckhead So you think it's possible to plan out something (that you've never done before) in enough detail that you don't have to revise or change anything? You can plan out every edge case? Every weird scenario that never should happen, but some playtester is bound to stumble upon...you can plan for that? And if you plan to that degree, are you not just writing the code itself at that point? What about game balance and "fun"? You can plan that to be perfect before you even start?

Just curious, have you made a large game yourself?

[Micah.WhiteBoxGaming]

The size of a game is irrelevant. Think of building a software application for a client or business. You start with an idea. Then you add on to it. You build extensions etc. What you need to do is literally plan it out as everyone has said. How to plan is simple. Break your game up into divisions or parts. I will plan a basic game for example:

•   Type
 o    Side scroller
•   Genera
 o    Shooter
•   Audience
 o    Teen and Up

Now that I have some basic information about my project I can make a few more decisions about my project. Because it’s a side scroller I can determine I want it to be 2d. Because it’s a genera is shooter, I can start planning some basic weapons. Finally, because I’m targeting older children, I can have freedom of speech (curse words, gore, etc)

•   GFX
 o    2D
•   Weapons
 o    Machine gun
•   Speech
 o    Crude

Now I can start expanding this out more.

•   GFX
 o    Side Scroller
       2D
•   CPU reqs
 o    P3 or higher
•   Memory reqs
 o    4 Gig or higher
•   Weapons
 o    Machine Gun
 o    Rocket Launcher
 o    Grenade
 o    Knife
•   Speech
 o    Crude
•   Humor
 o    Crude

As you can see the game concept is start to come together based on my basic design. So far I have decided on a GFX design, Created a basic weapon list, set my target audience and started to define/design my characters based on speech. Because I picked crude. I know my characters will need to be crude. I could go further and start defining my characters physical appearance, speeches etc. BTW for those whom caught on, I was designing Duke Nukem roughly. Another option if your completely newb to game development would be join someone else’s team and learn the basics. 90% of projects fail in game development. Most of the time its because lack of planning.