Just a note to say the obvious – this blog is old and no longer updated. I most likely won’t see or reply to comments here. For up-to-date goings-on, find me on twitter: @robotduck
The week is complete!
This afternoon was crunch time as we made sure all students finished their games and tested them as much as possible. Those who had finished helped play-test each other’s game for the rest of the afternoon and one or two just managed to solve their final bugs in the last hour!
Out of the ten students, eight chose to upload their games to Kongregate, so without further ado here are the links. Enjoy!
A huge well done to all the students for learning so much and getting their games finished. The week was a total success!
Day 4 complete. At the start of today I introduced the idea of “Feature Lock”, meaning the deadline for implementing new features. Our feature lock deadline is the end of today. Tomorrow (the last day of the course) should be reserved for play testing, bug fixing, polish and publishing. This means all the core gameplay mechanics for the game should be complete and working, even if some parts of the game are still using placeholder art, or have no sound, for instance.
The students all made a lot of progress again today, with some games looking almost finished by lunchtime, while others are cutting it somewhat finer in terms of getting a finished playable game ready for tomorrow. One of the difficult parts of running this workshop is making sure that everyone understands how much we can and cannot get done by the end of the week, and which elememts to focus on. For example, having a working title screen, lives system and game over screen which allows the game to be restarted is more important than finding some royalty free music for each level, or tweaking particle system effects!
Anyway, here are some more screenshots of the games. We have a really nice mix of styles including 2D platformers, first-person maze and exploration games, driving games, tank combat, a vertical scrolling shooter and the LHC Particle game mentioned above! We’re hoping to get them uploaded by the end of tomorrow so they will all be playable.
Day 3: All the students are well into their own game production now. Today featured a lot less teaching up on the big projector and more one-to-one time with each student tackling the challenges unique to their projects.
I introduced the idea of setting “milestones” as a way to track progress and ensure students are concentrating on the highest priority areas of their game development first. This is to ensure we don’t get bogged down in details (such as artwork) before we have all the basic game mechanics implemented. Many of the students ended the day with the functionality implemented for a title screen, game over and end-game conditions, and other “core mechanics” they’ve chosen such as collecting items, opening doors, etc. We still have a long way to go with only two days left though, so I’m trying to instil the idea that tomorrow (Day 4/5) should be considered the last day in terms of implementing features, and Day 5 should be solely about testing, polish (and adding any extra art to replace placeholders), and publishing.
Some snapshots of some of the games in development:
Day 2 complete!
This morning I covered a lot of ground. By lunchtime I wanted all the students to have come up with a simple game design document showing the plan what would be in their game. First of all though, I wanted to give a wider view of some of the different styles of game that can be made with Unity, since we spent the majority of the time yesterday looking at things via the standard first-person controller prefab, and I really didn’t want to end up with ten first-person cube-firing physics shooters at the end of the week!
I demonstrated a range of different pre-made types of “player control” as alternatives to the first-person control we used yesterday. We had:
– A rotational third-person character with an over-the-shoulder camera view.
– A directionally-controlled character with a higher overhead style non-rotating camera view (rpg style).
– A physics-ball control similar to marble madness / super monkey ball.
– A generic flying “vehicle” which could be used for anything from a bird to a jet fighter
– A steerable car using wheelcolliders and suspension
I also ran through a list of the types of interactions and game-like activites that are particularly easy to achieve in Unity, such as
– Collecting items
– Physics challenges (building/toppling stacks, see-saws, swinging or hinged objects, etc)
– Numeric counters (ammo / health / targets or checkpoints hit)
– Trigger and Collider events
– Animation (eg, doors opening)
I also presented a short slideshow explaining a useful design “tool” described by Charmie on the funstormgame.com blog which is basically a simple diagram which helps you look at a game in terms of layers, with the game’s “core mechanic” at the centre, surrounded by secondary mechanics, then game progression, and finally the ‘story’. The article is a good read, and the slideshow I made was basically just a bulletpointed version of it.
Armed with this inspiration, the students were able to come up with lots of ideas – a few of which were possibly on the ambitious side given that we now have 3.5 days remaining, so I had to help them by suggesting simpler compromises – and by lunchtime each student had their own mini game design doc, complete with a “core mechanic” diagram describing their game.
In the afternoon, everyone dove headlong into making their games, and while going round the room solving individual problems, I also tackled lots of common game features on the projector for everyone to see, such as how to make a title screen, level progression, time limits, more complex trigger mechanisms, 2d camera work, the terrain engine, GUI text and 3D Text.
By the end of the day I was seeing the beginnings of lots of interesting games:
Day 1 complete! The starting skill level of the students is little-to-no experience with Unity or game programming. Some of them have done a little coding in other languages, and some have done some quake mapping using quake level editor tools.
This morning was spent mainly getting familiar with the editor, the various windows, creating primitives, manipulating objects in the scene view, importing simple assets (textures, 3d models), materials. In the afternoon we all created a very simple game together designed to quickly tie in a lot of basic concepts such as collisions, prefabs, instantiation, physics, and some simple scripting covering applying forces, sound sources, spot audio effects, detecting collisions and destroying objects with explosions!
Our sample game involved spinning flying saucers flying over a simple scene, with the first person controller modified to fire physics objects when the mouse is clicked. When the saucers were hit, they fall to the ground before bursting into flames.
From tomorrow the students will be branching out with their own game ideas – starting with making a simple game design and specification document, including deciding on what are achievable targets within the remaining four days. Should be interesting 😀