Building the game, where does one start?

News & General Discussion
1

Ok, I just want to make it clear that I am not asking how to do a game, that bit is fine.

I was simply curious as to where you guys start with your games? I am sitting here with an idea, and no idea where to start, I done some simple games in the past as a group thing where it was simply a 2D platformer, and we just picked a job and we did that and thats that.

Now I am starting a game with a friend of mine and quite frankly I am not entirely sure where to start, we got the idea down, we know what we want.

So the issue I have ran into is that I simply do not know where to start from, do I start with the backgrounds? The main player object? Or do I start with the menu.

So I was just curious where you guys usually start when you are starting a new project.

2

Do you know the basic gameplay concept? Once I have an idea of a game, I sit down, pull up the last working game that I have released, and just hack the sucker in! I use existing art, UI, and code to get the BASIC mechanic working as quickly as humanly possible. Then, I play, code, play, code, play, code until I begin to truly feel whether the core concept is worthy of a game.

Often, I can have the basics running within a day, maybe a week. Then, I spend time iterating the idea, until I have found the fun. Not until then, do I even remotely begin thinking about art. Lately, I spend a few days polishing it into a “Minimally Viable Product” for release on Android - aka feedback.

That’s how I start,
Gigi

5 Likes
3

Thanks for your reply, and since I am completely new to unity I do not have any previous games, but I’l guess I just need to dig into that sucker and just see what I can do.

4

When I started my current project, I focused purely on getting the the gameplay right. Nothing else. Just simply the gameplay.

I used placeholder art I obtained from various sources for the characters and sample level.
The key is to not do too much. Just do the very basics: 1 player character, 1 or 2 different types of enemies, and a short level and see how it goes from there.
I tested the gameplay and tweaked it until I liked it, and to be honest, I tweeked it quite a lot, being a perfectionist! :stuck_out_tongue:

Once I got the gameplay down to my liking, I started working on the blueprints of the game. It’s important not to spend too much time and energy working on those because a lot could change as you’re progressing on the game and as you get feedback from playtests.

After that, I worked on adding more content to the game. I’m a one-man-team so I got a bit tired after a while so I switched to making the UI for a bit. Then I went back to working on the game.

My next step will be to work on the multiplayer aspect of the game, since my game is primarily a multiplayer game. After that, I’ll go back to finishing the UI.

5 Likes
5

I second all of the advice given so far. Start with gameplay first. Get a playable prototype as soon as possible.

I personally tend to build the critical systems first, before getting into exact game play mechanics. In Pond Wars it was the water and the waves. Once these were built I said “how can I make this more fun”. Then I added the boats. Asked again “how can I make this more fun”. Then I added the shooting mechanic. Most of the rest was just minor tweaks along the same lines. “It would be more fun if your sights changed colour to indicate you could shoot.” “It would be more fun if you had health bars” “It would be more fun if…”

The sequel that I’m currently working on arose out of the question “Would it be more fun in 3D?”. Soon I’ll have the bare minimum built in 3D (Boat on water with waves). If this is fun then I’ll continue with the game.

3 Likes
6

I’d suggest that before you even get to the playable prototype, that you start with a set of notes covering everything you want to get out of the game; everything you want to make. Then, throw most of it out. Distill it down to the most basic detail: On Paper! This is essentially making a Design Document (Or Game Design Docuement). It’s surprising when you sit down and start jotting down notes, how much you can work out in your head and on paper.

I prefer something freeform. Note cards on a table. Spread them out. Color code them if you need to. Lots of stickie pads, as they’re cheap! Thrown it all in a heap, and then sort thru them. It can be great fun… Then simplify it down to the absolute core elements that you want to play with.

Then build your core only prototype.

If it works using only capsules and cubes, you’re on to a winner.

Then start adding placeholder art.

4 Likes
7

Its always better to plan things out before creating anything (game, music, art etc…), makes things easier in the long run. Some designers write up to 500 pages of GDD and they get straight to work without stopping, some just do like 10 and they end up changing and improvising to the point of sometimes losing the integrity of the idea.

8

From what I’ve heard, there’s something of an art there; too much, and your design is constrained and you have difficulty changing if needed; too little, and you can have difficulty staying on target.

9

Thats why you spend a lot of time making those 500 pages of GDD :smile:, so that theres nothing that would be needed to be changed ( mostly )

10

Fixing things early is better than fixing them late, and if you have a 500 page GDD document from the start, you’ve probably done a lot of design work that could be done later.

The minimal set principle seems useful here. :slight_smile:

1 Like
11

Yeah, there are many in the community that advocate massive GDD before you code a single line. I personally hate the idea.

GDD are great if you need to work with a team and keep them all in line.

But for a guy coding on your own, you’ll learn far more about your game from building a prototype then all the pages of specifications in the world.

2 Likes
12

I have divided my game production into several stages:

  1. Idea - come up with an idea, brainstorm a bit
  2. Prototyping - replicate that idea in a simplest form possible, minimum art used. If game is not “fun” then back to stage 1
  3. Enrichment - if prototype is “fun” then add more features, create different mechanics around it, use placeholder art
  4. Art - this is where you sketch stuff and actually put graphics into game
  5. Audio - give your game sounds and music where possible
  6. Testing - always test your game: especially at enrichment stage, you should always know whether your game remains as fun as your prototype was. Have others to test your game as well
  7. Launch - publish your game to stores, showcase it to others and receive feedback to further improve your game

Some people may have different approaches to their projects, but I find this effective so far.

1 Like
13

Well, we’re talking production, not learning… Or any least I am.

