From the lighthouse to the business of orbitals

Mandatory report on a project done in a Game Development course at ITU.

- trailer made by Nils Sørensen

In this report I will reflect upon the process of coming up with an idea for a game to be developed with the Unity game engine, as a programmer in a group of five people attending the Game Development course at the IT University of Copenhagen.  Brainstorming was a large part of the process and that part alone had several phases where ideas shifted shape many times over and prototypes were created and thrown aside.  A large part of this report will thus accordingly be devoted to that process along with a briefer coverage of the technical implementation, where I had a delightful immersion in a technology new to me, opening up doors to new paths to explore.

With darlings set aside rather than killed, as I would like to see them, the group settled on a concept to follow through and the development of a deliverable product proceeded without hiccups, consisting mostly of the linear completion of tasks we commonly agreed upon and prioritized.  The outcome is a fairly polished game offering a rather basic gameplay, though with a few twists, that may appeal to a broad audience of casual players.

The development environment and division of roles

Before the process began, a Game Development course announcement of the requirement to use exclusively the Unity game engine within all groups, came as a surprise.  Even though I am aware of that Unity is the most commonly used engine by game studios, at least around the Copenhagen area, I had not been in a hurry to become acquainted with that environment.  One reason is that I do not specifically aim for a job within the game industry.  Another reason is that the games, or interactive experiences, that I have ideas and ambitions for, might not fit well within the framework of any given game engine, where I would rather like to use my background as a web developer and an enthusiast for the possibilities of the Internet.  When considering game engines I was most interested in the new Goo Engine^[1], that is based on JavaScript and web technologies, like WebGL, that are closer to my heart as a web developer.  Another option I fancied was to continue developing a specialized game engine^[2] I had begun work on in a previous ITU course and base a new game on it.

Even though this was an initial surprise, I was easily convinced of the benefits this requirement would give, where all team members were most likely to be familiar with the Unity game engine and so would have a level playing field, giving experience with one of the most commonly used tools and spoken languages in the field of game development.  In a previous Game Design course I lead the team into developing a custom server side solution and a client app, where no game engine was used whatsoever, utilising my forte as a web developer, where admittedly other team members may have had a hard time getting up to the same speed I had with the technology^[3].  Even though the project from that course may be considered a success, the choice of technology may not have been fair to everyone.

When it came to dividing roles within the group, I was open to working on tasks other than programming.  Sound design interested me for instance, as I’m an amateur iPad composer and a compulsive audio app purchaser.  Also I was interested in 3D modeling, as I’ve previously done hobby projects in that area^[4] and were at the time enrolled in a 3D course^[5] at ITU.  Taking on those roles would have been a welcome break from programming, even though that is still my main passion, but it turned out to be logical that I took on the role of one of two programmers, as there lie my strongest skills and experience.

Still, I had no previous experience with the Unity game engine and it required some effort to come to grips with that tool.  Before doing anything else, I went through all the official Unity tutorials to gain a footing in that environment and in the process I came to appreciate the possibilities this tool has to offer, in terms of being able to quickly realise visually interactive designs and to reach a multitude of platforms with ease.  In other words, I was easily sold on Unity as a weapon of choice.  Within Unity I chose to use the C# programming language, that I had limited previous experience of, rather than JavaScript (UnityScript) that should have been more familiar to me as a web developer, since I was already in the business of trying out new things.  By now I have started new projects using Unity and can foresee using it in the future.

The student groups were assigned a limited amount of Unity Pro licenses, valid for the duration of the semester, and we utilized them for among other things to communicate with a Unity Asset Server that we set up on a cloud computing instance^[6].  It gave the development process a more integrated feel to have source control management within the development environment, though we probably would have done just fine using for example a Git repository and an external tool^[7].  The three licenses our group was assigned went to the two programmers and our game designer and graphics artist.  A fourth license for our 3D modeler would have been nice, so everyone could have communicated within Unity through the Asset Server, but we solved that with the less fancy, ad hoc manner of delivering 3D models through our private Facebook group.  #firstworldproblems

Brainstorming

Initially we discussed what kind of play we wanted to create and for what platforms.  One style fancied was that of exploratory games, like Dear Esther^[8] and Flower^[9].  We discussed adhering to dogmas such as having no scoring system, no narrative or textual explanations but rather only visual cues, and we even considered exhibiting permadeath as a game characteristic^[10].

