I had to think of something? Sleeping until 7 and didn’t help, food and a shower.. Now an idea started to form. The void ship from the Dr. Who series and the hunt for the Maquis from Star Trek, void ship = between worlds,  hunt for the Maquis = turbulent and violent space.. hmmm. To the blackboard, and draw 3D, draw 2.5D, ok then 2d.. Couldn’t figure out how I wanted the game to look, as I would like to do it in 2d (haven’t done 3d since unity came out with their 2d support), I just couldn’t squash the 3D into 2D.

Remembering that I only had 48 hours and 5 was gone sleeping, eating and showering already. I had to keep it simple. So why not having two universes, one on top of the screen and one on the bottom, and having to fight invaders from the other universe. So I set out to do so.

What I have ended up with is almost that. Only change is that the enemy ships are wormhole generators that you have to shoot down before they can open a wormhole, and there by destroying the other universe (I have allowed myself some freedoms as I do not know how wormhole from a universe with other lawn of nature would impact our universe or it’s even possible).

You can play the game Join Us! online, or download the PC version here.

Learned a lot, especially not to optimize as much as I do. I have done some things where I thought, this will be slow, but it’s micro seconds, so doesn’t matter. Ended up with at most 10 draw calls which is nothing. Now I have uploaded the PC version and the web version to Ludum Dare I don’t really wan’t to work on it any more, I’m mentally tired and just want to relax and not think about “Join Us!” anymore,  for now…

It’s been fun and amazing to see how much you can do, when you don’t focus on having to deliver something amazing and super polished, but just a game someone would enjoy So hope you will play it, enjoy it, and rate it on Ludum Dare.

Now, go make games

– Henning

After only a week and not much time to look into Unity 2D I must say that I don’t think I’ll ever look at another game engine ever again The 2D workflow, sprite importer, animator, ordering layer and so on, just makes everything SO easy. I’m simply blown away.

I have so many options now, that I don’t know what game to start making, which i great Now I just have to finde the time to make it all happen..

If you don’t have allready, go download Unity 4.3….  To get started take at look at 2D Game Development Walkthrough.. Unity 2D RULES!!

Have fun and go make games!

– Henning

I’ve spend some time making the basic stuff for a 2D game using Unity. Forcing Unity to make a 2D game have been a challenge, It works but I’ve spend a lot of time handling sprite sheet, animation and other standard stuff and not on the actual game. Then by pure coincident I saw someone mentioning Stencyl on spiludvikling.dk so I took a look, and if version 3.0 keeps it promises I guess I’ll be doing all my 2D games in Stencyl. Only thing about Stencyl I don’t like is the missing possibility to use C# and the still missing Android support But for now it’s so easy to use, that I’ll gladly learn Scratch and objective C.
Now that Unity version 4.3 is out, I’ll have to try it out to see if it’s as easy as they say, and if it is, I might switch back. If not, I’ll save Unity for my 3D needs

Have fun! Now go make games!

– Henning

Asking Google I found three possible things, that could be the problem.

1. When creating my mesh I set mainTextureOffset and mainTextureScale.
2. My sprites use the build in transparent shader, which apperently could also kill the dynamic batching.
3. I set the material for all meshes to my spriteatlas texture. Not using shared materials.

The Code is as follows.

