Generate random dungeons with tiles

I have started a new series which discusses generation of random dungeon. I will release it as open source when it’s more “done” 🙂 … http://www.fourtwo.se/Tags/Generating%20dungeons

Blow him up! games page

I have created a game page for Blow him up! on my new site. http://www.fourtwo.se/games/all/blow-him-up

Moving my blog

I’ve moved my blog to http://games.fourtwo.se/ … so head over there for news and updates!

Blow him up! released and waiting for update

Well, it’s been a budy few weeks. Blow him up! finally got accepted and I have started developing my next game. The next game faces a few challanges since I’ve rewritten how the graphics is done completly. I need to redesign my whole control-library, but it’s fun. It’ll be better and that’s what’s important.

The first week I didn’t get many sales, but that was expected. I fucked up by changing the release date AFTER my app had been accepted and a date had been set, so my game didn’t get any spotlight at all in the “New” section. Well, now I know better. The last 4 days sales has gone up and I’m not quite sure why. Unfortunatly it seems like many players doesn’t understand how to play and I have to make a more extesive guide. I’ll do this as HTML and make a link to it in the game. I really do want everyone who has bought it to enjoy it since everyone that I’ve talked to have said that it’s really fun.

I had some issues with the application loaded. The function to make a zip form within MonoDevelop didn’t work for me, but in the end I just had to zip up the binaries located in the bin-folder.

If you would like to check it out, just head over to Blow him up! on App Store.

VertexDeclaration for XNATouch / MonoGame

This is a helper I created to use VertexDeclaration from XNA to openGLES.

GLStateManager is a manager that remembers what modes that have been set so they don’t need to be overly initialized. I don’t know if it saves any performance, but I sure hope so. The IntPtr arrayStart is a pointer to the array of Vertices in memory. Like VertexPositionColor[] vertices.

The IntPtr can be gotten by using IntPtr arrayStart = GCHandle.Alloc(vertexData, GCHandleType.Pinned).AddrOfPinnedObject();

Prepare vertices for use

using All11 = OpenTK.Graphics.ES11.All;
using GL11 = OpenTK.Graphics.ES11.GL;

        public static void PrepareForUse(VertexDeclaration vd, IntPtr arrayStart)
        {
            GLStateManager.VertexArray(true);

            bool normal = false;
            bool color = false;
            bool texcoord = false;

            foreach (var ve in vd.GetVertexElements())
            {
                    switch (ve.VertexElementUsage)
                    {
                        case VertexElementUsage.Position:
                            GL11.VertexPointer(
                                ve.VertexElementFormat.OpenGLNumberOfElements(),
                                ve.VertexElementFormat.OpenGLValueType(),
                                vd.VertexStride,
                                new IntPtr(arrayStart.ToInt32() + ve.Offset)
                                );
                            break;
                        case VertexElementUsage.Color:
                            GL11.ColorPointer(
                                ve.VertexElementFormat.OpenGLNumberOfElements(),
                                ve.VertexElementFormat.OpenGLValueType(),
                                vd.VertexStride,
                                new IntPtr(arrayStart.ToInt32() + ve.Offset)
                                );
                            color = true;
                            break;
                        case VertexElementUsage.Normal:
                            GL11.NormalPointer(
                                ve.VertexElementFormat.OpenGLValueType(),
                                vd.VertexStride,
                                new IntPtr(arrayStart.ToInt32() + ve.Offset)
                                );
                            normal = true;
                            break;
                        case VertexElementUsage.TextureCoordinate:
                            GL11.TexCoordPointer(
                                ve.VertexElementFormat.OpenGLNumberOfElements(),
                                ve.VertexElementFormat.OpenGLValueType(),
                                vd.VertexStride,
                                new IntPtr(arrayStart.ToInt32() + ve.Offset)
                                );
                            texcoord = true;
                            break;
                        default:
                            throw new NotImplementedException();
                    }
            }

            GLStateManager.TextureCoordArray(texcoord);
            GLStateManager.ColorArray(color);
            GLStateManager.NormalArray(normal);
        }

        public static int OpenGLNumberOfElements(this VertexElementFormat elementFormat)
        {
            switch (elementFormat)
            {
                case VertexElementFormat.Single:
                    throw new NotImplementedException();

                case VertexElementFormat.Vector2:
                    return 2;

                case VertexElementFormat.Vector3:
                    return 3;

                case VertexElementFormat.Vector4:
                    return 4;

                case VertexElementFormat.Color:
                    return 4;

                case VertexElementFormat.Byte4:
                    return 4;

                case VertexElementFormat.Short2:
                    return 2;

                case VertexElementFormat.Short4:
                    return 2;

                case VertexElementFormat.NormalizedShort2:
                    return 2;

                case VertexElementFormat.NormalizedShort4:
                    return 4;

                case VertexElementFormat.HalfVector2:
                    return 2;

                case VertexElementFormat.HalfVector4:
                    return 4;
            }

            throw new NotImplementedException();
        }

        public static All11 OpenGLValueType(this VertexElementFormat elementFormat)
        {
            switch (elementFormat)
            {
                case VertexElementFormat.Single:
                    throw new NotImplementedException();

                case VertexElementFormat.Vector2:
                    return All11.Float;

                case VertexElementFormat.Vector3:
                    return All11.Float;

                case VertexElementFormat.Vector4:
                    return All11.Float;

                case VertexElementFormat.Color:
                    return All11.UnsignedByte;

                case VertexElementFormat.Byte4:
                    return All11.UnsignedByte;

                case VertexElementFormat.Short2:
                    return All11.UnsignedShort;

                case VertexElementFormat.Short4:
                    return All11.UnsignedShort;

                case VertexElementFormat.NormalizedShort2:
                    return All11.UnsignedShort;

                case VertexElementFormat.NormalizedShort4:
                    return All11.UnsignedShort;

                case VertexElementFormat.HalfVector2:
                    return All11.Float;

                case VertexElementFormat.HalfVector4:
                    return All11.Float;
            }

            throw new NotImplementedException();
        }