Though we are interested in mobile touch devices as platforms for games, we did not want to exclude other platforms either and so kept the choice open until rather late in the process.  Even though we have now settled on the Android and iOS mobile platforms, the game actually works reasonably well also with mouse input in a desktop environment, which we indeed use for development and initial testing iterations.

The lighthouse

The first brainstorming sessions were sparked by a photograph of a lighthouse in Iceland^[11] that has an unusual design which can resemble a space pod of some sorts.  We toyed with the idea of being able to fly a lighthouse like this, exploring and discovering the environment, collecting objects that might count towards completing a goal.

One concept had the player surrounded by seven platforms, one of which is populated by a lighthouse that can be entered and flown towards flashing lights on distant shores, going through swarms of obstacles and energy units^[12], finding that those distant lights are other lighthouses that can be brought back to one of the home bases.  Each of the distant lighthouses flashed one of the seven colours of the rainbow and when all of them had been collected to their bases, their combined lights would form a white boulder or beam of light that would lead to the next level^[13].

Several other concepts were based on that lighthouse photo, involving among other things guiding ships, rising and falling sea levels, and even going through different environments on each level, like underwater, through forests and space.

The elements

Those concepts based on the lighthouse may not have been tangible enough and too abstract to grasp, and we received the encouragement to simplify and focus our ideas.  Subsequently the idea sprung up to base a game on the classical elements of fire, earth, water and air.  That lead to the concept of fixing planets ruined by their inhabitants by applying the missing elements to them.  And from that we got the idea of a planet trading business, where the game takes place in the context of a market where the buying and selling of renovated planets takes place, with planets habiting elements of high demand being more valuable than others, and the player has the role of a planet businessman, taking on contracts to prepare planets according to his clients’ demands, collecting revenue from successfully completed contract work, enabling her or him to sign up for grander contract work offering larger payout.

As much as I had already invested enthusiasm for the concepts based on the lighthouse, it was a rather easy transition to shift focus to a game based the classical elements, especially given the environmentalist context of ruined planets and the capitalist context of selling planets with elements in high demand.  Still I was fond of those lighthouse concepts and took the position to explore them further at a later convenience, rather than to kill them on the spot, feeling well equipped by the newfound powers of Unity.

The mini games

Having settled on this concept based on the classical elements we began to define gameplay within that context.  We had the business- / repairman and a vision of his home base as some sort of a garage floating in outer space.  That was going to be the game’s center and a point of entry into mini games where the player would go on missions to gather elements.

Initial thought was to have four mini games, one for each of the elements, with different challenges and each even with different game mechanics.  We realized soon though, that creating four mini games and the central game management in the garage would probably overshoot our capacity during the semester and halved that possible overscope by discussing the feasibility of two mini games, where one would offer the collection of the more tangible elements of earth and water, and the other would inhabit the less tangible air and fire.

As I had become fascinated by an art installation design of a constellation done for theLAGI renewable energy initiative^[14], I volunteered to create a prototype of a mini game where the player could collect both air and fire elements in an environment inspired by that design.  Another team member created a prototype for collecting the earth element and possibly also water, where boulders were rolled with game mechanics inspired by the gamesDragon, Fly!^[15] and Giant Boulder of Death^[16].

The simplifying U-turn

In a meeting where we were presenting the two prototypes and trying them out, we had the rather insistent encouragement from our producer to simplify our concept even further, with the specific suggestion of implementing one mini game with 2D gameplay where spheres of elements would reside in each of the screen’s four corners.

Having seen that meeting as a time to flesh out a list of tasks to carry on with the already began development, I could not help being visibly irritated; an appearance supported by the lack of sleep the night before doing prototype work.  Those feelings carried on into the next day and had me dazed by how emotionally invested I had become in this project.  I felt done with brainstorming and ready to move on with development, having once developed enthusiasm for the lighthouse concept, set that aside and again built up steam for the classical elements concept with different mini games that implementation work had already begun on.  Gameplay in 2D for this project did not initially appeal to me either, as we were working in a mandatory 3D engine and I was thinking quite literally in the dimensions offered by that.

Even though I was still rather annoyed for the second day by those repeated changes to our concepts – having personally transitioned twice from a brainstorming mode to a focus on implementation, building up steam to only extinguish it and go back to the drawing board – I could also realise the sensibility of those suggestions and also feel they were well received and easily grasped by other team members.  So I wrote a comment to our team’s Facebook group, stating how I could understand the new angle as a feasible option, and other team members saw it the same way.  At a later meeting our producer mentioned his concerns of having possibly intervened too much in our process, which indeed at the time I felt to be the case, but regardless we went along with the suggestions and steered the development towards that new angle.

