Building SOT part 6: the switch

Changing perspective 

I'll be moving to a side scroller, 2.5d point & click game, which will still use the gyroscope to execute the world-switch mechanic, but in a much more comfortable and accessible way.

I've talked to some people.

Basically I've hit a point where I'm noticing that, after playing for longer than 2 minutes, the player becomes uncomfortable. The strain of having to stand up and move the phone around is not contributing to the game.

To check this I went and talked to some people who were hanging round about their gaming habits in mobile games. These people include Master students in game design and interaction design, as well as some first-year game students.

Notes from the first year discussion. Impressive, I know.

Here are the results:
There are two types:

• The people who play games for a longer time, 30+ min/session.
• These people like games that offer a more intense experience. They are usually home when playing.
• The people who play while waiting for something else to happen, +- 10 min/session. 
• These people prefer a "no-brainer" experience, as a distraction. Examples were waiting for the bus, being on the toilet, while the pc or console is experiencing difficulties.

The use of gyroscope controls as intensive as what SoT would have been is not desired and breaks with the environments in which mobile games are being played.

Building SOT part 5

Building SOT part 5: Graphical Upgrades 

 

A test with sunbeams and one with a spherical edge to the upper world view.

The circular window is achieved by making a sphere, inverting the normals and cutting a hole. The camera then sees and renders the inside of the sphere as the skybox, and looks through the hole to display the other character.

The sphere then gets rendered by the second camera, but not the first one. Also, it's upside-down because of how the camera is oriented and mirrored, so that's fun.

Building SOT part 2

Mirror effect

After experimenting with a few mirror effects using a second camera projected on a plane I've arrived at this:

This was achieved by using two camera's, one mirroring the movements of the other in relation to the mirrored world. Then I've used the camera depth and culling mask to overlay the main camera's image over the mirror camera's image.

Performance on my phone seems fine, and hits over 60 fps when only rendering the terrain. Adding the trees as seen in the .gif makes it drop to ~40 fps. Seeing as how we're making a point & click I'll be happy as long as we hit 30+ fps, so we're good.

Now to re-implement the world switch mechanics.

Building SOT part 2

World creation: Part 2

Using Unity terrain

Unity terrain can't be rotated, and as such can't be made to be upside-down; Something which I need for SOT. As such I want to render a mirror world using a second camera.

Attempt  #1: Using RenderTexture

 

This method uses a plane and a texture created by an orthographic camera above the world. The performance is fine on mobile, but the downside is that the reflection looks incredibly flat. Maybe I should experiment with a non-orthographic camera?

 

 

 

 

 

 

Attempt #2 Using a mirrored camera & viewport editing.

 

As you can see in the gif above, this looks pretty cool, but I'd have to fix the scaling issue that happens due to the width and height relation.

The solution will probably involve a combination of the two, having the mirror camera from #2 and rendering it on a plane like #1.

Exploring options on how to build the world of "Two's".

World creation: Part 1 

Trying to figure out a way to build the world of for "A Story of Two's", on a technical level, is a challenge mostly due to the dual-world gameplay. As the player must be able to switch between characters at will in an open-world loading and unloading would be a challenge, but also the fact that world worlds must be visible by looking up or down respectively.

Chunk-based loading

 

The first that I came up with was a system of 13x13 chunks, 50x50  units each, in which only the chunks that the characters occupied would be loaded, together with the neighbouring chunks.

This would mean that, out of the 169 possible chunks, a max of 18 would be loaded in (one occupied and 8 neighbouring for each playable character), which would save on performance but dramatically reduce draw distance.

Another advantage is that you could swap out specific chunks to change the content of the map based on a timeline or certain triggers in the world, which would make a dynamic and seamlessly transition between world-states. Puzzle chunks would be loaded in, and when they would be reloaded they might get replaced by a different puzzle.

Problems like the draw distance are issues, but that might be resolved using very low-poly representations for far-away chunks. What will be the biggest problem would be creating each world chunk.

Custom Unity editor window

 

 

To save having to manually drag and load each chunk form a list I've made custom editor window with a 13 x 13 grid of buttons, each linked to a scene. Each scene then contains a chunk, and the buttons show when a chunk is loaded in or not. This greatly increases the in-unity workflow.

 

Chunk editing and level design in Blender

 

In order to make and export chunks in blender they each need to be separate object, but also need to seamlessly mech in each other. Enter MultiEdit by antoni4040. What this allows is for each object mesh to be edited simultaneously, and so I can make chunks of flat planes and create mountains and rivers spanning multiple chunks.

However, and I'll be honest, managing each separate chunk afterwards is a pain. Keeping track of each one takes up most of the time. I want to minimise the amount of work in this step, so better to completely design the world first and only start building it later.

Using Slack in a very small team.

In preparation for the master we, Sarah and I, have been using slack as our main communications platform. This, as it turns out, has been incredibly helpful, due to the app integration.

Also I didn't want to use facebook chat. Not for "official" business.

Basically, I've set it up so that Trello, BitBucket and Google Calendar are all linked to Slack, and send activity logs to different channels. This makes sure that both of us know exactly what is going on at all times, and that makes communication a lot easier. No need to ask someone to do something, or when a deadline is due, just go to the appropriate channel and see if it's there. Whenever something happens I get a notification.

For example: Sarah pushes an update to BitBucket and moves a task from "To Do" to "In Progress" on Trello. I get immediate notifications from slack that these things are happening, and, without exchanging a word, I know Sarah has finished something and started work on another.

However, it's not just about real-time updates, but also keeping a log of things. This is so that we, in a years time, can look back and show exactly what we did at which point in time, what we discussed during meetings, which builds were shared,... pretty much everting. This can be used during presentations or to show people who would be interested in our creative process.

Using twine for text based games.

 

Complete passage structure.

PLAY THE GAME HERE

The cool thing about twine, that I've noticed, is that it's got plenty of coding potential. This was mostly to explore these possibilities. Below you can see some of the structure involved.

A randomly generated passage.

Adapted from the story written for the storytelling cource, which you can find here:

Go to the full story.