It’s always fun to fuss and faff with a project, but if you want to deliver a project and deliver efficiently, you need to have a goal. The “play a game into existence” method can be fun, but it’s not very practical.

If you don’t have a goal, you won’t know what direction to go in to reach it.

Now, on the other hand - fun, learning, exploring - you can really do anything you want. Just fuss around until you find something fun. There’s a lot to be said for that.

If you have a strong idea about what you want, planning it is the best way. I’m working thru a complicated networked game right now and I have not yet once opened the editor for this project, and yet I’m working through one problem at a time, one problem after another, as these primarily take thinking time: architecture, design, gameplay, scope - it can all be done quicker and faster on paper than trying to code examples and try them out.

Some people might not think of it as that much fun, but - are you trying to ship a game or play with one?

6 Likes
14

While writing out your idea, you’ll also be amazed by all of the aspects of your game that you didn’t think of. I can’t even count the number of times I’ve been writing and planning and run into a design flaw that would have been disastrous had I discovered it while building the game.

15

Avoid theory.

The easiest thing to do is to determine which “screens” you’ll have. Like, title screen, gameplay screen, menu screen, game over screen, victory screen, continue screen, etc. and code up the logic for switching between all the screens. When does the game start? What variables determine game over? How do you win? Write that up in variables and use key inputs to trigger things to happen, like press “k” to kill the player, etc. Construct a basic skeleton for your game. Then, start fleshing it out by adding more features. Then make it look a little nicer. Then test. Then add features. Then make it look nicer. Then test. With luck, your game will take shape and you will like it.

If you start with the underlying details first and work up to the presentation, you’ll save time and have less bugs.

The worst thing to do is hit the presentation layer first, get a working game loop running and then test/tweak/test/tweak until it’s fun. When you do that, you leave the underlying details in a state of uncertainty… which means you’re working on the graphics but you don’t know what game you’re making. Which means, lots and lots of testing extremely early in the process, followed by repeated major changes to the core gameplay, followed by bugs and fixes, followed by soul searching (why isn’t this fun?), followed by development hell and, if you don’t quit, you’ll have a game on your hands… but it might not even be a game you meant to build.

So, recap… start practical, detail oriented, focus on the things that won’t change much/at all early in the process and then iterate over and over, gradually building it up. You’ll have more control over the way your project is going this way, and less likely to get stuck 100 hours down a rabbit hole.

Good luck and remember, you can always ask for help once you get started.

Sources: Experience, hundreds of hours I can never get back.

2 Likes
16

Thank you so much for all your replies, I can tell not everyone thinks the same way and that’s good to know, then there simply is no wrong answer on where to start.

I have a basic idea of what I/we want to do, so I am going to start by trying to get a basic skeleton up to just see if it’s fun or not, the art and animations comes in at a later stage.

I run into the issue of having a million ideas about what I want to do, I continue to have ‘amazing’ ideas about the game in question and while doing so I might be overthinking what I want to add into the game, so I always end up adding more and more features to add in, and that just ends up being a list so long it just seems overwhelming, so I am trying to focus on the basics for the time being.

A game with cubes and spheres so it’s not a pretty game, but it’s not suppose to be this early on, it’s suppose to be fun, the looks comes second after all :wink:

2 Likes
17

I like to spent a few days to get a proof-of-concept going; Basic controls and interaction ,maybe even an enemy or item. Code effectiveness and cleanliness is not important at this stage, it will be little enough to tidy it up later. However, this small concept will quickly give you an idea if the game you are envisioning will have the potential to be fun to play; Often, an idea that seems great in theory doesn’t hold up in practice. An example: My very first project was to be a close remake of the 1993 Amiga game Hired Guns. Gameplay was basically like Legend of Grimrock: step-by-step movement and turning in a 3d world made from blocks. However, I quickly found out that is just wasn’t much fun to play, mainly because this rigid movement system doesn’t lend itself well to fast-paced first-person-shooter-action with rapid-firing guns, grenades, and whatnot. So I started it a new with a a free movement system as common in modern FPS.

2 Likes
18

Ok, up front I’m just a student that has made a few games for class assignments but haven’t done anything I’d publish. Like you my head fills with all those brilliant ideas (& then & then & then…) So I now mind map them. That lets me dump everything from my head so I’m not trying to keep track of it all & I can then go through it, expand on stuff, create linkages, delete bits etc. this gives me a visual representation of the interactions. Using that I look at the bits that have the most linkages as it usually indicates a core bit then using capsules, cubes etc I try to code those bits in (I have quick dirty movement & camera scripts that I use for every game then tweak/hack as needed after the first run through) leaving commented place holders for where that script may link to something smaller I’m not looking at yet to see how it feels. Changes are made & if it feels ok I add the next bit & keep iterating until I get to adding the bits with single linkages.

This is a slow way but as I’m only learning it lets me stop at a point where I’m happy & it meets the requirements for my assignment & I start fixing art, sound, scores etc. I will always have the mind map & what I have done so I can go back & revisit it later when I learn more. The time away also makes me look at the mind map differently when I do go back & changes are always made. The biggest thing I’ve learnt so far is no matter how detailed the mind map at the start the game still never comes out fully formed at that initial run through.

19

This, although for a different reason.

Especially for beginners or big games, theory is generally used as a way to make you think your working without learning any actual skills. Its why I dont recommend you write out a GDD for your first game, its just busywork to keep you off doing any actual development.

1 Like
20

Personally, I like to start with a scene specifically for testing and building prefabs and controllers the draft out the core ideas.