Day: February 13, 2017

Firstly I thought that I would start by getting our ideas onto paper of how want the overall game to plan out. Here are the results:

We needed to get a plan for the how the game navigation will work so I added 4 options; one to go straight into the game, a how to play button, settings and a button which will be linked to the partnering website. On the how to play screen there will be a lot of information on how to play the actual game so like the buttons (w,a,s,d) and alongside them there will be screenshots from in game showing an example. I have added a settings option just in case we need it or not so that is not final as of yet as we me not even need it but it is certainly something to consider.

The next part I have broken down how the game is going to look, for example you can see where text is going to be, where the character is going to be and the obstacles etc.

-Dylan

 

Today Dylan and I decided to theme the player character after a robot with the base idea that robots run off code. With that in mind here are the current designs (and developments).

 

Here we have a basic, brightly coloured, friendly-looking robot. The colours are like this in order to appeal to a young demographic. We didn’t think however that the robot was good enough so we developed the idea further now that we had a starting point.

As you can see I have removed the black outline from all elements of the image so make it seem less harsh and in a way, more friendly. I changed the mouth colour from grey which I think makes the image look better. For more contrast I have changed the arm colour to a light grey so it compliments the other colours well. For the next change I want to focus on the head shape because I feel like it doesn’t do the character many favours or look overly appealing.

 

I like the new head shape but feel as though it is lacking definition and contrast with the other aspects of the face. Dylan suggested I add the secondary colour to the face to get that contrast back and I agree with him so for the next development I will do that.

I have changed the style of the body/torso of the character to resemble that of a screen with code on it (not accurate code, I know – but a symbolisation of code). Dylan and I are still discussing the role of this; whether we want it to be dynamic and change as the game is played to perhaps provide hints to the user, to remain the same and stay as it is, or to be changed completely.

I like the addition to the face and feel like Dylan’s suggestion has done the character a lot of favours. It certainly looks a lot better, more real and more friendly. I am unsure on where I stand with the whole floating aspect of the character. This may be developed to see what it looks like with legs, or developed to have variations of floating. I find though that by the character not having legs it is then easier for us to give it movement in the game because it would have less to do, and less could go wrong, whereas with legs we would have to create multiple ‘moves’ as it were which would be time consuming, and not necessary for the core of the game. This is something Dylan and I will discuss in the days to come.

– Ryan

The aims for the project are to create a platform game that teaches the user to code. The user will control a character, as of right now that character is the robot you will see character development for on this blog.

The game will work like this:

The player runs through the world. Equilibrium is in place, everything appears in order. This part of the game will act as a tutorial for movement. Simple W,A,S,D controls. Just as the player reaches the end of the level it will all fall apart, colour will fade and the equilibrium will be broken. The player character will also malfunction.

The player will then have to reboot the character using code, however the character only reboots in a low-power state. Most of the character’s memory will be scattered across the world for the user to find. The memory will be RAM, as that is very fitting of the situation.

For every piece of RAM the player collects, the character will regain some knowledge. That knowledge will be an element of code, gradually getting more, and more complex.

The RAM is important because the code associated with the RAM will help the player solve the problems they will face in the game. For example; Player picks up RAM and learns brackets “()”. The player will continue in the level to a broken element. By the side of the game will be the code screen. The player will debug the code by adding the brackets they have picked up (A tutorial for this will be in place to set them off). The player fixes the game, gets a reward of some sort and continues.

Later, as the game progresses in difficulty, multiple pieces of RAM, with longer bits of code will be picked up. The player will reach the problem of the level and will now have to think about which piece of code fits. Like a puzzle but the player will have to actively think and solve this problem by using the knowledge they have learned form playing the game.

*A side not here is that when the payer character picks up the RAM, the character will say something along the lines of “That’s great! I now remember (insert code here). This piece of code means this… and when (insert code here) is used, this is possible/can happen.*

The RAM pickup will not be near the problem in the level. This will encourage the player to remember the code and figure out the problem themselves.

We are yet to discuss a points/rewarding system for the game. We want it to be as encouraging as possible, but also rewarding so we want to apply gamification so that the user feels like they are accomplishing tasks as they go. Perhaps things along the lines of:

– Aesthetic rewards
– Points/high scores
– Extra characters
– Bonus levels
– Desktop backgrounds
– Avatars

This is something we will discuss and research.

The target audience for this game is yet to be set in stone, but we will come to it in a later blog post when we have the rest figured out.

– Ryan & Dylan