public static GameObject CreateSprite(float x, float y, float width, float height, float scale, Material material)
    {
        y = materialHeight - y;
        float uvWidthUnit = 1f / materialWidth;
        float uvHeightUnit = 1f / materialHeight;

        float vertHeightScale = scale * (height / width);

        Mesh mesh = new Mesh();

        Vector3[] verts = new Vector3[4];
        Vector2[] uvs = new Vector2[4];
        int[] tris = new int[6] { 0, 1, 2, 2, 1, 3 };

        verts[0] = -Vector3.right * scale + Vector3.up * vertHeightScale;
        verts[1] = Vector3.right * scale + Vector3.up * vertHeightScale;
        verts[2] = -Vector3.right * scale - Vector3.up * vertHeightScale;
        verts[3] = Vector3.right * scale - Vector3.up * vertHeightScale;

        uvs[0] = new Vector2(0.0f, 1.0f);
        uvs[1] = new Vector2(1.0f, 1.0f);
        uvs[2] = new Vector2(0.0f, 0.0f);
        uvs[3] = new Vector2(1.0f, 0.0f);

        mesh.vertices = verts;
        mesh.triangles = tris;
        mesh.uv = uvs;

        mesh.RecalculateNormals();

        GameObject newMeshObject = new GameObject();
        newMeshObject.AddComponent<MeshFilter>().mesh = mesh;
        newMeshObject.AddComponent<MeshRenderer>();
        newMeshObject.renderer.material = material;
        newMeshObject.renderer.material.mainTextureOffset = new Vector2(uvWidthUnit * x, uvHeightUnit * y);
        newMeshObject.renderer.material.mainTextureScale = new Vector2(uvWidthUnit * width, uvWidthUnit * height);
        newMeshObject.AddComponent<BoxCollider>();
        Vector3 boxColliderSize = newMeshObject.GetComponent<BoxCollider>().size;
        boxColliderSize.z = 0.1f;
        newMeshObject.GetComponent<BoxCollider>().size = boxColliderSize;
        newMeshObject.AddComponent<Rigidbody>();
        Rigidbody rigidbody = newMeshObject.GetComponent<Rigidbody>();
        rigidbody.constraints = RigidbodyConstraints.FreezeAll;
        newMeshObject.isStatic = true;
        return newMeshObject;
    }

So first I tried setting UV for the vertices instead of changing mainTextureOffset and mainTextureScale. For the first test I just removed the two lines, to see if the number of draw calls decreased.

The number of draw calls, on my main game screen, went down from 42 to 9 (I have some GUI taking up some calls).. And when I started shooting, a lot, the number of draw calls stayed solid at 9. So a real improvement. Of cause now I had to test if changing the UV coordinates for each frame changes anything…. It didn’t effect the number of draw calls This post from the Unity Forum says it all. So modifying mainTextureOffset and mainTextureScale is not the way to do it!  So no more testing, the UV way of doing things must be the way to go.

[ExecuteInEditMode]
public class UVSetter : MonoBehaviour
{

    public float pixX;
    public float pixY;
    public float pixW;
    public float pixH;
    public float matrialSizeX;
    public float matrialSizeY;
    private Mesh theMesh;
    public bool updatable;
    // Use this for initialization
    void Start()
    {
        theMesh = transform.GetComponent<MeshFilter>().mesh;

        float uvx = pixX / matrialSizeX;
        float uvy = 1f - (pixY / matrialSizeY);
        float uvw = pixW / matrialSizeX;
        float uvh = pixH / matrialSizeY;

        Vector2[] newUVs = new Vector2[4];
        newUVs[0] = new Vector2(uvx, uvy);
        newUVs[3] = new Vector2(uvx, uvy + uvh);
        newUVs[2] = new Vector2(uvx + uvw, uvy);
        newUVs[1] = new Vector2(uvx + uvw, uvy + uvh);
        theMesh.uv = newUVs;
    }

    // Update is called once per frame
    void Update()
    {
        if (!updatable)
        {
            return; 
        }
        float uvx = pixX / matrialSizeX;
        float uvy = 1f - (pixY / matrialSizeY);
        float uvw = pixW / matrialSizeX;
        float uvh = pixH / matrialSizeY;

        Vector2[] newUVs = new Vector2[4];
        newUVs[0] = new Vector2(uvx, uvy);
        newUVs[3] = new Vector2(uvx, uvy + uvh);
        newUVs[2] = new Vector2(uvx + uvw, uvy);
        newUVs[1] = new Vector2(uvx + uvw, uvy + uvh);
        theMesh.uv = newUVs;
    }
}

On a final note I just want to mention that, to get the editor to show the correct UV in the editor, I just added [ExecuteInEditMode] decoration to my UVSetter test class..

Now, go make games!

– Henning

Now, go and make games!

– Henning

private shieldFingerId = -1;

...
// If nothing is touched, the shield controller has been released
// Know I should test for the shieldFingerId to be released, but this works for my purpose.
if (Input.touchCount == 0)
{
	shieldFingerId = -1;
}

