Building Your Very Own Robot at Home or How Game Content Development and Design Works
Here in War Robots development team we’re used to working on mechs on a daily basis. Lately I’ve been asked a lot by players and some co-workers alike about the content development pipeline in our game — what it looks like and what stages a robot has to undergo before being released (or rather, sent off to war).
Although I have been doing this for a while now, I can imagine the process being a complete mystery for someone not directly involved in it. So, what does it take to ship an actual playable piece of content from a game designer’s perspective?
Idea
It all starts with an idea. It does not matter whether it’s just a crazy random outburst you had when you woke up in the middle of a night or whether it’s a well-thought concept that has come a long way. The inspiration may come from a simple player comment on Facebook just as it may be born of a casual remark of a friend or co-worker passing by your workplace. You see an awesome picture on the web or you go to the cinema to watch a great movie and bang — there it is, an idea, sitting inside your mind and taking over, kind of like in Inception.
Usually we game designers have quite a few ideas already on the list when we sit down to discuss the content to be put into development but something new and unexpected may certainly come up during the discussion. Or, some of your old ideas could be presented by someone else on the team in a completely different way that you haven’t thought about before. It’s like a joint creative brainstorm and you never know where this discussion will end up. I would say that we mostly base our final decision — that is, which idea to pick this time — on what makes us all agree about it being really cool.
Design
Before an idea becomes an actual playable in-game object it needs to be given a shape and to give it a shape you need a plan — a schematic in the form of descritive text that the rest of development team can refer to. You can’t ask someone to draw something for you without thoroughly describing what you have in mind first, right? We call such text plans game design documents. That’s where the technical and creative parts of a game content designer job collide as you transform something metaphysical from inside your head into a physical object that has dimensions and properties.
Basically, you do this by describing the future robot’s type, weight, height, width, movement speed, special ability (if it has any), its combat advantages and disadvantages, weapon configuration and more — pretty much everything related to the gameplay, balance and outlook — in detail. You think about its origin in the game world, you look for suitable reference images all over the web that resemble — closely or distantly — the final visuals that you’re trying to achieve. Such images supplement your descriptions and give artists on the team a general working direction.
Concept
Next, idea and design take form of a concept. Traditionally it’s a 2D or 3D art created by a concept artist in an attempt to visualize the design as accurately as possible. This step is needed to actually see the visuals of a soon-to-be-robot for the first time and decide whether the original design needs any adjustments. The accurate bit is pretty important, because a concept plays a big role in shaping the final product and is somewhat of a foundation for a 3D artist later.
However, not every detail needs to be perfect at this point — basically, you and the artist can write down a list of things that should be changed when transitioning from a concept to the end product and not alter the concept art further, but rather move on to the next step to save time. We usually show the concept art to our players throughout the development of a robot to show what we’re working on and get some feedback.
Prototype
After the concept is approved by a game designer, a 3D artist starts working on a low polygonal model of the robot while programmers prepare the necessary code (if the robot requires any outside of what already have been developed for other robots— say, if it has a new, unique ability never implemented in the project before).
Eventually what we get after importing such model into the game engine and setting it up is a working prototype that can be already played and tweaked. However, it’s not ready to be released yet — such prototype has no textures and is basically very raw in all senses. The model is not the final one, there may be bugs in the code, the animations might need some adjustments and more.
Such prototype is needed mostly for gameplay reasons since now you can actually try your hand at the designed robot, see how it fares on the battlefield and basically decide if playing it is as much fun as was originally intended. This is all achieved by the means of the game engine — it allows you to spawn the robot, walk around, shoot things (or bots / other developers) and see what has to be improved in the final version. Some things that don’t require drawing or programming you can usually quickly fix yourself — such as adjusting the colliders by changing their size and shape or altering robot’s movement / rotation speed or tweaking its behavior on various surfaces by allocating its support collider and selecting a material for physical interactions along with changing its properties.
We also give our players a go at testing this early version of the robot and sharing their impressions about it by deploying this prototype on a special test server. Then we analyze their feedback and reflect on our own thoughts after playing the prototype in conditions that are close to the real battle and figure if any adjustments to the balance are needed (such as changing the amount of hitpoints or movement speed or even something bigger like removing one of the weapon slots thus rendering the robot weaker).
Product
The moment we start testing and tweaking the prototype, a 3D artist is already hard at work on the final 3D model of a robot. This include high poly count mesh, diffuse maps (color, pattern), normal maps (bumps, scratches), specular maps (lighting), animations and such. When it’s all ready, we update our former prototype (which at this point is usually balanced and rid of bugs) with the new visuals, see if everything looks and works great and do a couple of final pre-release open tests with our players to make sure everything works as intended.
While usually we’re pretty sure about what to expect from a final 3D model and the artist knows what he’s doing too, sometimes things can go not quite as planned. For instance, after conducting a series of tests with the prototype we might decide to alter the robot gameplay a little bit and that alteration might need adjustments to the visual part as well (which at this point could be nearly — or actually — finished). Imagine that you had to take away the robot’s ability to jump for balance reasons — now you have to also physically remove the jet pack from the model to stay consistent and changing a high poly model is no small task.
Finally, when all the necessary adjustments have been made and your shiny new balanced bug-free polished robot is waiting to tear his enemies apart, you can take a moment to contemplate all the hard work that has been done up to this point and relish in the feeling that you have made it — you have walked this path to its end and can now ship the content to the game to the joy of your players. That’s it, right?
Post-release
Well, not quite. While you might think that at this point everything is all good and done, it can be far from truth. After being shipped to the live game your awesome well-balanced and thoroughly tested robot can change the meta of the game by shifting its general balance (i.e. making the players favor the new robot or certain weapons that are good against it etc.). It’s not necessarily a bad thing — actually, it’s not a bad thing at all, since such changes are great for keeping the game fresh and enticing.
But that also means monitoring the new content after release, seeing if it needs any additional adjustments or if it’s actually the other robots that now need the adjustments after making place for their new competitor. But hey, let’s talk about this in detail some other time, shall we?
If you liked this story, you may find some of my other stories relevant:
How to balance your game using statistics and math