Settled on a new course of action, it was time again to implement a prototype based on the new concept of a single 2D mini gameplay.  Here our main concern was how to represent visually the reception of elements on the subject planet.  To start with something simple to implement we decided to split the planet’s sphere into four segments, or wedges, where one would be receptable to one element each.

That representation indeed resembled slices of a pizza and having sharply defined quarters of the sphere, each only capable of receiving one element, was regarded as making little conceptual sense.  So we discussed a representation in the form of nested rings, one for each element.  How to implement those rings was not clear to me and I thought initially about stacked discs, like in the Towers of Hanoi puzzle^[18], and later became fond of the form and mechanics of the gyroscope^[19], which the game uses in its current form, with nested rings rotating randomly.

Development tasks and their division

Programming effort was in large part divided between the garage and the one mini game of delivering elements to the subject planet, where I devoted most of my time in the latter, focusing on the touch interaction with elements, their reception on the center planet and managing the progression of play in time and the approach of goals (rendered with progress bars).  Highlights in that process include the gyroscopic rings of element reception; a module for spawning asteroids as obstacles, fully configurable in the Unity editor; configuration of obstacles for each level in the editor for a designer without any programming; handling multiple, simultaneous, touches of the elements, offering a cooperative play; and making victory and failure exit animations with mecanim, a non-programming task I jumped on to try out some of the movement through 3D space I so much desired in the game.

Later on I joined the garage, implementing a HUD in the form of a clipboard, using Unity’s mecanim system.  Also I added the ability to look around the environment by touch and to buy elements from the shop before going on missions, among other tasks, like finding planet textures^[22].

The modeling work, graphics and code from other team members flowed smoothly into the project via the Asset Server.  During development it was good to have as a reference a game design document created by one team member, where among other things aspects of the economy were outlined and interactions of elements were defined, that are in fact yet to be implemented in the game.

Name quest

One of the seemingly most difficult tasks of development has been choosing a name for the game.  In a cycling tour around Refshaleøen I came across a barrack marked with the sign “Copenhagen Suborbitals” and that got me thinking about the word “orbital” and subsequently suggesting the name “Out of Orbit”, which is actually used by a small game currently in the Google Play store, but it has stuck as a working title, while other ideas include Elementix, Elexia, Elementum, Elemia, Elemental Architect, Elemixir, Elemade, Elemaden, Eletrade, landMiller, landMaker, landMakia, planetShop, orbitalis, orbitalia, or even just suborbitals.

Conclusion

Beforehand we were warned that difficult moments could arise in the process but I was not really worried about that as I consider myself pretty much open to all types of games and not tied to any specific genres of play as I’m in the first place not so much of a game player – having reached the hardest core of game playing in the early 90’s when I finished the permadeath game Prince of Persia and all episodes of Commander Keen – and so felt open to follow along to wherever the process would take us.  Regardless, ideas sprung up early in the process that I quickly clung to and built up enthusiasm for, that I later on had to suppress when other ideas surfaced, that were possibly more realistic and generally acceptable.  Those changes proved indeed to be sources of surprisingly difficult moments for me, though fortunately they did not last for long.

Overall I feel that the group worked very well together and no conflicts arose among the members.  Only I had to make an effort to keep in line with the level of diplomacy and air of serenity within the group, having invested personal enthusiasm for what I must admit were darlings in the moment.  Along with the immersion in Unity’s technical intricacies, it was a great learning experience to go through those development phases, even though I have been around the block once or twice in a previous career as a software developer.  Especially it is interesting to have taken part in the evolution of ideas through all their phases and to compare that process to how other known works have changed dramatically from their initial concept to their published form^[23].

Do I think we could have had more interesting gameplay with the multiple mini games previously prototyped?  Yes.  Do I think we have a more manageable project and a unified experience with the focus on the current mini game?  Also, yes.  And the experience the game offers in its current state is enjoyable enough to have me and other team members interested in continuing work on the game, to have it presentable for the Google Play and Apple App Stores.

IT University of Copenhagen
Game Development course – instructors:
Henrike Lode and Mark J. Nelson
spring 2014
Björn Þór Jónsson (bjrr@itu.dk)