• Register
Post news Report RSS Finding the Minimum Requirements

A brief post about finding the game's minimum requirements and developing the game according to them.

Posted by on

For this brief post I thought I'd share a little bit about the game's minimal requirements, especially with regard to desktop gaming systems as well my own development machine. To begin with the requirements are listed here. There isn't anything substantial about them, and actually for modern systems the GPU spec is probably much lower than most other first-person "open" games. With that said, the goal is to maximize my development machine to make the best game possible with the resources it has.

Boundaries

When development started two years ago I was unaware of the true value of a vertex. Especially in context with other aspects of game design such as image post-processing, audio, frame-rate, textures, physics, dynamic lights/shadows, shaders, resolution, and on and on. All I had was my trusty 2011 MacBook 13", an idea, and a year or two to commit to development. I knew what the game should look like, but I was also realistic. Not to mention I had (and still have) limitations when it comes to 3d modeling and texturing. But that's part of the challenge that I enjoy. And so began the journey of learning how to use Unity, Blender, Photoshop and various other tools to create something.

The first cave which consists of a terrain for the ground and a mesh for the ceiling.

After research and experimentation, the first iterations for the game consisted of basic caves, terrains, and several objects of various complexity as far as modeling goes. The main purpose for these iterations was to experiment with some core gameplay mechanics, start learning the tools, see what the movement and controls would feel like, and to see what my machine is actually capable of since I'd be using it for the next couple years for development (start-up company resources are limited). So came the process of experimenting with various types of terrains, smoothing vertices in Blender, adding/removing dynamic lights, trying different shaders, and generally just trying to find the balance of cost vs. performance, so to speak. I came to an obvious conclusion: my machine has a huge limitation as far as the GPU goes (fillrate bound). It was obvious in Unity's profiler and statistics screen too. Frame rates early on were not very good.

But I also realized some major pluses:

  • My machine had CPU cycles to spare
  • My machine had memory to spare
  • Less complex models means faster turnaround when making changes
  • Focus can still be on crucial elements - story, gameplay, and immersion

The first canyon terrain I attempted to make.  It was poorly planned and a bit too large.  For scale, the player is about 1mm.

So all I had to do was limit the vertex count, take advantage of the CPU and memory, and try to be as quick about it as possible. Pretty obvious, I know. This also meant there would be room for some image post processing (which is important for the overall look and feel). After more testing and even more experimentation during the second iteration of the game, the numbers started to become more clear:

  • Limit the number of vertices per frame to somewhere around ~70k. This is a bit difficult as a minimally complex terrain is already capable of taking up anywhere from ~50k to ~65k with one directional light.
  • Limit the number of dynamic lights per frame to around 6 or so.
  • Limit the number of dynamic lights with shadows to around 3.

Low Poly?

With the information above locked in, the focus for 3d modeling was simple: learn how to model objects using the fewest amount of vertices as possible while still being recognizable. Then use the available memory for "decent" textures and shaders to make up for the lack of vertices. With a budget of sometimes less than 5k vertices per frame and over 350 objects to model, there was and still is a lot of trial and error. Actually at the time of this writing there are only two models in the game with more than 900 vertices, the terrain and the NPC characters which were modeled in MakeHuman (even the MakeHuman models were decimated in Blender). Everything else leans towards the "low poly" side. But this also means next-gen mobile gaming devices and tablets will likely be able to run the game fine. I've already had some success running the game on Nvidia's portable Shield. On the down side, much stronger gaming rigs will not have higher poly objects. However they will likely have a fantastic frame rate.

With all that said, the goal is still to make a game that looks good (open to interpretation) and performs well. A complimentary goal is to learn as much as possible to maximize the results for this game as well as future games. Even to this day, subtle tweaks to older object models can sometimes make a noticeable difference. There is still a ways to go to find that perfect balance. But I definitely think it's as close as it's ever been. Plus I can't imagine what it will be like to make a game on a system with a dedicated GPU. In any case, the focus now can shift to building up the next levels which is very exciting.

Thanks again for reading!

Larry

P.S. There are more images of the game development process here: Imgur.com

Comments
e_Glyde
e_Glyde

Really informative article.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

News
Tags
Dev Diary
Browse
News
New
Post news
Report
Report
Share
Related Games
Hevn
Hevn Realistic Sim
Related Engines
Unity
Unity Commercial
Related Groups
Miga
Miga Developer with 2 members
Unity Games
Unity Games Hobbies & Interests with 1,789 members