Tips on making your own game

This is my experience so far on making and releasing your own game. There’s more to it than just writing code. It’s about how you write it and what not to write. And it’s about having a good base to stand on to save time. We want to reach the finish line some day. You have a finite amount of time in this life, why waste it. It’s the only resource of which you cannot get more.

Get shit done

A very important principle is getting shit done. That means that you focus on the goal of getting your game released instead of creating vast structures that will be able to host whatever game within it. Start small! ONLY add support for stuff that you need. You NEVER know if you will need it in the future or if you really need it in the form you’re thinking of right now. Everything evolves and your thoughts evolve alot. Write list of all of your known issues and what you need to do to get the game done. And try to estimate every point on that list. Then tripple the estimation 🙂 … Know you know what to expect. This can save you from getting bored or frustrated that it’ll never get done.

Start small and escalate

We all have that magnificent game we want to make that is so epic. There’s a reason big game studios have hundreds of employees and it is that it takes time. And to embark on a bigass project directly ain’t good. I’ve tried it so many times, got bored and lost my entusiasm. Having alot of half-finished games in my bag. Start on a small game, add support for stuff, make a bigger, add more support and refine the last framework. And do this again and again. Soon you will have a really good base to stand on for the bigger games.

Wrappers

I like having modules in my framework. Something that handles Content, a common way to handle elements in my UI, etc etc. Often I just create a class for the module which just forwards calls from another module. Like the ContentManager in Xna. It loads various resources from the disc with Load<T>(assetName). Let’s say you don’t really need any fancy resourcehandling right now or just want to get started fast on your game and “get shit done”. Then just make a class that wraps that wraps the other class and forwards the calls. And make an interface for all the methods aswell.

Why would you make this? It just slows the game down with the extra calls. Well, it’s because you just made a layer between the calls of the ContentManager and you main game logic. If you want to load and unload resources, merge textures or whatever, you can manage this within your wrapper in the future and don’t need to hassle to rewrite all the code you’ve put into the main game logic. And if you need to extend your game ot multiple platforms, it’s easy to create a new class implementing the interface. This is very useful for storage scenarios and sql on different platforms. Like iPhone, wp7 and android.

Examples

• Texture manager
• Sound manager
• Storage
• Scene management
• General highscore module
• Graphical UI game components
• Text management
• Particle system
• Popups, alerts, controls

Scenes views and overlays

