Blog

Architects’ attempt at making a game for 48hours

The short story: This is what came out – Slider – lets you create stuff by sliding rows of cubes and 3D print the result.

It is not so much a game as it is an interactive design tool. We couldn’t escape our architectural background just yet : )

At the end of this post there is a link to a playable web version of Slider and a video of how it works.

We’ve also included a link to the first 3D printable model created with Slider.

 

The long story follows below. It is in the form of a log that documents to a certain extent our thought process and also turned into a kind of repository of useful links and resources for getting into Unity development.

Hope you enjoy it. Read, play and we’d appreciate if you give your feedback in the comments.

 

 

We’ve been looking into the gaming industry for around two years now and feel excited about what it could bring to architecture. Games are especially inspiring for our design explorations of architecture made by the inhabitants. In our work we use a lot of interactive design tools that we develop ourselves and we are more and more convinced that game engines and game design is the most natural and effective way to engage users in the creative process.

 

This year we wanted to participate in the Global Game Jam 2015 at its Berlin location, meet like-minded game developers and learn more about how actual games are made.

Global Game Jam happens once a year and according to their website is the world’s largest game jam event (game creation) taking place around the world at physical locations. Think of it as a hackathon focused on game development. The weekend stirs a global creative buzz in games, while at the same time exploring the process of development, be it programming, iterative design, narrative exploration or artistic expression. It is all condensed into a 48 hour development cycle. The GGJ encourages people with all kinds of backgrounds to participate and contribute to this global spread of game development and creativity.

Unfortunately the Berlin GGJ event went quickly overbooked so we decided to do an in-house game jam at AWARE here in Frankfurt while keeping the basic rule – release a game in 48 hours.

Let’s start!

 

 

Friday – 15:00 CET

Starting point:

We were recently inspired by this Minecraft python script developed by Cody Sumter and Jason Boggess in the MIT Media Lab. It lets one 3D print a part of the Minecraft world. We tried to imagine what a simpler game might look like that combines the 3D modelling simplicity of Minecraft with a direct link to 3D printing.

 

Goal:

The goal for the next 48 hours is to create a rough prototype of a game that empowers anyone, designer or not, to create a personalised 3D model of a small-scale object and also lets them order it for 3D printing.

 

Gameplay:

We’ve been looking into the combination of user-friendly design tools, games and digital fabrication for a while now. The gameplay is the trickiest part, as with all games in general. It needs to be simple and fun, yet allow for advanced users to make more complex objects.

 

Minecraft is one direction we looked in. It has a simple gameplay – you either remove or add cubes of various materials to the game world. It also has a great community of players and the worlds and gadgets that they have created is mind-boggling.

 

Another, more abstract approach we’ve tried in previous in-house prototypes so far is a Match-3 gameplay, where a combination of three cells of the same kind would result in a new kind of cell. Sharing the match-3 game prototypes we’ve made with people around us gave us the invaluable feedback that while they are very interesting from a generative point of view, i.e they allow the creation of unexpected results, the whole experience of a match-3 design is quite abstract and difficult to engage with.

So for the next 48 hours we’ll work on the more direct, cube-based gameplay strategy, taking references and inspiration from Minecraft and the likes.

 

Game Mechanics:

An idea we wanna try this time is that the game character will be the 3D object that the player is making. The game starts each new player as a simple matrix of cubes. The mechanics we need is something that rearranges the cubes and allows for some to be removed and new ones to be added. The direct click-place approach of Minecraft has been very successful and might be best also in our case, yet we feel it is too literal.

 

We’d rather try a mechanic that has a higher degree of unexpected results while still not losing the direct control over what the player is making/designing. So we thought of giving the player the possibility to slide full rows and columns within the matrix of cubes. As a scarce game resource, the player moves could be limited and more moves can be gained if a goal is achieved.

 

Game World:

In our game there will be two semi-independent game modes: One, where the player walks around in the gameworld and collects/exchanges resources and the second mode which is for crafting and shows only the object being made.

 

Tools and platform: for development we’ll be using the free version of Unity and we’ll aim our prototype for the iOS but share it with you over the Unity web player.

 

But enough talk. Let’s make a game!

 

Friday – 15:57 CET

Wanderer Mode.  This mode ideally would be a nice, welcoming and relaxing place to be, a place where the player would not mind to spend all the time that they have. A good reference is Proteus – a procedurally generated world:

 

We’re going to use Chinese perspective for the camera projection. Chinese perspective is used in the Chinese scroll paintings like the one below and its advantage in games is that it is scrollable and displays the relationships between object in a clear way. Setting the scene camera in Unity to orthographic with rotation angles (10,75,0). Here is a great guide on axonometric projections in games from where we took the angle values.

 

