Hiding

Ages ago I made a post about the idea for a 2D/3D coop platform game. In the game two players share the same game space but they each see it from different viewpoints. They control the movements for the player character together. One player inputs left and right which can be seen in the other players viewport. The other player input up and down again this is only visible in first players view. The combination of co-control and the incomplete view of the game forcing the players to talk or scream to each other to rely the information their co-player lack in their viewpoint to safely navigate through the level.

I keep coming back to ideas for local multiplayer games that utilizes hidden information so I might as well start writing them down.

Semi Coop Maze Runner

An iteration of the 2D/3D coop is a maze-runner game where the two player do not share the same game space but they still control the movement of the player character in the co-players space and not in their own space and share potentially power-ups or downs. 

The top image is player A's screen and the bottom is player B's screen.

In the example above player A sees the screen a the top but her up and down input only affects the player movements on player B's screen seen below and vice versa. So again the players must communicate to get their characters trough the maze without hitting the walls. Picking up or avoiding items is also a combined effort whereas collecting points could be a secret mission for the players making the game semi-cooperative.

Game Mechanic for Non-Color Blind

Another way of hiding information is to play with color. In this mockup all 4 players see the same game space and the same objects are present in the space but each player have their own background color which naturally hides the game object that share that color. 

4 players, same game space, different background color.

Again this could be a collaborative game where the players have to talk to each other to fill in the whole picture. One could also imagine that the players were teamed up in intricate ways making the game competitive.

Whimsical Creatures

Myre & Milton

Playtesting = Game Design

Today I playtested "the mansion game" three times. It's impressive how much changes from one game to the next. Rules are tweaked and in this case the size of the board was almost halved. The result a faster and probably funnier game.

I haven't written the rules down yet. The game is a puzzle game and the mechanics are about movement, shifting the board pieces aka rooms around and moving the character in order to snatch gems. The goal is to be the first to get all the gems in your color. While playing your objective is therefore to rearrange the board so you can move as freely as possible while hopefully limiting your opponents movement.

Two Board Games

Testing the four-player-game with two players

Lately I've been working on making a couple of board games. Well it started with one -a four-player-game but being designed for four I can only playtest when there are four people around with an hour or two to spar. Strangely enough even though I share a flat with four other people it rarely happens that they are here at the same time. So I began developing a second idea that could be playtested with only two people.

To begin with the allure of making a board game is really that it is something I can make on my own (with the brilliant input of playtesters). I find when working on digital games as you can see in the very old previous posts that I get stuck in the scripting part of the process. And then the game mechanic ideas are sidetracked by the fight with the code. Though I actually really like coding I don't seem to be good enough to work my way through to a finish prototype on my own. Board game prototyping could be the way forward. I guess you could just call paper prototyping.

A 2D-3D-co-op platformer

I haven't giving up on the kid game. It's just resting.

In the meantime I've dug up another project. This game idea was born at the Nordic Game Jam and executed as You say Jump? I say How High!. Is a 2D-3D-two-player-co-op platformer where the main focus in the the verbal interaction between the two players playing. Both players control the same character. None of them however have full control. One player sees the character in top view and can move the character up and down. The other player sees the platform from the side and only controls the sideways movement. As both game view are flat 2D view neither of the players have enough information available on their screen to control the character alone. THEY MUST COMMUNICATE!

 This image is suppose to explain the basic game mechanics.

For the game jam we had a crazy set up with one computer and two screens. None of us had touched Unity at that point so we went with bad old flash for developing. It turned out to no ones surprise that it was a difficult task to code what on all accounts except the visuals is a 3D game in a 2D environment. So all in all not the ideal offset for the huge commercial success we all were hoping for ;)

After playing around with iPad I realised how ideal it is for two-player games. So now I'm prototyping the game in Unity.

!++

I let Christoffer be the ++ on the blog. He wrote one post. And then nothing...
So now I have to do something. And so I have. I've made a draft for the graphics for his game.

The style reminds me of drop7 right now but maybe it will get a life of it's own.

Why Not

Playing with size.

Unity Crash Course

This week I attended a lecture series in Unity hosted by ITU. Two nice guys from Unity, Joe and Emil, gave a guide tour through a lot of Unity's features from animation, textures, GUI and editor scripting. They covered tons of stuff and it turned out to be a nice introduction to Unity.

