Getting more serious about game DESIGN

Hello,

I have started and stopped numerous projects lately, and I have traced the problem to (I think) my lack of game-designing skills. Meaning, I can code up an engine for a game (maps, entities, etc.), but my projects usually stop right there. I cannot seem to push my projects past a bunch of entities, and a map. What I think the issue is, is that I am more focused on game programming than design.

This is not to say that I jump into projects with no idea what I will be making; I try to make a basic document on how the game will work, and will try to follow that document throughout development.

Let me give an example. I tried to make a game for LD29, but here is how it played out:


-[b]Made game design document[/b] The game was going to be about digging and looting different dungeons, labs, etc. for oxygen tanks, weaponry, and health packs. Inside said dungeons, numerous enemies could be found.

-Made Engine
I made a tile-based world with lighting, and randomly placed structures.

-Added in player things
The player sprites were made, and he can dig around everywhere. Great!

-Added in enemy things
I added in enemies that patrolled the dungeons. This is where it began to fall apart. I realized that 90% of the gameplay was digging through vast amounts of land in a probably fruitless effort to find dungeons. Project quit :(.


Any ideas? I basically have yet to make a real game. I have been trying to do this as a hobby for about 3-4 years and only have a Game Library to show for it. No actual games yet, since I can’t really design a game :-.

Anyone else struggled with this?

-wes, the very confused new JGO Wizard :clue:

I had never released a game before, and I’ve been working on one for about two months now, and am about to release it to GooglePlay (hopefully this week).

Honestly, the only thing I did different that made it succeed (over the hordes of unfinished projects) was accountability to someone other than myself (Im making it with JumpButtonStudios.com). I didnt even follow a design pattern when coding it (bad mistake), I just did what I had to do to show some progress. Because when your working for/with others, people know if your doing your job and if your slacking off, so you do your job.

Most people will probably say somthing along the lines of, “If you cant finish a project alone, you certainly wont finish one with a group”. But for me, working with a group was far more rewarding and punishing, and was the only thing that really got me to finish. Rewarding for the same reasons JGO is rewarding, you get to share your progress with others. Punishing because you’ll be held responisble for the work you do by others.

I guess it depends on what type of game. If you want something with a story focus, nice setting or what have you then the process is kinda different than if you wanna make flappy bird.

a game design document you only make if your game is “vast” / has a lot of things going on story wise. This is not a rule but for example with Doom they didnt bother. Because its a game thats all about the mechanics.
I started my GDD years ago and I guess the thing about a game like that is that you have all the scenes in your head, characters, events, dialogue and you wanna see it come to life
OR you want to see a unique fun game mechanic come to life - in that case it an iterative programming testing process

what do you actually wanna do ?

I suggest watching some Extra Credits; It’s helped me figure out what not to do with my future game, at least.

Beyond that, I’m in the same boat as you, but my game engine/library/whatever isn’t even that usable as of late.

Some of us are just programmers, and that is a sad fact. Sure, you can get into complex game design, but you should really just do what you think is more fun.

You can go down either one of the two paths.

If doing engines is the thing you want to do, aspire to be somebody like John Carmack.
If making games with strong design is the thing you want to do, aspire to be somebody like Daisuke ‘Pixel’ Amaya, Phil Fish, or any other popular indie developer out there.[sub][sub][sub][sub]Okay, well not Phil Fish. I don’t want you to become insane and cancel your future title for no logical reason![/sub][/sub][/sub][/sub]

However, it’s still a great idea to jump out of your comfort zone and try things you’ve never done before.

Yes, there are two paths you can go by, but in the long run
There’s still time to change the road you’re on.

This is what I recommended to Wes earlier in a Skype conversation. This is a great channel, in my opinion. I’ve been watching their content for years! However they cover some of the bigger issues, issues that go on a much broader scale in the game industry, problems that people like Me, Wes and you are highly likely to never run into.

Game design is something odd. If you think programming engines is fun, continue doing that. If you want to branch out and learn some design, do that instead. If you want to want to completely forget complex engine work and put 90% of your focus on game design, go right ahead and do that. Do what you think is right.

If engine work is what you truly love, if engine work is your forté, you could do what Puppy Games does. They are very well known for taking basic game design concepts and turning them into modern, fun, and graphically advanced games that are actually pretty damn successful Java-wise.

That’s just my two cents on the topic. I hope to learn just as much from this thread as Wes does, because this is an issue that highly effects me as well. I’m pretty sure we all run into this problem, and the number of threads similar to this one shows it very well.

Hope this helped. :wink:
Sorry if this post didn’t make much sense, I’m tired as I’m writing this.

  • Jev

The only way I would know on how to get over the barrier of game engine and games is this. Make actual games. Don’t make frameworks or game engines. Make something playable, no matter how simple.

I recently had to make a Galaga clone. I had pretty awesome time making it, and it turned out pretty good. I would suggest you try the same :smiley:

Here is ‘real’ Galaga.

S_lE_L0UtkQ

EDIT-
Try setting a deadline for yourself. Mine was 7 days, but I finished it in 4 or 5.

Just to agree with trollwarrior, you can’t even really build a game engine if it is not being used in several real and complete games. Otherwise, how do you know your solution is solving anything?

Agree completely with this.

I’m one of those that prefers making an engine as opposed to aspiring to an actual game, that said I try and force myself to aim for an end-product when developing this engine, otherwise the temptation is to continually tinker rather than actually delivering anything.

Just dug out my initial ‘roadmap’ listing the engine features for each ‘release’:

  1. proverbial textured spinning cube
  • abstract application (render/update loop)
  • point, vector, matrix
  • mesh builder (specialised for cube atm)
  • viewport, projection, scene classes
  • LWJGL rendering implementation
  • image loader
  • texture class
  • animator, rotation transform
  1. galaxy simulation
  • vertex/fragment shader (fixed parameters for now)
  • VBOs / VAOs
  • upgraded mesh builder
  • height map loader
  • camera class, orbit camera controller
  1. terrain
  • height map loader
  • terrain builder
  • phone lighting
  • indexed mesh builder
  • normals computation
  • device management
  • event handling, basic movement events
  • improved camera controller

etc etc

Obviously I only have myself to please so I still procrastinate :wink: but at least I generally have some goal in mind and a set of tasks to achieve.

  • stride

well, he did not say he does not know how to finish a game, only he did not find it fun enought to be worth finishing…

Maybe try designing some pen, paper and dice games (i.e. no programming at all) to get more of a sense of game design?

Here are some thoughts about ludum dare. Disclaimer: I might not be the most experienced game programmer or designer, but I have participated in multiple LDs and have learned quite a lot from it. So this are mostly thoughts for things that work for me or improved my workflow. though most of this thoughts are about ludum dare, some of them also strongly influenced how I work on my game projects now. sorry for the wall of text :wink:

I think for ludum dare it is important to stay focused on the goal. For this you have to know what you will be doing, not in terms of tech but from a “game design” perspective. We always started our ludum dare jam by eating breakfast and brainstorming ideas. We don’t talk about how we will be implementing them, we just discuss how the ideas might play out in terms of game mechanics, artstyle etc. the ideas can be very simple or even silly. you can still refine your ideas. But be realistic when you chose your target. I might like the idea of implementing a 2d clone of portal, but I know that I won’t be able to pull something like this off during a ludum dare…

Don’t take the first idea that comes to your mind (if it’s your only idea, you might be stuck, so go for it). Though it might be a nice idea, you can bet that someone else has had the same idea. That does not have to be a bad thing, but it can be a nice thing to be unique. Last ludum dare (“You only get one”), my first idea was, that the player has a bow or crossbow but only one arrow. We then went on and found another idea, but it was funny to see, that there were multiple entries from other people, that did exactly this.

If you don’t have any idea for the theme, story, graphics style etc., but still want to participate, pick a game mechanic or a simple game (tic tac toe, flappy birds, tetris, poker, whatever, one of our entries is losely based on a popular board game) and try to execute that as nice as possible. You can’t force creativity but when you start working your brain starts working and more ideas can come up. You might find a cool twist to the game mechanic or find out how to link the theme to your game. Maybe it just ends up as an unoriginal clone, but it might not :wink:

Split up your work in multiple steps. For my game, my plan was roughly like this: “Setup Box2d and factory for creating bodies” => “Setup controls for player body” => “Add scene/graphics” => “Add lighting” => “Add food” => “Add enemies” => “Add Music and SFX”. I started with the first step and when completed went on to the next. Sometimes you have to backtrack to clean things up, but really, you want to go forward.

It is about the game, not about the tech. While it can be fun or interesting to dabble around with tech, don’t let it go overboard. A nice architecture without a running game is not so nice in the end :wink:

Reevaluate your ideas and tasks during your project. Is it too hard to implement? Will it be fun? Are there any problems? Be realistic and cut unnessary or hard to implement features. You can still add them later if you have time left (you won’t XD).

Use tools you know well and can handle. If you try something new (like I did with box2d and box2d lights this time), have a fallback plan, in case you fail. You don’t want to spend half of the time fighting with your dev environment. You want to make a game.

Be prepared. I have setup the git repository and the project before ludum dare started. When I knew what I wanted to do, I could just startup eclipse and start coding.

Know your schedule and set deadlines. It is important to know how much time you will have. If you don’t set deadlines, you will be tinkering in your code and lose focus. You can still stretch a deadline if it is to hard to meet, but try to be in time.

Don’t lose too much time for unimportant stuff. If there is a simple way of doing something and a cleaner one, that takes much longer to do, don’t bother with the complicated one. If you need something better you can still refactor it later, if you have the need for it. (Disclaimer: This does not mean “Write ugly code.” but “Don’t write unnessesary code”).

Take a break once in a while. I had more good ideas on the potty like I d’like to admit :wink:

Mute communications: while it’s ok to have a look once in a while at what’s going on on the compo page / email / facebook / jgo, you should restrict yourself. try to work without distractions, then take a break and update your feeds, if you have to.

Most importantly: Have fun :smiley: If you notice that your initial idea is to hard, just scrap it und do something silly and simple. Or do a more simplified version. or stop if it is too much of a pressure for you. I had to abort my first ludum dare, because I got sick. it wasn’t fun working in this condition, so why bother.

one last thing that I find utterly important in programming in general is the ability to identify and break down problems. If you are stuck with a big mess and don’t know what to do, it is very likely that you don’t understand your problem well enough. Investigate what you are doing and find out what the factors are for your problems. You will often find that your main problem consists of multiple smaller problems. You can check those problems again and split it up further until you have a bunch of small problems that you can solve each on it’s own.

As a small example, let’s take the problem “I want to make an AI for my ludum dare game”. This are more or less my thoughts on what I did to identify the challenges of this task.

I want to have different behaviors, like finding food, chasing an enemy or evading

- Access information about the game world
[list]
[li]Access to the existing food entities
- Access to the existing cells

[/li]
- Information about the entity.

- Decide what the entities behavior is

	[li]When to run away/evade?
	- Who is the biggest/nearest threat?
	- When to attack?
	- Who to attack?
	- Where is the nearest/best food?

[/li]

[/list]
I need to execute my ai routines

- access to entities
- execute behavior update
- execute behavior
[list]
	[li]Find out applpied force (directional force based on target and behavior)
	[list]
		[li]Move towards target
		- Move away from target
	
	[/li]
	- Control the entity (actions/velocity/position etc.).
[/list]
[/li]

[/list]

Conclusion: Now when I look at this list, I already have a much clearer picture of what needs to be done. But don’t start making lists all over the place. Decide on a design/architecture/whatever, start working towards your goal, and if you find any problems, just break em down :wink:

I agree with troll. You should aim not for making a game engine but creating an actual game. The engine will come as a result of that. I’m currently working on an Arkanoid clone to get used to using audio with LWJGL, and after that moving on to make a multiplayer version of Zelda 1 to get used to networking. Since I know what game I’m making, the engine is tailored around it, because the engine is only there for the game, nothing else. Not like there is a yearly Game Engine showcase.

About game design, it really helps to play older games and stage-by-stage analyze them to see why they are built the way they are. Here’s a couple good bookmarks I have, if it helps:

Legend of Zelda: A Link to the Past in-depth analysis

Super Mario World Game Design analysis (Pretty long read)

Essay by Tevis Thompson about what makes Zelda fun, and what could be better

One thing that hasn’t been mentioned.

Don’t think your game will suck. Complete it anyway, and let the users tell you what they think.

Game making is all about making mistakes, and most programmers don’t like errors. Hell, that is why we have debuggers. For gaming, you have to let the users catch your errors. That is the only way to get it done. Let go, and create the game no matter how it turns out. It never is as bad as you think.

[quote] The game was going to be about digging and looting different dungeons, labs, etc. for oxygen tanks, weaponry, and health packs. Inside said dungeons, numerous enemies could be found.

-Made Engine
I made a tile-based world with lighting, and randomly placed structures.

-Added in player things
The player sprites were made, and he can dig around everywhere. Great!

-Added in enemy things
I added in enemies that patrolled the dungeons. This is where it began to fall apart. I realized that 90% of the gameplay was digging through vast amounts of land in a probably fruitless effort to find dungeons. Project quit Sad.
[/quote]
Next step: “balancing the game play”.

You have a clear idea of what might make the game boring. Can the design be altered to balance this out? To lessen the time spent digging: can the geography be changed? If there are geographical constraints that make it difficult to do so, perhaps there are tools (sort of divining rods? some sort of explosion/radar pinging to echo locate chambers?) to help direct the player to where to dig so that the percentage of digging drops to something more acceptable?

When reaching any stage that is tough, that would be a good point to consult with others for ideas. I think it is very rare for one person to be good at handling all stages of game building.