• Foolish Frost

RayFrakked (or how I built a game in a single month)

This game was conceived, designed, and built in a single month.  The only parts that I used from the outside were a texture pack I purchased, and some of the sound files.  Everything else was created myself in that time.

Game Design Specs.

  • Concept took about 3 days to begin with, and expanded from there as the game was designed. 

  • The game itself was created in Unity3, using UnityScript as the coding base. 

  • Models for the game were created in 2 days (including rejected model attempts).

  • The FPS is a default Unity design, with modifications.

  • Sounds were downloaded from FreeSound.org, and processed using Audacity and Sony Sound Forge.

  • Start menu uses the default GUI system of Unity, as does the HUD for editing maps.  This was Not fun, but it was educational.  At this point, there is not much I can't do with the GUI system.

  • The key registration system used a random key generator software for windows that I can't for the life of me remember. (this was years ago).  It was able to generate a text file of thousands of non-repeating keys I was than able to upload into a sql database.  Those keys are then in one of three states:  Stored (you can't register them), Ready (they can be registered), or Used (someone registered the key).  This allowed me to make sure every player always have a unique key.  This took about 4 days to setup.

So, how did I build a 3D game with all these feature in a month?  

By knowing how to design the game from concept up with reduced production needs in mind.

  • The game has no characters that are seen, so has no need of organic modeling, animation, or character AI development.

  • The game actually only has around three main models.  The walls, the pillars, and the spacers between the pillars. Talk about limiting asset needs...

  • The pillars all use the same code, and are generated when the game starts.  This means most of the game logic was built when one pillar was created and designed, and changes to the code/model of one pillar changed them all.

  • The game is single player, with only web calls to transfer data to and from a php base server.  This means no needing to deal with realtime servers, networking code, and debugging.

  • The game is made to allow the player base to develop puzzles.  I'm just creating the tools.  While I obviously will need to create tutorial levels and some starting puzzles, the players will actually be playing against each other and trying each others maps more often than not.  Since the game does not allow an unbeatable level to be created (since the player making it has to be able to beat it to publish it), this means that all maps are "possible" to win against.  (Yes, I know they could make maps that are nothing buy trial and error, but that's what ratings are for).

What kinds of problems did I run into?

  • The main issue was with rendering 9x9x6 pillars (that's 486, for you non-math types), that move.  Check out most games you play, they do NOT have that many moving parts.  Combine the increased render passes with physics needs, and the framerate initially slowed to a crawl.  It took nearly a week of remodeling the pillars, testing rendering modes, and a host of other research to get the game to where it is now.  In addition, Unity 4 sped things up considerable in terms of rendering speed.

  • The Unity model imports from blender using FBX were kinda sketchy back then.  Much easier now, though.

  • Sounds.  Not making them, but playing them.  With around five hundred pillars, all potentially moving at the same time, each making it's trademarked grinding noise...  The sound system broke.  I was forced to make a system to que and limit sounds that could play at one time.  Otherwise, it sounded like a trainwreck.  A lot of trainwrecks.

What would I like to improve and change?

  • Well, I'd like to remove channels and add some kind of visual connection between attachments.  Not sure how I would do that without making it an even MORE complex mess to figure out visually.

  • Finish adding the voiceovers for failure, clues, and humor.  Those were fun to make, and yes, they ARE my voice.

  • Cleanup of a lot of kludge code.  Heck, would love to upgrade it all to C# as well.  Just to keep up with my current coding preferences.  

  • Get the level selection system finished, polished, and linked to the websystems fully.

Overall, it was a fun project that proved that it was possible to build a full 3d game in just days.  It just takes limiting your designs to allow for your skills and available resources.


©2018 by John Bowden of Foolish Designs. Proudly created with Wix.com