Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Let's all share our tips / tricks for creating games :)

A topic by coquigames created Jun 02, 2017 Views: 508 Replies: 7
Viewing posts 1 to 4
Submitted(+3)

Hi everyone,

As we all rush to make our games I thought I'd share some tips / best practices I've learned from doing game development for the past 6 months. Please feel free to share your own tips and tricks with the rest of us as well :)

I'll start:

1. Plan ahead - The first thing I did when I read the announcement was to pull up Notepad and write a few ideas for the game jam. Planning your features / code ahead can be very useful in making sure you don't spend too much time focused on the wrong thing :).

My notes for my game idea:

======================
IDEA 1
=======

Puzzle platformer game based on a switching mechanic where two objects are tagged and switch places for a limited amount of time

Mechanic -> 

-Shoot one object and tag it -> change material
-Shoot second object and tag it -> change material and call EventSwitch event
-EventSwitch switches object transforms and starts timer
-After timer runs out, switch objects back

->Disable gravity while objects switch so you can switch objects beneath your feet

Power-Ups:
==========
-Longer switch time
-More than 1 pair can be switched at a time (max 2 pairs)

Use cases:

-Switch positions of a small block with a long block to form a bridge and cross a chasm
-Switch positions of movable object so now you can ride the object while it moves (create BP that moves with TM)
-Can switch multiple pairs in the given amount of time
-Switch position of interactive objects -> trampoline, slide, ladder, etc

Interactive Objects

-Movable platform -> moves sideways or up and down
-Rotating platforms
-Jump pads
-Switch that opens a door
-Ladder that lets you climb

======================

2. Leverage your strengths - If your strong point is programming, make sure you lean on those skills when designing your game and vice-versa with the art. In my case, I have a coding background, so I will keep art to a simple low poly style with minimal animations. If you are an artist, keep the gameplay elements simple (easy to code) and focus on creating beautiful art!

3. Create a prototype FIRST - This is huge and I learned this the hard way. I recommend you flesh out your mechanics first and implement a prototype to test gameplay BEFORE worrying about your assets. While you code, use simple cubes to depict characters. At this stage, your goal is to see if your idea will work (technically) or whether is fun. After you nail down a good amount of functionality, only then create your assets and import them.

I wasted countless hours while making my first game because I would create 2 features and then start building a level. Then I would incorporate another feature that would break my level so I had to redo it again (say now you can double jump so your platforms need adjusting).

4. Making a prototype and making a game are two different things - Your prototype above is just the code to get your mechanics going. A game will include your prototype, plus actual art assets and a bunch of stuff a game needs that you dont think about - start menu, pause menu, death and restarting the level, HUD, etc

Make sure you give yourself time to implement that functionality and dont leave it to the very end :)

Thats all for me, anyone else want to share some advice?

Completely agree with developing the prototype, hell I believe in most big budget AAA games they consist of prototyping and programmer art until the last few months of development. The utmost core importance is to get it working before you get it looking good. Obviously this doesn't apply to people in teams with set roles, but in that situation, planning is of key importance before any asset is created or feature implemented.

Writing it all down is important too because it gives a clear list of what needs doing and when, including a list of art assets you think you'll need. This can be expanded upon or reduced in development.

To give a tip that isn't just reiterating what coquigames said, is to pick a scale and stick to it. This applies to art, but if you develop art assets, they'll be for a specific size, so when you import them into the engine, you may need to scale them up, but be cautious of having scales vary too wildly. For instance, if you model your character to be a specific height, then you'd obviously want your wall with a door frame in it to be a specific height and width for your character to fit through. So when you import them into the engine, and scale the wall to be 2x larger and your character 3x larger, then the character may not fit through the door anymore, or the door will be inconceivably large when your character walks through it. Same can be said for tables that are too wide or chairs that are too high. It sounds like a simple thing but I see it all the time in indie games, especially the horror titles.

Another tip is to use pseudocode. What that is is breaking a function down into steps in plain English (or your native speaking language), outlining what exactly needs to be done. For example, if you had a gun that shoots and when a barrel gets shot it explodes, what you would do is write something like:

1) Figure out if the barrel has been shot (hit with projectile)

2) Play a particle animation of an explosion 

3) Play an explosion sound

4) Delete the barrel from the game (or swap it out for your exploded barrel model depending on how complex you want it to be).

Then you have a clear understanding of what needs to be done, and gives you focus points on what to search for in your programming documentation.

Submitted

Absolutely agree on the pseudo code! I use it all the time to create complex code and also to debug. Cant recommend it enough!

Submitted

Another tip: Use paper and a pencil. Do not underestimate the power of a pencil. I use it all the time for prototyping a level, making concept art, etc.

Submitted

Another great tip! I've been using pen and paper to wrap my head around vector math lately :)

(+3)

Probably the best advice I can give is to keep your code modular. For example, if you're working in Unity limit your scripts to specific behaviors; ie: individual scripts for moving, aiming, inventory, and whatever other abilities a character might have. This way you can quickly add or remove features, and edit mechanics individually rather than risk breaking your one character controller.

Submitted

Best advice! Some of my game jams end terrible because of my code breaking.

Submitted

Another excellent tip!