Adding to the greatness of it all was the time given to questions from the audience. I got to ask what was wrong with the sprite sheet animation code since it was giving my this odd graphics problem over time. At first Joe found it just as strange as me but after a trip back to the Unity-factory he could give me the solution.

It turns out the offset float value on the y-axe kept in increase over time. This would be fine if it wasn't for the fact that the float as it increased would be round up thereby constantly increasing in inaccuracy.

Solution: Adding Mathf.Repeat to the offset's x value with the length of 1.
offset.y = Mathf.Repeat(offset.y,1);
This ensures the value every time it goes above 1 is returned to count from 0 instead.

And now it works! Yaaahhhhhh!

Quickie

4 frame animation of someone walking.

New Friends?

I'm a bit jetlagged still from our trip to IndieCade with Copenhagen Game Collective. So this is all I have to share for now - a few new friends.

Sprite Shiit

As I wrote last I've gotten the sprite animation somewhat working and I've even found a good way of making the sprite sheet. But I still haven't found the trick to getting the quality of the images right :(

So to start with the quality seems fine almost anyway as you can see here:

But after a while of running the application the graphics get blurred as you can see in this second screenshot. I have no idea why.

If anyone out there has an idea as to what I'm doing wrong then please comment.

It Moves!

I've got the code for animating sprite sheets working. I had made the mistake of setting a variable as a float instead of an integer. In human lingo this mean I was working with a decimal number where I was supposed to use a "whole" number. I took me a while to figure this out, but by now at least I understand the code I borrowed a lot better.

I changed this:
float index = Time.time*fps;
to this:
int index = (int)(Time.time*fps);

Current screenshot of application:

Everything looks a mess. I'm trying to figure out why my graphics gets pixelated now that I've change to Unity3 and while doing so I've piled graphics in different resolutions.

Talking of Unity3 the mysterious icon issue has been fixed and it's now super easy to add an icon picture under the player settings and best of all - it works!

Damn, Smooth Sliding

Rewriting the code the sprite sheet animation from java script to C# has given me some problems I didn't anticipate. The code simply appears to work differently in C# than in java script. I have two videos that illustrate the difference.

This video shows the right animation but the code is in java script:

Here the similar code is rewritten in C# as you will see the sprite sheet just slides at an angle instead of jumping picture by picture:

Here's the original java script code:

//vars for the whole sheet
var colCount    : int =  4;
var rowCount    : int =  1;


//vars for animation
var rowNumber   : int =  0; //Zero Indexed
var colNumber   : int =  0; //Zero Indexed
var totalCells  : int =  4;
var fps  : int = 10;
var offset  : Vector2;  //Maybe this should be a private var


//Update
function Update () { SetSpriteAnimation(colCount,rowCount,rowNumber,colNumber,totalCells,fps);  }


//SetSpriteAnimation
function SetSpriteAnimation(colCount : int,rowCount : int,rowNumber : int,colNumber : int,totalCells : int,fps : int){


    // Calculate index
    var index : int = Time.time * fps;
    // Repeat when exhausting all cells
    index = index % totalCells;
    
    // Size of every cell
    var size = Vector2 (1.0 / colCount, 1.0 / rowCount);
    
    // split into horizontal and vertical index
    var uIndex = index % colCount;
    var vIndex = index / colCount;

    // build offset
    // v coordinate is the bottom of the image in opengl so we need to invert.
    offset = Vector2 ((uIndex+colNumber) * size.x, (1.0 - size.y) - (vIndex+rowNumber) * size.y);
    
    renderer.material.SetTextureOffset ("_MainTex", offset);
    renderer.material.SetTextureScale  ("_MainTex", size);
}


And the code in my C# version:

using UnityEngine;
using System.Collections;