foreach (Touch touch in Input.touches)
{
	// Fire
	if(touch.phase == TouchPhase.Began && !withinShieldController)
	{
		Fire();
	}

	// "Grap" shield
	if (touch.phase == TouchPhase.Began && withinShieldController)
	{
		shieldFingerId = touch.fingerId;
		UpdateSheldAngle(touch.position);
	}

	// Move shield
	if (touch.phase == TouchPhase.Moved && touch.fingerId == shieldFingerId)
	{
		UpdateSheldAngle(touch.position);
	}
}

As you can see, when I got hold of the information about touch.phase and .fingerId, everything turned out to be very simple indeed.

I found the Unity Script Reference pages to be very limited on the subject of touch input, e.g. information about touch.fingerId only says “The unique index for touch.” no examples, or explanation. But by asking Google, and searching the Unity forums, great resource I might add, it finally made sense.

Working with touch has forced me to use my LG E975 mobile for testing, which is a slow process. :/ I guess I have to figure out how to make Unity Remote work with my phone. If not, development is going to take forever!

Hope the above code makes sense? Now go make games!

– Henning

Not something I will ever forget to do ever, ever, ever again.. So now everything works, and the game is really starting to take shape. The audio is still horrible, and the gameplay needs some adjustment, whats to add time bonus/limits, but I really like what the game is morphing into.

I have only one android device, so I’m looking forward to having friends test it on their devices, to see if there are problems with the different resolutions and aspect ratios. Which has really given me a lot of headaches, and maybe for nothing.. It have been a lot easier to work with, now that I’ve started using rich text in all my GUI text. It all looks good in unity, but you never know what might pop up on strange devices

Now go make games!

– Henning

The progress of the development of 3×3.

Hope you’ll enjoy it too. 3×3 Final version.

– Henning

• I have opened the sides of the tunnel and added some stars to get away from the very claustrophobic feel.
• I added a single power up in form of the ability to remove an entire wall. The power ups spawn every 10 to 20 seconds and they stack.
• The biggest change is the textures of the boxes. I really spend a lot of time trying different textures, shapes and colors, still I’m not 100% satisfied, but I think it’s better than before.

If anyone would like to do some textures for the game, feel free to contact me, I’m sure you could do better than what I ended up with

One thing suggested that I would have liked to include, was an idea to have the tunnel twist and turn. But as this was never the intention, the code would have to be rewritten from the ground up. So this will, if ever, have to wait to future project.

Play version 10. Enjoy and please send feedback.

– Henning

I have used the last days to add a lot of small things to the game, tweaking it, and playing it, again and again. I also had a friend play it, a lot, to see if I missed something obvious.

Here’s a list of what I have done.

• Added particle effect for the box explosions.
• Updated sound effects.
• Added Gui Skin
• Added Font
• Changed resolution to 1024×768.
• Player control, motion can now be changed in mid move.
• Collider made smaller for when player is rotating.
• Added Crash SFX
• Updated Move class to separate horizontal and vertical movement to allow diagonal movement.
• Added 10000/15000/20000 points SFX
• Added level 10/15/20 SFX
  
• Added Audiosource mini buffer to hold 4 audio sources.
• Adjusted colors of boxes to make them easier to distinguish.
• Added plane to slowly revile the boxes, and not just pop into existence in the back of the scene.
• Updated all level and point SFX.
• Adjusted music slowdown to 0.75 instead of 0.5 when dead.
• Changed font to Plasmatica by Apostrophic Labs.
• Adjusted GUI boxes to match the new font

The best update, is the ability to move freely, and in all directions. I thought this would be a pain to make work as I wanted, but with a few changes to the already existing moving class, and the separation of horizontal and vertical movement, it was surprisingly easy.

One thing I didn’t expect to give me any problems was the colors of the boxes, but as I tried to make the colors easier  to distinguish from each other, the bigger problems I got with the lighting settings. First the scene was overlit when the boxes came close to the spot close to the player,  then under lit. Then the ambient light made everything look flat, and so on. So I ended up spending almost 3 hours adjusting colors and light settings. But I’m finally happy with the result.

After I added more sound effects I found that they would cut off each other, so I added a mini buffer, to hold 4 audio sources and use the first available. This gave a hole new, and more complete feel, to the game.

Hope you enjoy the game And have time to send me some feedback.

– Henning