Unity 3D is a great game making engine that allows indie developers and larger companies focus on game design rather than building all the components a game needs to run. This is great, but there is still the issue of creating art for the game and for people like me that is always a problem.
Be warned though that it’s not just drag-and-drop from SketchUp into Unity as the models need some touching up to be able to run smoothly in Unity. Knowledge of SketchUp and Unity are obviously required before trying this all out. Plus, not all textures translate well into the game either.
So why even bother with this process? Fristrom outlines why you should care:
So this is a viable method of level construction for a variety of uses:
if you’re a hobbyist game developer
if you’re looking for placeholder assets to prototype with
if you’re looking for assets that will never be too close to the in-game camera (buildings in the distance; or a racing game where the off-track assets are whipping by at 100 mph)
if your game has a highly stylized non-photorealistic look
Doing this is unfortunately not appropriate for mobile development – even with Unity Pro, the performance of these assets are simply not good enough for mobile.
There are other ways to build an environment that may interest you too. Obviously, you can just use stock items and geometric shapes for testing the core of the game but often more is needed.
If you’re like me you’ve wondered how Unity got so big so quickly and is so good at what it does. At Slashdot, they have a great article on the history and the creation of Unity 3D. It’s really neat to read about the design approach behind the software insofar that they were inspired by FinalCut Pro and how it opened up filmmaking to smaller teams.
Despite the big names using Unity3D, it’s the smaller developers that make Helgason especially proud. “Big companies could always make games, they would figure it out and buy technology or build it themselves,” he said, adding: “Where we really made a dent is making it so that these masses of people can not just build games but can build games using the same tools as the big guys.”
Last weekend myself and a great team of game designers set out to make a game which uses basic EEG readings as a mechanic. The main source of inspiration of the game idea came from Doctor Who’s weeping angels. The gist of the angels is that if you look at them, they will get you when you look away. Don’t even blink.
Here’s what I sent out to the team prior to the jam so that we’ll all be on the same page:
So in sum, here’s the basics of the game:
Single player (1st person perspective)
Escape a procedurally generated room. Over and over again; like Groundhog Day but meant to scare.
Gameplay: Player starts with the camera locked on the statue then they have to navigate to the doorway to escape the statue without physically blinking. If the player blinks then the statue teleports to right in front of them, they are granted only three blinks. Too much blinking = death.
Art: all we need is furniture and a statue. I think dim lighting will allow us to get away with lame textures and stuff.
After that email one of the team members suggested we make the game playable without monitoring physical blinks, so we’d have a version everyone can play and a “hardcore” version. The core mechanics then should be similar in concept to how Slender Man games function.
In short, we didn’t finish the game but we did make something playable. We blinked.
Here’s what happened:
First some context, TOJam is a fantastic annual game jam held in Toronto and it gets bigger and better every year. The event has hundreds of people all descend on George Brown College to make games starting on Friday and having something playable by Sunday evening.
Reading minds
We wanted to use an entry-level EEG device the MindWave because I have previously seen it used for other games built on Unity. It was more complicated than anticipated to use the MindWave with Unity. We spent a good chunk of the first day trying to get the device to work.
This is after some time spent on Thursday trying by myself to connect Unity and MindWave. The image below shows that the device is connected, the connection software (ThinkGear) knows it there, but the application claims the device is not there. I didn’t know if I should’ve directed my anger at MindWave or Bluetooth. Overall, this was frustrating and I was hoping that the talented programers would know where I went wrong.
After some struggle we figured out how to connect the MindWave and rewarded with this screen (enlarge to see what the MindWave records):
Fantastic! Now we can really make this game interesting.:)
Then we discovered that the blink mechanic we wanted to use in the game was actually hard to read with the MindWave. They have a blink detection system but it’s not clear and requires some educated guessing. A lot of this effort could have been avoided if the company behind MindWave released some Unity project files and demos (they have one but the download link was broken).
Even though we successfully had Unity and the MindWave talking to one another we decided to put it aside because of Bluetooth chaos. It was time to make the rest of the game.
The room
For the atmospehre of the game we originally envisioned something that seemed OK, but then got creepy like a museum after opening hours. When looking for reference pictures, I chanced across a great series of photos from the decaying Prince Edward Hotel in Brandon Manitoba (of all places) and it looked perfect.
Saturday saw the game go from primarily creepy to something more typically found in the horror genre: the abandoned building. It wasn’t a big change and was decided upon before most of the modelling was started.
Getting the room to procedural generate wasn’t too complicated and we got that working. As the code was being written we had a statue constructed and then built all the furniture that will be placed around the room. Things were going smoothly. We had all the pieces of the game being built separately and by the end of Saturday it looked like all we had to do was put the pieces together.
It looked like we’d even have time to get the blink working. Even if couldn’t get blink functioning we had other mind-reading functions we could incorporate.
Here’s an early screenshot from the game:
It’s so dark and gloomy to make the game hard without the MindWave.
It’s worth mentioning that we had off-site support for our audio and the fellow behind it made some insanely freighting sounds. The audio was done on time and, oddly, was the last thing we added to the game (just because it’s so easy).
The final day
After a late start, we got all the code from six separate computers on to one. We didn’t use Dropbox at the behest of the organizers, but in retrospect we should have broken that rule. Then we ensured that all the pieces would fit together.
I know it says 8:04, the Windows build was first.
This last days was the most hectic as it now relied mainly on the back of one of the programmers. We got the most important parts of the game working and some of the room elements working as well. We didn’t bother putting in all the assets we created as with what little time we had left we opted for function over form.
With that in mind, we decided not to incorporate the physical blink detection at all. It came down to a functioning game or a game that would probably break during the evening play sessions. One programmer went so far as to figure out some more of the MindWave but, due to too much going on, we didn’t incorporate it.
We figured we can easily add in the rest of the assets afterwards.
Around us other teams were play testing and celebrating their complete games. We, on the other hand, didn’t even have a chance to play test. TOJam game-building ends at 8pm and at 7:50 we tried our first complete build…and it worked!
This was particularly exciting for me as it was the first time at TOJam that I was part of a playable game by the end of the weekend. Of course, other games there were far better than ours, I was still pleased.
Next steps:
We will continue to work on the game to make it more playable and a better experience. By better I mean scarier. With luck, this will be playable for the TOJam Arcade for everyone to play.
Some stuff is obvious from what we ran out of time for:
More assets for the room and for the player to bump into.
Audio to accompany all the objects that move.
MindWave integration.
More early rooms to train the player before they get to the procedureally-generated rooms.
From play testing at the jam I noticed we need:
A way to end the madness as both “win” and “fail” states are the same – you end up in a new room. This was always intended but we never gave the player a stop button.
Better training levels to cue the player as to what’s going on.
The exit needs to be more visible.
We need a better way for the player to figure out where the statue initially is.
Thanks! A BIG thank you to all of team Oh My Glob!
And thanks to all the wonderful people who made TOJam happen from the organizers to the sponsors to the volunteers! Without all their combined efforts we never would’ve had this game this far along.
In retrospect, I don’t know why I felt the need to write all this down. Thanks for reading!
You must be logged in to post a comment.