A playable demo fully realized.
You will need to register, but you can always put in a fake email address, it's not used, since I don't have a password reset system installed yet. Just leave the default key when you are registering as well. Keys are currently turned off.
When you get into the game, you can either play one of the tutorial levels, or try using the editor. The editor allows you to not only manipulate rods embedded in the walls (extend, retract, rotate), but to also place attachments onto panels on the rods. These attachments are generally sensors (like buttons) and effects (like lasers).
In addition, you can lock rods in place, and turn of the refraction panels in each rod. Normally, when the rods have lit panels, you can shine lasers into them and they will reflect back out another panel elsewhere on the rod (possible even a panel still not extended from the wall, so keep that in mind). A laser can reflect through as many rods as it hits, so a single laser might pass though the entire map several times.
All attachments you can add to the rods can either hear or transmit on a channel. Channels range from 000-999, and include some with special abilities:
- 001-009: These channels are regularly triggered every 1-9 seconds in play mode.
- 900-998: These channels only trigger once, unless reset by calling the relative channel on 800-898.
- 899 resets all the 900 level channels.
- 999: This channel tell the game the player won. Try to put a trigger with this someplace hard to reach, but not impossible.
The player start position will be the same as your own position when you saved.
Yeah, looks complex, don't it?
This game, while not finished, is definitely in the late beta stage. It includes the following features:
- First person camera action, based on movement and jumping less than shooting.
- An environment that changes to present puzzles based on room configuration.
- A full level editor, including the ability to test your created maps and publish them for others to try their luck against.
- Full sound effects.
- Start Menu to allow feature navigation.
- A key registration system that ties a single product key to a username/email/password. This system is similar to what steam uses for it's product registration. The key system is currently disabled, allowing anyone to register.
- Web based server for registration, sharing levels, and leaderboard scoring (this section still needs work, but is mostly ready for use).
- It has reflecting lasers! And crushing walls! And changing environments!
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.
Made with Unity! RayFrakked
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 over a year 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 game design 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 framerate.
- 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.