Game Development - Coding's not the problem...

SO you are looking for the "thought tools" that will allow you to interconnect your programming with good game ideas yes?

From what i've heard, practice practice practice, trial and error and studying many existing games to see how they have achieved their designs as the main way to achieve your goals. Also studying psychology and marketing would be of great use to you.

IMHO modding is the place to start. Then as you start wanting to mod things that really require code rewrites, you start to become a game designer.

Thank y'all. After crawling the web at work today, practice seems to be the only consistent answer. I did find some book recommendations at stackoverflow, as well as the link to Code Kata.

I should mod, that is a true statement. Maybe I'll do something with Civ4 or FE.

Thanks again for the feedback!

Oh please join the FE modding community! We are quite knowledgeable and helpful. We needs as many minds as possible. I got started in modding with GalCiv2 awhile back and have been doing Stardock mods ever since. FE is a great place to learn. The only drawback is that we can't do any sort of real modding until the game is released. But there is plenty of XML to play with.

What exactly are you looking for? If you're looking for books on game design, I can't recommend any. All of the game/software design books that I've read are oriented towards team management, which isn't relevant for sole developers. (And most "business" literature is trash anyways.) If you're looking for books on game architecture, there are a number of good ones, but the best are all genre- or domain-specific (i.e. books on shooters, real-time-strategy, etc. or books on artificial intelligence, physics, etc.). As mentioned above, it's also a good idea to look at existing architectures.

Also, Civ4 is by far the more interesting game if you're looking to get involved in game programming since the source code is available. (FE mods are limited to changes in data.)

The key is proper planning. You want to write up the basic goals for whatever you're working on, then make a very detailed list of what is required to get there. It's VERY important to know what your target is, otherwise you'll just be flailing around writing code or making changes without knowing if you're getting closer to your goal or further away. It seems stupidly obvious that you want to have some idea of what you're making, and how you want each feature to be fun, but when you're deep within development it's incredibly easy to lose sight of the forest for the trees.

- Jon

P.S. I have a new website up which talks about design, particularly in the context of strategy games. I'll be covering various topics, many of which should be useful for aspiring designers.

^ ^ ^
He's pretty much the one to listen to about this...

Quoting Jon Shafer,

reply 6

The key is proper planning. You want to write up the basic goals for whatever you're working on, then make a very detailed list of what is required to get there. It's VERY important to know what your target is, otherwise you'll just be flailing around writing code or making changes without knowing if you're getting closer to your goal or further away. It seems stupidly obvious that you want to have some idea of what you're making, and how you want each feature to be fun, but when you're deep within development it's incredibly easy to lose sight of the forest for the trees.

- Jon

P.S. I have a new website up which talks about design, particularly in the context of strategy games. I'll be covering various topics, many of which should be useful for aspiring designers.

Well now, that was interesting. It's great to see some of the thoughts behind the scenes in relation to game design. Will definitely keep reading your site with cool posts like that.

Seems like you fit in very well at Stardock, who have always been so open with us end-users. Glad you're aboard!

I'm a web developer, not a game developer, but I guess many of the principles would be the same.

I usually start by creating wireframes of the various screens. If it is for internal use these are very rudimentary but if they are for approvals they are a little more polished. To generate these I use a Wacom tablet and start by sketching in Painter (I have custom brushes set up so the sketches look like markers - makes the final output appear more conceptual).

After concept approval of the wireframes the various user interface items are built in Illustrator and/or Photoshop. These are built in the context of final screen mock-ups (once again for approval) but are built so they can be easily split out and individually generated (grouping and layer management is important to be able to organise the outputs later).

If the requirements are tricky and are going to require a lot of development then I list each required component or focus area in FreeMind. Typically for web development these will list pages, database, permissions, classes etc. FreeMind is open source mind management software and is excellent for organising hierarchical information. Stemming from each component I then list the requirements to deliver it such as the functions I think will be required etc. I don't try to get this part 100% right at the start, just record what I think will be involved. Then when I'm focussing on a particular area I then start listing out logic flows, todo items and notes so the mind-map gets increasingly complicated. I colour-code each entry, red for items yet to be done, orange for items that I think are done but need testing, purple for items I'm not going to worry about yet but may look at in the future, green for completed items, cyan for information items, and grey for comments or notes. The beauty of mind mapping is that you can collapse the items you aren't working on so it give a great to-do list of items that need to be built. This is very much a working document that is constantly updated and added to as the project proceeds.

Version control such as Git is a good idea particularly if you are going to have different parties working on different areas of the code.

If the project requires collaboration with other parties over distance then it is a good idea to formalise file management and coding standards with everyone involved. File sharing can be done through DropBox, web collaboration software, or sites like github. DropBox is damned handy though for basic collaboration.

The structures from the mindmap can then also be used to develop timelines and milestones.

Wow, you do all that during the planning phase? My wireframes basically exist on Dry Erase boards in the neighboring conference room. Then we get approvals and take cell phone pictures of the Dry Erase boards.

Oops. I didn't read the OP properly.

