Week 2 – Getting the basics down
When at Disney I dealt with schedules a lot. At most publishers you set up milestones where certain parts of the game are due at certain dates. As the publisher you review them, and send back feedback, the developer responds, and the cycle continues next milestone.
This game is primarily a two man operation; myself and the programmer. So while I have a general schedule as to what parts of the game should be done when, it is pretty fluid. I work with Morgan to see what is realistically done this week, and what parts of the game have the biggest ramifications and what is hard for him to fix later, and so should be done first. Many of these are not what you think they would be; dialog and whether or not decisions are always Booleans (yes or no), and how inventory works are essential to nail down right now, even more so than some of our most fundamental mechanics.
My role has producer is thankfully limited with this small team. Morgan and I work closely, daily on what we need to do, and I deal with the various people I need for art sporadically. So let’s look at briefly what we were doing last week and what we are up to now.
1. Getting the pipeline set up.
Before you can really do anything, we have to get the pipeline set up. The pipeline is the the flow of operations needed to get to your finished product. AKA, how you do crap, and send it to each other so its not all messed up when you put it all together. You have to make sure there is a way to transfer files, make sure the code being worked on is shared between everyone, and also that you can get it playing on the systems to test it.
Developers differ greatly in how they put together their pipeline, and big games have incredibly elaborate set ups since dozens if not hundreds of people are working on a project. It gets even more complicated when different parts of the developer are working on not just a single engine, but dozens of middleware used for physics, lighting, etc. Source control is a big issue, which means simply making sure that people aren’t “saving over” others work. When the code is compiled, there shouldn’t contradictions in different people’s output.
Not much an issue with 2 people. Our source control is, ‘let Morgan know if I am about to do anything’. Unity works in “scenes” which are like discrete levels that draw from the assets in the production folder. I can work on something, package it up and send it to Morgan. He can simply import the package, and as long as he was not working on something specifically within that scene, there is no issue.
We use Dropbox to transfer files. Dropbox is totally rad, gives you 2gigs for free. Actually, I just went to the website to copy the link, and they gave me 250mbs for free. I have no idea why, but that is awesome. Seriously, I can’t believe I wasted my time a few months ago setting up an FTP for something else.
An important part of the pipeline is how you test your game. We do it two ways. Unity has a app called Unity Remote that lets you control your build on your computer via the iPhone. It is very nifty, as you can literally change a variable for speed, press play, and then instantly test it on your phone. Thing is, it is a bit sluggish, and looks like crap on the phone. Since it is sluggish, it means sensitive inputs like jumping or pinpoint touch controls can be hard to test. So while great for on the fly testing and quickly checking out your level while actually making it, its not all that great for long term testing.
Test level running on Unity Remote, it looks even uglier in motion
For compiled builds we use a web/iPhone app called Test Flight. Test Flight is website/app that lets you upload builds that are then instantly distributed to whoever is on your team. So every few days, Morgan compiles the latest build and places it on Test Flight, and anyone I want to can download it. Very nifty.
Since it is an actual build though, it requires using Apple’s xCode, which is Apple’s IDE (integrated development environment) that compiles builds into a magic package that the iPhone likes. To do this you have to register as an Apple Developer. That only costs $99, so that is not bad at all. However you have to go through their certificate / authentication process which took Morgan and I literally a day straight to figure out. Maybe we are both idiots, but I have to say, for how smooth and easy Apple’s UI is on their devices, their developer HUB is a nightmare when it comes to simple things like adding people to your team and how to certify yourself to play your own builds. Anyways, after we got that set up, we could start building the game.
2. Core Mechanics
Last week we were getting a first pass at most of the core mechanics in. I would say about half of them have their first iteration complete. Not all of them are necessary to nail down now for a few reasons. Our game has mechanics that are added as the game goes on, so early levels don’t use all the mechanics. Also, some mechanics are easier to tweak later. Also, the way some of those mechanics “feel” will be tweaked as we playtest. Things like momentum, “stickiness” of a walk or movement, or other things of that sort will always be tweaked.
Jump height however is something that has to be decided pretty quickly. Things of that nature direct level design. When you design a game with any platforming elements, you should know the exact heights and distances of your jumps. Take Super Meat Boy or Donkey Kong Country Returns. Those games are polished and designed to the nth degree. Platforms and gaps are the perfect distance. If halfway through production Retro said, lets increase DK’s jump by 150%, it may break the game. Well, it would break the game. The would have to redo tons of level design. As I have 4 months to do this thing, I cannot afford the risk of changing such a core fundamental. This is easy to see in Super Meat Boy which has different characters with different abilities. You start seeing how levels can be exploited by characters with different jump heights. Of course they design the game with that in mind.
So we nailed down some of the most important mechanics so I can begin level design. However, that is an ongoing process, and I will have even more mechanics dropped into the game this week.
3. Level Design
The only way to really feel the mechanics is to place them in levels. In my GDD I have general sketches of the different areas/zones/levels. Now is the time to start designing them with mechanics in place. My pipeline goes something like this.
Paper Sketch a level => Make block version in Unity => Try it out => Make changes => Place Art => Tweak
The making changes and tweaking stages are an ongoing process, and will get repeated many times. Art sometimes changes things because elements easy to understand may be obscured by art. An example out be a ledge being less clear, so perhaps you make a easier to see ramp to the ledge instead of a blind jump like before. An easy one to look at is in a FPS, sniping lines. Towers and windows are changed all the time as trees, or geometry can give a sniper or player more or less line of sight than the level designer would have originally thought had they simply been looking at a top down map.
Below is one of the first areas that I did top down map of. This has already drastically changed.
Doing a quick map gives me a general feel of the area, but it will look very different by the time its done.
I then make a plane object in Unity, place the .psd image of the map on it, and then scale it in relation to my character. That way, I can literally drop blocks and make a very simple version of the level, and then move around in it. Here, I get a sense of scale, quickly see which areas are problem areas for my camera, and also what is boring lame level design. Which happens all the time. In the image below in Unity you can see how often I move stuff outside what was planned on paper. This is a very quick pass, and already you can see the outlines of objects I moved, and places where I changed the scale, etc.
You can see the image above is the texture of the floor, so I can place objects on top of it.
This game has well over 30 areas for me to design. I want all levels to be at a first pass stage after 1 month, so that is about 1 a day. Cranking out the levels is my primary task for this week. Morgan is getting various systems together for me, such as dialog, cutscenes, etc so I can start working on that. We are also doing optimization tests to see how many polygons we have to work with, and what the art will look like. Niko from Corridor Digital is doing that with us, so you should have something to see maybe next week.
If you have any questions, or want to learn about anything specific in our ongoing process, just comment below.
Also, if one blog a week isn’t enough, and you also like random links to videos and other dumb stuff involving games and movies, follow me on twitter. You can also ask me questions there.
Is Unity free?
You can use it for free with limited features. You can buy a license for $200, or a professional license (dont need the Unity Splash screen, as well as various professional features) for $1500.
Actually they scrapped the $200 “indie” license they used to have. Now they only have the “Unity Free” version and the $1,500 “Unity Pro” version.
But yeah the free version is a stellar product. Very few features are Pro only, and the ones that are aren’t vital to development.
Or you can to to thepiratebay
Does’t work if you want to actually use Unity.
There can be nothing more stupid than pirating an engine, and then releasing a commercial game with it.
Hmm..
hmm… yes?
I’ve always wanted to know how to use Unity. The computers in my Digital Arts class all have it on them and I have no idea how to work it
Unity has a great set of tutorials – http://unity3d.com/support/resources/tutorials/
Step by step. Will easily teach you the basics.
Are you just on the main phases, or do you already have a story down? Also, i’d like to know what type of game it is. You said you need to determine momentum, and jump height, so there must be a character, rather than the player being the overseer. Perhaps it’s a third person shooter, or an rpg?
^ this please. Can you make a blog on what type of game this is without giving away too many details. This would definitely help me visualize what you are talking about when you discuss the technical stuffs
Yeah, hopefully next week I will have a character design / designs to show you guys.
I will try to reveal a bit more of what the game is like, but it is at such an early stage I don’t want to go too much into it if stuff changes.
But within a week or two, you will have a better idea of what time of game it is.
FREDDIEW AND CREW, Y U NO GOING TO THIS? http://playlist-live.com/lineup/
You say that things like dialogue and inventory systems have to be decided really really early on, is that specific for unity or do you mean that for programming in general?
Say someone wanted to make an RPG type of game which would be text heavy due to storyline, does all of that have to be decided and finalised way before any development begins? There is absolutely no practical way of changing these kinds of things once game development begins?
Its not that each line of dialog needs to be decided beforehand, its the dialog system that needs to be nailed down early on. Mass Effect for example has a very complex dialog system, with branching paths and multiple responses, but something like pokemon typically just has static messages and yes or no branches.
The idea is to have every NPC use the same dialog system. So if you make a pokemon style system and then half way through development you decide you want some of the NPCs to have a more complicated interaction, they will have to be coded separately, and it will force you to modify your player character interaction system to accommodate the new NPCs types.
So the idea is to avoid modifying old code, which would increase the chances of a bug arising. The written dialog itself is very easy to add/change/remove/edit during development.
What type of game is this? Looks like a platformer, or maybe those pics are of a map for FPS. Is it 3rd person game? What type
The android process is not near the price nor difficulty as the Iphone Developer stuff.
I highly recommend investing in the license. It’s 25 bucks FOREVER to join the market and doesn’t require all the crap fees. Other than the engine licensing for Unity’s android, It should be well worth it to port to the android market.
Thanks for the share on the Test Flight! Great link