A scene can be described as a view. The main manu of a game is a view. And the stage in a platformer is a view. Or in my words, a scene. This is nothing new, but it still is revolutionary if you havn’t thought of them before. I think of the view as a main view, which can contain a various amount of overlays. Let’s say you’re at the main menu. You click highscores and a board pops up. This is a scene overlay. It blocks all touches from triggering stuff on the main menu since you should only be able to interact with the highscores. So we add an highscore overlay. Well, we can only see the local highscores. To see your friends, we must query the server. We decide we want a button that checks at what place we are compared to out friends. When we click the button, we add a new overlay which displays this number. So now we have a scene, with two overlays. Each overlay blocking the previous from handling touches.

Get scenes, they simplify sooooo much. You always start making your game logic, testing it and when you come far enough you start noticing the need for a main menu, high score, game over view, lan game view, etc.

UI Controls

Ahh, a very fine component this is and to be fair, it’s not trivial at all. Unless you make it trivial. This is an area where alot of time can be put in and nothing will come out at the other end. You want the panels, scrolling panels, textboxes, labels, buttons bla bla bla. I can’t stress this enough for this component, KEEP IT SIMPLE and EVOLVE SLOWLY 🙂 … Get shit done!

There’s so much dependencies possible to implement. Margins, padding, justification, alignments, etc. If you calculate positions every frame, it will always be drawn correctly, but you might get performance issues on platforms that aren’t very powerful (i.e Mobile platforms). No use wasting clockcycles. I would recommend you implement some sort of life cycle with intialization, positioning, etc. And if you change the layout at runtime, Invalidate() the structure and calculate new positions and sizes. Once 🙂

A good post about building game engines: Built here? No, thanks by Bernat Muñoz

Multi platform scaling issues

Well, I’m still waiting for the approval of my game @ app store. I submitted it 5 days ago, but alas, it takes about 6 workdays before it’s reviewed. So, we’ll see what happens. I really hope it gets accepted so I can take some time to move to my new framework for iPhone and get going on some new games.

The scaling issue

There are different resolutions on the phones. I could use the screenwidth as ratio to scale all graphical object, therefore I don’t the graphics in different resolutions, I can just use bitmaps for the highest resolution and scale them down for those with lesser. The platforms I’m targetting have 320, 480 and 640 in width. This approach works, but it’s not optimal when doing pixel graphics. I use the width since my game is in portrait mode, but I think I’ll stick with the width for calculating ratios since this is the common ground in my point of view. So things get updated at the same rate on all platforms. One problem with my approach is that I calculate the scale for objects every time I’m drawing an item on the screen. That leads to alot more floating point operations than needed. And that’s not anything you want to do on the iPhone. I could just as easily just scale them once at creation. My bad 🙂

I do alot of other scaling calculations in the code over and over again. I should be able to calculate all those constans in the current scene when creating it.

Rewriting it

I’m saving all my textures now with the screendimensions appended at the end. They get merged based on their resolution so I don’t load anything that I don’t need. All merged textures are grouped by the scene they belong to and I also have a “shared” library with fonts, etc, which are used by most scenes. So common names for the textures are “merged-main1.480×800.png” and “merged-game4.320×480”, etc.

I have found that my framework works on WP7, it was pretty well written from the start. I even have a control-library for Panels, Scrollings Panels, Buttons, TextBlock, TextureButtons, Images, etc. So, it’s working out pretty good.

Better performance with XNATouch

Well, as most ppl know, there are some performance issues with XNATouch right now. These can be circumvented somewhat.

SpriteFonts

SpriteFonts load very slow, this is due to the format the Texture2D is in when it’s loaded. You can circumvent this with this post.

Merge textures

Since the SpriteBatch has been rewritten, it’s much faster. To improve loading speeds, you should merge you textures (.png/.jpg/etc) together in bigger files. Up to 1024*1024 pixels. This will also improve drawing speed since the object/vertex-buffer will be drawn whenever the framework wants to use a new texture.
So … If your Draw() looks like something like this

public pseudo Draw()
{
spriteBatch.Draw(alot of background sprites);
spriteBatch.Draw(alot of different platforms);
spriteBatch.Draw(alot of enemies);
spriteBatch.Draw(player sprites);
spriteBatch.Draw(more foreground sprites);
}