Wireframes for planning phase. Up to the initial mind-map for design phase. In-depth mind-mapping etc for production phase.

Prefer digital wireframes because they are really quick to generate and many components can be reused in different versions.

You need to code mostly to gain that skill

Start writing your game in a simple Game class with Initialize and the typical Update/Draw loop.

Then, as you add more things, it will become impossible to handle. Move to a Screens design, where the main game just run different Screens, and those screens handle different parts of the game (the Menu, the Game, the End,...). Little by little, you will organize code in those screens, some managers (InputManager, SoundManager,...) and will separate everything.

For designing game objects, you may want to star with an object oriented approach, but once you are comfortable, will probably want to move to a component-oriented approach better.

My 2 cents

My suggestion is to research and experience every video game that is similar to the game you want to make. Then go out and play some games that are not related. You want to play good games, bad games, popular games, underdog games... you want to be an expert on games, gameplay, game mechanics.

And the key is... pay attention to mechanics, to design. When you get frusterated... try to figure out why, and how to go about fixing it. When you are having fun... figure out why.

Those are basic tips.

I got my start making maps for Starcraft... and I carried over to Warcraft 3. Thats where I learned about design and coding. Looking at other people's work is a great help for learning the ropes.

As for how I go about it now... I spend lots of time just planning everything out in advance. I think about my goals, how I want the player to feel, what are the game mechanics I want to be prominent.

For example, in designing a Tower Defence game: I will first decide what type of TD I want to do. How many towers should there be, how are the enemies organized? Do i want to focus on strategy... or is it a casual grind? Am I going to copy a popular format and add enhancements... or will I try something that hasn't been done before?

After I lay out the ground work... I start thinking about storyline if applicable, do some world building. I also jump in and start writing down features, and even numbers. Making a spreadsheet and filling it weapons, special abilities, tech trees, etc are all helpful in figuring out if there are holes in the design. If i get to a mental block working on one aspect, I change to another.

I realize that my methods may be unusual... but I maybe something in that explanation will be useful to you

Also, coding simple systems is pretty easy... but coding complex mechanisms is not. Look at the new Sim City game... even if you have a perfect design document its not trivial to create a highly interactive system with interconnected parts.

It helps to document your work as you go. Not just comments in code, but a list of any resources you've changed in each update, the basic intent of what you did, whether or not you were successful and the results of any tests you performed. It may sound boring and there is an overhead associated with doing this, but it can save you some time in the long run.

Oh yeah and if you don't already have a second monitor hooked up, it would come in really handy to do what I just said, as it'll save you having to Alt-Tab between your code and whatever you use to take notes.

The three Sid Meyer rules of game design for player psychology: egomania, paranoia and delusion.

Wouldn't be funny if it wasn't true.

Planning is all. Planning is everything. I've just come off of a weekend of coding to what I thought had been an adequately detailed design, only to find out that significant questions had gone unanswered during requirements gathering. At least I can still use some of my utility classes.

Planning is all. Planning is all. Planning is all.

It's like some sort of gom jabar test or something

Quoting Napean,

reply 16

It's like some sort of gom jabar test or something

I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

Quoting Rosco_P,

reply 17

Quoting Napean,
reply 16
It's like some sort of gom jabar test or something

I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

I updated that for you.

I must not code outside the plan. Coding outside the plan is the mind-killer. Coding outside the plan is the little-death that brings project cancellation. I will face my tendency to code outside the plan. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. When the impulse to code outside the plan has gone there will be nothing. Only I will remain.

Quoting Rosco_P,

reply 17

Quoting Napean, reply 16It's like some sort of gom jabar test or something

I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

I like this person.

Quoting Gammit10,

reply 19

I like this person.

Didn't realize a Dune love fest was underway over here

Many men have tried to create intelligible, coherent code...so many, but none has succeeded.

They tried and failed, all of them?

Oh, no. They tried and died.

@ jon Shafer

Thank you for your insight. Its not necessarily what you do, it's how you do it. The process oriented approach speaks of your experience quite soundly.

I'm checking out your website at the moment, and I like your bit on the game unity of command.

From what I observed, you enjoy the game because it executes the core elements of actual warfare into simple elements that when combined create well executed, fun game design.

Things like being able to tell one opponent from the other is critical in warfare, and any game that doesn't allow a general to easily determine what unit is what fails fundamentally.

Currently corvettes are quite good at interrupting supply lines in sins, one of their most useful combat roles. Sins allows for more fluid supply lines then unity of command, and every competent player must understand the subtleties of sins supply (one of the major strengths of sins).

I would enjoy seeing this supply experience expanded in sins 2, possibly by adding more complex gravity well setups (dual planetary bodies, asteroid grav well interference, binary stars, and anything that changes fleet supply speeds to increase the "space terrain" aspect of the game).

This would increase the time elements to supply reaching its destination and therefore add significantly to the "feel" of this aspect of the game.

The Forums Are Now Closed!

The content will remain as a historical reference, thank you.

Game Development - Coding's not the problem...

Looking for good design resources