Let’s make the gameworld an endless flat surface with resource cubes scattered onto it. The player can pick those resources up to add to their design later. Resources would be renewable. Everything in the gameplay, solid cubes, hollow cubes, number of moves, even the possibility to 3D print could be a resource that the player needs to acquire. Still open for discussion which resources will be limited and which renewable.

 

Friday – 18:55 CET

The gameworld is now 150×100 cubes large. Camera is set up. Since orthographic projection in Unity does not support Fog, we used a set of 85 planes with material set to Particles/Alpha Blended (alpha setting = 3 / 255) in order to soften the horizon. Resources travel down from the sky along vertical beams. The beams are randomly scattered. The graphic style and colors are far from ideal but, hey, it’s a prototype to be made in 48 hours.

Next up is player/camera navigation…

 

Friday – 19:20 CET

Found a “tap to move script” from here which we are adapting for the character controller.

 

Friday – 20:00 CET

Character is moving in the world. Next steps would be to allow for the collection of the falling resources and change the avatar to a matrix of cubes that could be edited in the crafting mode of the game. But before continuing to develop the wanderer mode we’ll start something up for the crafting mode to see how these two modes could work better together.

 

 

Friday – 21:00 CET
A thought regarding the resource beams: Maybe as the player enters under a beam the first few cubes equal one new resource unit each, but as time goes and player is just sitting there the value of each falling cube could become a 10th or even a 100th of a resource unit. This is to encourage exploration as opposed to idle resource mining.

 

Saturday – 00:53 CET
Crafting mode: Made a new game scene where a matrix of cubes is generated upon start.

It is made out of cube prefabs with invisible “feeler” objects attached to all their sides in order to detect their neighbouring cubes at runtime. We adapted this from the method shown in this video series on making a Match Three Game in Unity3D by Grim Grin Gaming.

We can define the count of cubes for x, y and z direction. Player can tap and slide a row/column of the matrix. There is a bug which appears after a row is moved – row chains are not constructed correctly and only part of a newly tapped row is moved.

 

Saturday  – 1:55 CET

For the past hour we’ve been playing with the slider-crafter gadget – sliding, sliding and sliding – with matrix of 5x5x5, 7x7x7 and 10x10x10. It seems this toy might go somewhere.

Next step is to introduce a hollow cube prefab for the empty cells and to trim all cubes that shoot out of the matrix volume after each move.

 

Saturday – 11:42 CET

Back to work after few hours of sleep. Sliding logic needs to be rewritten completely. Now.

 

Saturday – 13:00 CET

A lengthy discussion on gameplay. Why would it be interesting for the player to slide rows of cubes and how to achieve that?

What is the type of game we wanna have – is it a survival game, where one has an antagonist character/force to avoid or fight, something one has to overcome in order to remain in the game world; or is it a puzzle game, where your goal is to make or reach a specific task for the level, and you have to be faster, doing it with less moves and so on…

What makes a game interesting and addictive? Actually humans have an inborn instinct to play – we play every day, and it is not necessary to be a super fancy 3D graphics game or one with a very complicated plot. We solve puzzles every day, play Sudoku constantly for centuries, and the Rubick cube is a classic puzzle already. The only thing needed to provoke your will to play is a very simple set of rules (might be even only one), a clear goal and you are on to it.

 

Saturday – 16:45 CET

Had to rework the crafting toy to allow for the later addition of new cubes sliding in and to properly determine neighbours after sliding. Also we made it trim the cubes which end up outside of the matrix dimensions after a slide is completed. This was done to keep the spatial envelope predefined because 3D printers have a fixed build volume sizes.

 

Saturday – 17:15 CET

Game Over idea: If the game is based on the number of moves/slides the player is able to make, then we could use this shattering game-over effect when the player runs out of moves. That way if player wants to 3D print the object then he/she has to get to the result within the number of moves available.

 

Saturday – 20:00 CET

Basic sliding crafter is done. It has two type of blocks – solid and hollow. Now looking into adding more types and as well into the matrix generation algorithm.

It could be interesting to start the player off not with a matrix of only solid blocks but to use perlin noise algorithm and spawn various types of blocks into the initial slider matrix.

Here is a good resource for procedural perlin noise world generation.

Types of blocks we could have are: solid, hollow and porous.

 

Saturday – 21:24 CET

After a thorough search online for generating perlin and simplex noise in Unity and reading through several sources, found a great free plugin in the Unity asset store – Turbulence Library

 