Then you should merge the textures in that order. First all background, if there’s more space in it, merge in the platforms and so on. You shouldn’t split a set (like all platforms OR all enemies) into separate textures since the SpriteBatch will have to load Texture1 when it needs to draw the platform of type A and B, and then jump to Texture2 for type C and D, and then jump back to draw one of type A again. Yeah, you get my drift.

Save resources, avoid garbage collection

Instead of storing all data and game logic inside objects which you create and throw away after they have been used you can create fixed size arrays which holds data for your elements/sprites/game objects.

I used to new Platform() every time I put out a new platform on screen. Now I have a dictionary of the different types of Platforms and it only contains the code needed to Update and Draw the platforms. All the data have been moved out to an array. Look at this pseudo-example:

object PlatformData
{
	bool Active;
	Vector2 Position;
	Type PlatformType;
	bool HasBeenHit;
	bool DeadlyToHit;
	int LowerPlayerHealthBy;
	Color DrawColor;
}

class SomePlatform : Platform
{
	override void Update(GameTime gameTime, PlatformData data)
	{
		// update data, calculate new position, etc
	}

	override void Draw(SpriteBatch spritebatch, PlatformData data)
	{
		// draw the sexy platform
	}
}

class SomeGame : Game
{
	Dictionary PlatformLogic = new Dictionary();
	PlatformData[] PlatformData = new PlatformData[40];

	override Update(GameTime gameTime)
	{
		for (int i=0;i<PlatformData.Length;i++)
		{
			var data = PlatformData[i];
			if (data.Active)
			{
				var logic = Platform[data.PlatformType];
				logic.Update(gameTime, data);
			}
		}
	}
}

PlatformData hold all information about the element. Platform holds all the logic about Update and Draw. And the SomeGame contains references to both.

More babies, less action

Well, during the last 6 weeks I have been attending attending my newborn and havn’t had the time to make much progress on my games, even less on posting stuff on my blog. But it’s about to change! (I hope … with kids you can never plan much, imo 🙂

I’ve finished the first version of my testgame that I’m going to release on app-store. I’ve learned alot of concepts during this path. The next game be alot faster to develop and I have a semi-good idea about it. To me I’m still in early learning period. I need to learn more OpenGLES to be a resource for the XNATouch-community.

My very own SpriteBatch (the concept)

Well, I finally got tired of the low perforance of XNATouch when it comes to drawing sprites so I’ve set about an own project of drawing them. The concept is as follows:

• Each sprite I’m drawing needs to have a base class with it’s position and dimensions. It’s gonna be called Element
• The Element should also have a notion other types of transformations on it, such as scale and rotation
• The Element must know what texture it going to be drawn from and the part of the texture (since I’m merging all my textures for faster load times.
• Since there’s alot of garbage created and discarded when making these calls to the draw, the Element should have a knowledge of it’s own vertices. Today, in XnaTouch, they are created in a List<> and thrown away after usage. At every draw call.
• The vertices should be recalculated before each draw in the SpriteBatch so their values can be copied over the array in the SpriteBatch.
• Setting a new texture every time to the shader takes some performance, so the SpriteBatch will copy vertices as long as the texture isn’t changed. Here I will benefit from having texture packs/merged textures as the Texture-parameter of the shader will change more seldom.
• Drawing the Element should have a possibility for clipping (since I want to create scrolling panels with text and pictures in them).

The rotation itself is presenting a few problems. I finally got the rotation sorted out (I’m totally fresh on the whole Matrix business). The other problem is that the quad expands when the position of the vertices are transformed. I’ll have to look into that one.

Another great point of making the SpriteBatch on my own is that I can specify the Z and therefore easily layer the sprites in more layers than just the two. Making shadows easier w/o having to make a shader. I was forced to learn some shader techniques to create my own since BasicEffect wasn’t working, but that was due to the fact that the vertexdeclaration was shot and needed to be set before every draw call.

When I get it fully working in Xna, I will port it to OpenGLES. It’s damn fun, I feel I’ve learnt alot from this, but unfortunatly my game has been delayed even more.

I’ll post the code and some thought when I have it ready …

Check it out at Vimeo: Blow him up, 2nd prototype