public class Animation_sprite_sheet : MonoBehaviour {
//vars for the whole sheet
public int colCount =  4;
public int rowCount =  1;

//vars for animation
public int rowNumber = 0; //Zero Indexed
public int colNumber = 0; //Zero Indexed
public int totalCells = 4;
public int fps = 10;
Vector2 offset;  //Maybe this should be a private var


// Use this for initialization
void Start () {
}

// Update is called once per frame
void Update () {
SetSpriteAnimation(colCount,rowCount,rowNumber,colNumber,totalCells,fps);
}
//SetSpriteAnimation
public void SetSpriteAnimation( int colCount, int rowCount, int rowNumber, int colNumber, int totalCells, int fps){
// Calculate index
     float index = Time.time * fps;
    
// Repeat when exhausting all cells
     index = index % totalCells;
    
   // Size of every cell
     Vector2 size = new Vector2 ((1.0f / colCount), (1.0f / rowCount));
    
     // split into horizontal and vertical index
   float uIndex = index % colCount;
     float vIndex = index / colCount;

     // build offset
     // v coordinate is the bottom of the image in opengl so we need to invert.
     Vector2 offset = new Vector2 ((uIndex+colNumber) * size.x, ((1.0f - size.y) - (vIndex+rowNumber) * size.y));
    
     renderer.material.SetTextureOffset ("_MainTex", offset);
     renderer.material.SetTextureScale  ("_MainTex", size);
}
}

As all the examples I can find in unity's documentation and around the internet on unity are mostly in java script I often find myself being lost when it comes to using C# in unity.

Power of Two

I'm slowly starting to figure out how I can add graphics to the game. Basically I'm getting tired of the green, red and blue squares. So now I'll go for red, yellow(!) and green blinking circles instead.

I'll be working with sprite sheets for the animation. So far I've managed to get a clumsy animation running on the iPad by using a piece of java script I borrowed from the Unity community wiki. But I want to work in C# so now I have to rewrite it.

Oh and the "power of two"-title refers to the fact that in order to get nice graphics on the iPad I have to remember to use image sizes that are a power of two e.g. 256 x 1024.

Hello!

Hi, I'm Christoffer,

Benedikte and I are travelling together at the moment- we're going to IndieCade with our friends from the Copenhagen Game Collective - and I've been invited to guest write for the next couple of weeks. So for a short while it'll be GameByOne++. Right now we're in San Francisco.

Well, while Benedikte has been working on the Kids game, I've been trying to make a prototype of a little game that's about chain reactions. It's based on a concept of interconnected nodes with different abilities and you have to send energy between them. The game is aimed for the iPhone right now, so I'm also working in Unity.

More on this later - first to the important stuff: Since Benedikte made such a nice picture of herself, I also drew a self-portrait - that's me up there. You may notice that I am almost as good with graphics as Benedikte is, ahem.

Also, here's a very early prototype screen shot:

OK, see you later.

Out of Order

I've run into a problem. When I build and run the application it just shuts down right after showing the Unity icon. The console gives me this information:

The internet tells me I should reinstall everything - Unity, XCode and my mobile provisioning files :( 3-4GB download. Yay.

Keeping Their Distance

I've refined the code that determines the placement of the kids. Now the code ensures that the kids aren't placed to close. Every kid placed after the first one is checked for whether or not they are in the vicinity of any of the kids that have already been placed.

Here's a bit of code:
public bool DistanceCheck()
{
disCheck = false;

for(int i=0; i<antal-1;i++)
{
if ( ((kids[i].transform.position.x-temp.transform.position.x)*(kids[i].transform.position.x-temp.transform.position.x)) + ((kids[i].transform.position.y-temp.transform.position.y)*(kids[i].transform.position.y-temp.transform.position.y)) < 200)
{
disCheck = true;
}
}
return disCheck;
}

And a video with the latest improvement:

To sum up, reds are crying, blues are about to and green kids are okay for now. When the crying kids are tapped they turn happy (no paedophile thoughts intended).

Touchy Success

Finally the touch input is working. I thought I would be able to "talk" directly to a method on a game object from another class e.g. objectname.method. I have now realised that I needed to use the method getComponent() to access the methods of the objects. This has taken forever to realise. But now the code works! It needs refining but it works.

When I touch the screen a ray is sent along the z-axis into the 3d space (world space I guess). Whatever the ray collides with is "registered" in the raycast method's collider. Assuming the object the the ray collides with is an Kid object I can then access the methods in the kid and change it's state.

When (0,0,0) is not (0,0,0)...

I'm working on "refining" the touch function so that a kid can sense if is being touched.
All this is probably really easy but as I'm a n00b in unity even the basic stuff is difficult. The idea is that if you touch the screen on the ipad and the coordinates of your touch matches the coordinates matches a kid-object then the kid should do something.

My problem is a can't get the coordinate system of the ipad to match the one in the unity editor. I sure it something really simple I'm missing but I can't figure it out so I've taken it to the extremes - I've posted for the first time in the unity community help forum.