Saturday – 22:02 CET

The Turbulence library above can only do shaders which is great but we need a more general noise library now – here is something more useful by Catlike Coding. It has both very detailed explanation and the code.

 

Saturday – 22:34 CET

First outcome of the Perlin noise script. Still need to tune the values but looks promising as a matrix generation tool.

 

Saturday – 23:31 CET

Below is a video showing the influence that the various noise algorithm parameters have over the generated matrix. The two cutoff values split the noise gradient into 3 discrete regions: for the hollow, porous and solid blocks.

 

Sunday – 00:01 CET

Dediced to drop entirely the wanderer mode for this prototype. As we’re discussing what to wrap up for tomorrow we thought the wanderer mode doesn’t really fit in. The crafting mode is probably best off as a standalone game.

 

Sunday – 12:30 CET

A visual helper feature: Now, when the player begins to slide a row, the cubes which block the view of the full row from the camera are hidden. This creates ad-hoc sections of the object, could be used also for “looking into it” by just tapping on the side cubes.

 

Sunday – 13:00 CET

Tried a perspective view with a background plane on which the object to drop a shadow as well as some other setting for the orthographic camera and different colors for the lighting of the scene. Didn’t work as well as hoped so back to the original axonometric projection.

 

Sunday – 13:15 CET

Again feeling worried about gameplay. There are more questions than answers. Maybe as we’re starting to wrap up we can leave these questions for an open discussion with you. With this sliding mechanic we’re using what could be something to challenge you? How to create the feeling of danger or inspire the curiosity?

Let us know if you’ve seen a similar game or you have an idea how to engage the player into sliding more…

 

Sunday – 15:17 CET

Here is a quick sketch how the three types of blocks could look like.

 

Sunday – 16:13 CET

User Inteface (UI). Starting to put in place a basic user interface to be able to switch between the various block types. Unity has a new UI system since version 4.6 and a good resource to get to know its basics when working with buttons is this video.

And this is the video explaining the Text UI object. And a link where to read how to assign text dynamically – in our case we used this to display the moves the player has left.

 

Sunday – 17:25 CET

The interface is now in place. The player can select the type of blocks which they add as they slide a row. They can see how many moves are left and can “buy” (for free) more moves or “3D print”.

 

Sunday – 17:50 CET

We called the result… Slider.

Not sure if it is a game though.

Welcome screen is ready. It shows upon game start and the matrix below is live, procedurally generated.

 

Sunday – 18:15 CET

Handling of 3D printing is quickly hacked together and there is a lot of room for improvements and automation but for a prototype this should work.
When player presses 3D print they are asked to confirm by entering email address and optional message. After that the message together with the “genome” of the current design is emailed to us.

We can then load that genome string into a tool we’ve built for Grasshopper/Rhino. It generates a valid .STL 3D model which can be used for printing at home or with an online service such as Shapeways. The player gets back an email with the STL file. 

A genome string looks like this: [2 0 0 0 1 0 0 1 1 0 0 2 2 0 0 3 1 0 0 4 2 1 0 0 … 2 7 12 4 ]

The data structure is fairly simple: [type x y z]

Type has three possible values: 0 for hollow, 1 porous and 2 for solid.

x, y and z coordinates are integer numbers since each cube is with size of 1 unit.
Here is where we got the code for sending an email from within Unity. This works for standalone releases but not for exporting to webplayer. For release via webplayer we had to use a simple php script that sends an email.

 

Sunday – 18:38 CET

The prototype is ready. Below is a video showing the basic elements of Slider – to call it a game is probably a long-shot, more like and interactive design tool. Ah well. Games that are more fun will hopefully come soon. Until then take a look at the playable demo of Slider and at the first object created with it – a voxel-art-style Bird.

Slider Demo from AWARE on Vimeo.

 

Bird – modelled in Slider from AWARE on Vimeo.

 

Sunday – 19:00 CET

Done!

Hope you’ve enjoyed reading through this log and going through the process with us.

At the end it is important to say we had a lot fun delving deeper in the aspects of game making and looking at new approaches and resources on such a speedy development schedule. It is probably true across the board to say that architects could cope well with the graphics and 3D assets part of game development, in our case, also with the programming part. Our many years of developing parametric and procedural design tools definitely helped with that.

But in terms of gameplay and creating engaging interactions we saw there is still a lot to learn – to let go of geometry and introduce more fun into the game. Game Design is something we definitely wanna know more about.

We would appreciate your feedback in the comments.

And don’t forget to make your favourite game character with Slider and share it with us.