Archive for the ‘C#’ Tag

OpenGL ES: Batch Rendering on the iPhone

This one took me a while, simply because there was a LOT of research to do on my part. This is not going to be a tutorial post, per-se… but more so a “This is what I’ve found” and a request that someone take a look through it and see what I could have done better, and then let me know ! :)

Simply put, I was getting a few FPS problems with the development of my game, and thought I would come up with a way to batch all of my drawing into as few OpenGL calls as I could. I came across a few interesting tidbits, including a Stanford ‘iTunes U’ course (look that up in iTunes, its WELL worth viewing) Especially the one on OpenGL from Tim Omernick (Slide can be found HERE).

A copy of the code can be found at the google code repository, direct link to the TextureController is HERE. Well then, lets have a look at it!

The first thing that I attempted to do, was make a struct with the vertices, color information, and uv information. This is a result from Tim’s lecture and heavily influenced by his code. The hiccup was that I wanted to be able to batch based on the GLuint being drawn so I would only have to bind a texture once and then draw all vertices associated with that texture. I came up with the following solution:

struct Vertex
 short v[2];
 unsigned color;
 float uv[2];

struct VertexInfo
 Vertex vertex[MAX_VERTICES];
 int _vertexCount;

What will happen here, is VertexInfo will be stored in a map, while the Vertex struct houses all of the information that will be thrown at OpenGL to draw. MAX_VERTICES is defined at the top of the header file, and I really have not played around with it much so I am not sure how slow or fast it will be with a full game running. Currently its set for 100,000 but that was just a number I pulled out of nowhere :D I imagine it should be reduced.

The Map containing the vertex information looks like this;

typedef std::map<GLuint, VertexInfo> VertexMap;
VertexMap vertices;

You’ll see how to use this in a minute. My idea for this class was to sort of clone the way the SpriteBatch works from the XNA framework. This is another of my nods to how well this framework is put together, and how much I enjoy working with XNA. I wanted to be able to call a begin function to let the TextureController know if I plan to use blending (or any other parameter I may add, such as sorting), and then throw a bunch of stuff to draw using the Textures->draw functions provided. Each call to the Textures->draw function will take the texture to be drawn and any information needed (such as the location, source rectangle, color, etc) and pack that information into the VertexMap waiting to be thrown to OpenGL. Once all of my draw commands have been executed, a Textures->end() will initiate all drawing for the batch.

Keep in mind, is this the best way to put something like this together? Probably not.. although its my first time doing such an interesting task.. :) Lets see how it works!

NOTE: I will input breaks to make some comments… so if you want the full file, be sure to visit the code repository at

void TextureController::draw( const Texture2D& texture, const Rectangle& destination,
 const Rectangle& source, const Color& color, const GLfloat depth )

As you can see, we’re plugging in a few informational tidbits, but this is only one of the drawing commands that i’ve implemented. The simplest draw command, you only have to provide a texture and a destination rectangle… and “default” values will be put to fill in the blanks when calling this function.

 GLuint glid = texture.getId();

 //	if we don't have any vertices with the texture being drawn, create a
 //	vertex map for it.
 VertexMap::iterator it = vertices.find(glid);
 if (it == vertices.end())
 vertices[glid]._vertexCount = 0;		

 //	find all of the vertices we'll need for this sprite
 float topLeftX = destination.x;
 float topLeftY = destination.y;
 float topRightX = destination.x + destination.width;
 float topRightY = destination.y;
 float bottomLeftX = destination.x;
 float bottomLeftY = destination.y + destination.height;
 float bottomRightX = destination.x + destination.width;
 float bottomRightY = destination.y + destination.height;

The above section is interesting in that it will first find out if we’ve already batched a sprite using the texture. If we have, we’ll just add the vertices into that batch. Otherwise, we’ll create a new batch of vertices and start that new batch. Next, we find all of the vertices! This is done through the destination rectangle passed in. The destination rectangle is going to be the spritebox that the texture is drawn to. In other words, its your canvas and your texture is the paint.

 // Texture atlas
 float minUV[2];
 float maxUV[2];

 //	if the source rectangle of ZERO was passed in, it means the client want to just
 //	draw the texture as is.. otherwise, the client wishes to draw a portion of
 //	the rectangle
 if (source == Rectangle::ZERO())
 float maxS = texture.getMaxS();
 float maxT = texture.getMaxT();
 float minS = 0;
 float minT = 0;

 minUV[0] = minS;
 minUV[1] = minT;
 maxUV[0] = maxS;
 maxUV[1] = maxT;
 float minS = source.x / texture.getWidth();
 float minT = source.y / texture.getHeight();
 float maxS = source.width / texture.getWidth();
 float maxT = source.height / texture.getHeight();

 minUV[0] = minS;
 minUV[1] = minT;
 maxUV[0] = maxS;
 maxUV[1] = maxT;

This section took me the longest to really figure out, because I had not done any research how Texture Atlas’s work. As I said, this was heavily influenced by Tim’s code and I really wanted to understand this section before I moved on. What we’re doing here, is if a blank rectangle is passed into the function (meaning the client didn’t specify a rectangle and therefore wishes to just use the texture ‘as is’) we’ll use the maxS and maxT coordinates for the TextureCoordinates. The way we find out what maxS and maxT are, is after the image goes through its modification to become a power of two texture (see my last article), maxS will become imageWidth / newTextureWidth. In other words
if the texture is passed into your game at 30 pixels by 30 pixels, it was re-sized by the Texture2D class to become 32 by 32. maxS will be 30 / 32, or 0.9375f. This value indicates that when using the default values, 93% of the image is drawn, while the remaining 7% of the image contains nothing more than padding in order to ensure it was a power of two texture.

What if we wanted to use a sub image, only draw a portion? This would be useful if we had several images on one texture. Lets say you have a texture with 2 frames of animation, both frames are 24 by 24. This means your texture is 48 pixels wide, by 24 pixels tall. If you only want to draw the last half of the texture (your “2nd” frame of animation) your source rectangle would be:

x=24, y=0, width=24, height=24
Meaning you’re starting 24 pixels into the picture, at the top pixel of the picture, and you’re going 24 pixels wide and 24 pixels high. This is going to be the sub-image you’re drawing.

In order to change these numbers into texture coordinates, we need to divide by the image width or height. For example, 24 / 48 is .5, so your texture coordinate for x is .5, then 0, then .5, and .5.

 //	Convert the colors into bytes
 unsigned char red = * 255.0f;
 unsigned char green = * 255.0f;
 unsigned char blue = * 255.0f;
 unsigned char shortAlpha = color.alpha * 255.0f;

 //	pack all of the color data bytes into an unsigned int
 unsigned _color = (shortAlpha << 24) | (blue << 16) | (green << 8) | (red << 0);

 // Triangle #1
 addVertex(glid, topLeftX, topLeftY, minUV&#91;0&#93;, minUV&#91;1&#93;, _color);
 addVertex(glid, topRightX, topRightY, maxUV&#91;0&#93;, minUV&#91;1&#93;, _color);
 addVertex(glid, bottomLeftX, bottomLeftY, minUV&#91;0&#93;, maxUV&#91;1&#93;, _color);

 // Triangle #2
 addVertex(glid, topRightX, topRightY, maxUV&#91;0&#93;, minUV&#91;1&#93;, _color);
 addVertex(glid, bottomLeftX, bottomLeftY, minUV&#91;0&#93;, maxUV&#91;1&#93;, _color);
 addVertex(glid, bottomRightX, bottomRightY, maxUV&#91;0&#93;, maxUV&#91;1&#93;, _color);

Aah, bit packing... how do I love thee, let me count the ways! When I first learned how to manipulate bits of data, I asked myself "Why would this ever be useful?" ... guess I learned the hard way, that its a very necessary skill to have. I don't fully understand it as much as I would like to, but I do a little research on it every day.

What we're doing in the above code is taking the red / green / blue / alpha color value (which is passed in as a 'between 0 and 1' value), multiplying that by 255, and packing the bits into a single value called _color. Apparently, its a lot faster for OpenGL to use this data in this way, so hi ho, hi ho.. its off to pack we go!

void TextureController::addVertex(GLuint glid, float x, float y, float uvx, float uvy, unsigned color)
 VertexInfo *vertexInfo = &vertices&#91;glid&#93;;
 Vertex *vert = &vertexInfo->vertex[vertexInfo->_vertexCount];
 vert->v[0] = x;
 vert->v[1] = y;
 vert->uv[0] = uvx;
 vert->uv[1] = uvy;
 vert->color = color;

And packing we do! This is where the batch work is done. What we’re doing is passing in a single Vertex data (the x location, y location, texture coordinates, color, and the texture used) and packing it into the struct I showed you above. Once we do that, we increase the _vertexCount, so we’re keeping tabs on how many vertices we’re batching.

So.. thats how we batch, how do we render? Simple!

NOTE: Keep in mind, this is only a portion of the code. This function is called from the “end()” function I talked about eariler. end() will ensure that beginning was called, and then pass the buck to the render function.

void TextureController::renderToScreen()

 //	Texture Blending fuctions
 if ( blendAdditive )

 //	needed to draw textures using Texture2D

 //	enables alpha for transparent textures
 //	I forget where I got these commands, I think
 glAlphaFunc(GL_GREATER, 0.1f);

 //	Enable the various arrays used to draw texture to screen


The above is just standard stuff to get ready for rendering. In fact, I think this was just cut / pasted from my Texture2D class. The real interesting part happens next!

 //	loop through all of the elements of the map and draw the vertices
 VertexMap::iterator it = vertices.begin();
 for (/* none */; it != vertices.end(); it++)
 //	easy access to our data
 VertexInfo *vertexInfo = &it->second;
 Vertex *vert = vertexInfo->vertex;

 //	bind the texture for the following vertices
 bindTexture( (*it).first );

 //	throw everything to OpenGL
 glVertexPointer(2, GL_SHORT, sizeof(Vertex), &vert->v);
 glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), &vert->uv);
 glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(Vertex), &vert->color);
 glDrawArrays(GL_TRIANGLES, 0, vertexInfo->_vertexCount);

 //	reset this batches vertex count
 vertexInfo->_vertexCount = 0;

What we’re doing here is looping through every key (which is the GLuit of the texture, if you recall) binding that texture so that OpenGL knows which texture to draw with, and then throws all of the vertices and texture coordinates and all other info needed to render the batch. A few notes that some people might not know (I didn’t when I was researching this)

glVertexPointer(2, GL_SHORT, sizeof(Vertex), &vert->v);
the 2 means that there will be 2 vertices, and x and a y. This number could be a 3, if you’re also storing a z value. We will be using GL_SHORT (remember in the struct, all vertices are declared as short), and the interesting portion of this is the sizeof(Vertex). This is called a STRIDE, and basically tells OpenGL the distance between the data in memory. (I hope I explained that correctly!) The last value is the array of vertices!

glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), &vert->uv);
This is very similar to the above.. except we’re using different values. The 2 is referring to the fact that we have 2 points per vertex for the texture coordinates (an x and a y) but if you’re going to be using a z value, this number will be changed to 3. Remember, we are using floats for this (check the struct), and the STRIDE value stays the same. Then just pass it in the array of information.

glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(Vertex), &vert->color);
Again, similar concept, except we did a few things differently with this. Remember our color scheme is 4 colors (red, green, blue, and alpha) but we packed all that information into a single value? We specify that via the GL_UNSIGNED_BYTE. otherwise, everything else remains similar.

glDrawArrays(GL_TRIANGLES, 0, vertexInfo->_vertexCount);
This is the reason we’re keeping track of how many vertices we have! What we’re doing here is telling OpenGL to draw the arrays using triangles, the 0 is referring to the starting index (obviously we’re going to be starting at index 0, just as if we were looping through the index ourselves), and how many elements are in the arrays.

What this will do, is put together the information in a single stream of information.. something like:

This is much more efficient for OpenGL to render, and therefore it will chew through the data and at much greater speeds than if you render your data once per texture. (ala, my old method)

now all thats left to do is clean up by disabling any states we enabled

 //	disable all the stuff we enabled eariler
 glDisable( GL_BLEND );
 glDisable( GL_TEXTURE_2D );
 glDisable( GL_ALPHA_TEST );


and voila!

Again, this is my first pass at writing such a system.. and I am still learning the form of graphics programming. I urge you to pick up the code from the svn repository ( and play around with it. If you find anything that I could do better, or things that may help me understand this process a little better, feel free to post for everyone to learn from!

Happy Coding everyone!


OpenGL ES Texture2D: Power of two

As most of you have figured out, OpenGL ES doesn’t like textures to be non power of two, and I really didn’t want to have to force all of my textures to be powers of two before loading them into my game. This presented me with a problem that had to be solved in-code.

To really understand texture mapping, especially if you’re doing iPhone development or OpenGL ES development in general, it is a good idea to visit Jeff’s blog on the subject located: HERE, and look up chapter 6 on Texture Mapping. I’ll wait, its a great read and should be glanced over at the very least!

Back? OKAY! So the problem is only powers of two can be used in OpenGL ES, so how do we convert our texture to a power of two? There are several ways to do this, but I chose to look at apples version of a texture file and learn from them.

They came up with the following to convert the width and height into a power of two:

//     Adjust the width and height to be a power of two
if( (_width != 1) && (_width & (_width - 1)) ) 
                i = 1;
                while((sizeToFit ? 2 * i : i) < _width)
                        i *= 2;
                _width = i;
        if( (_height != 1) && (_height & (_height - 1)) ) 
                i = 1;
                while((sizeToFit ? 2 * i : i) < _height)
                        i *= 2;
                _height = i;

The first portion of the code will convert the texture to a power of 2. Since the texture will be stretched, and never shrunk, apple had to figure out a way  to shrink the texture if it became larger than the max texture size of 1024. The following code will do just that:

        //      scale down an image greater than the max texture size
        while((_width > kMaxTextureSize) || (_height > kMaxTextureSize)) 
                _width /= 2;
                _height /= 2;
                transform = CGAffineTransformScale(transform, 0.5, 0.5);
                imageSize.x *= 0.5;
                imageSize.y *= 0.5;

the ‘transform’ is nothing more than a CGAffineTransform; in case you were confused with that. So, now that you’ve glanced over the code, you remember in the article where Jeff was talking about S and T coordinates? We’ll take care of those like this:

        _maxS = imageSize.x / (float)_width;
        _maxT = imageSize.y / (float)_height;

This will give us a number between 0 and 1, depending if the texture was re-sized or not. _maxS and _maxT will also be used in our textureCoordinates array for drawing the texture to screen. This should only render the portion of the texture that has any data, and not the padding we added to the texture.

While I am still learning OpenGL, I figured that a lot of people would be interested in the following solution.. especially if you did what I had, and had thrown out the Apple Texture2D file and re-wrote your own. Full source code to the Texture2D, or any other file within the D’Jinn Engine can be found HERE.

Hope this was informative! If anyone has any further information they would like to add, feel free!

Happy Coding Everyone!

C++ on the iPhone: Djinn Engine

EDIT: I would like to point out that below, when mentioning “Mike” … I forgot to plug his website.. whoops! In any rate, he has a few great tutorials (in video form) located: … HIGHLY recommend you check them out if you’re using Obj-C on the iPhone.

Hello everyone! I have been reading through your emails and appreciate all the letters. One question I kept asking myself with this project was “Do I want to make the engine open source?” My decision came apparent when I realized that this engine, although it will be used for my iPhone games, was first and foremost a learning experience for me and a tool that I used in order to become a better programmer.

So here I am, with a working copy of the Djinn Engine, and I have decided to make the project ‘open source.’ Before I upload the source to a SVN however, I want to ask the communities opinion on what they want to see?

The engine works, but it is crude. Currently in the engine is the following:

TestGame – I’ve been using this as a static unit testing for the engine

Actor System – Handles any actors in the game. Started by using the Angel Engine as template

Animation System – Animation Manager used for stopping, starting, and updating various animation playlists.

Game Screen Management – A C++ version of the Screen Controller tutorial from below.

Serializable objects – All objects (Characters, particle effects, etc) will be serialized in .dat files for dynamic loading. This way they do not need to be hard coded into the engine.

Input management (single touch only) – A C++ version of the input manager tutorial below.

Particle System – Using Mike’s tutorial as a starting point, dynamic particle system that includes a controller, effect, and various emitters for every particle effect. The one i currently have been using is “fire”

OpenAL Sound Support (have not put in OGG support yet, plan to) – Also using Mike’s tutorials as a staging point, this is an OpenAL sound engine that currently only works with sound effects… I want to add OGG support in the future.

File Management – pass in the asset name of a file, and a pointer to the object you wish to unserialize, and the file manager will take care of the rest.

Random Number Generation – … does just what it says it will do :)

Modified version of Apples Texture2D for C++ (will need to revamp this)

Math Utilities class (IE: Clamp, Min / Max, Abs, Lerp, etc etc)

and a couple of other things. Keep in mind, this is a 2D engine! So… iPhone community… We have a few choices before this thing goes Open Source. I will continue working on it, adding things that will meet my needs (keeping in mind, this will be the engine I am using for my iPhone Game) and I figure if I need a feature, maybe the community could use it as well. Should I just release it “as is” right now and continue working on it while you all can get your hands on it and modify it depending on what you need? Should I clean it up a bit, so its easier to understand when you’re reading through the code? or should I wait til the engine is pretty much done and release it then?

Let me know either via comment or email what you wish, and we’ll make it happen. I’ll have to work on some documentation, especially for the crude object serialization haha.. but that shouldn’t be too hard to do. Let me know what you think, and for the few of us who actually enjoy C++ on the iPhone, lets make it happen!

C++ on the iPhone: Test Driven Development

I have been learning quite a few development strategies as of late, and the newest one that I’ve taken a peek into is Test Driven Development (TDD), or Unit Testing. The idea behind TDD and Unit Testing is to split up your problems into small, easily manageable problems rather than having to design everything from the get go, and living with any or all of your mistakes for the rest of the project. TDD is a very complex topic and usually requires the use of various frameworks for dynamic unit tests, but I’ll be focusing on the ‘beginning’ method of TDD, static unit tests.

How do we start? Well in my current engine, what I did was write a class called “TestGame.cpp” which was a singleton class that housed various methods for testing the game. In that class, I would write functions to test a particular class I would be creating, or an entire game loop to test the logic of a class without having to construct a game world for our object to live in. Inside the TestGame class there is a function called ‘startTesting()’ which will call anything you wish to test. Lets write a sample test to give you an idea on the very basics of what I’m doing.

//This function is public, and able to be called when you obtain the instance
//of the TestGame class. We will start every test from this function, and keep
//it kind of like a list. Whenever an aspect needs to be changed, for example
//with the actor class, we can simply uncomment the 'testActorClass()' line 
//to ensure it still passes all of our tests. 
void TestGame startTesting()

//This function, however... is private and unable to be called by anything
//outside the "TestGame" class, and should only be called by the 'startTesting()'
void testActorClass()
	Actor *act = new Actor();
	string testString;
	float testFloat;
	act->setAlpha( .50f );
	testFloat = act->getAlpha();
	//	identities are unique and assigned when the object is constructed.. Calling this function
	//	should not change the identity
	act->setIdentity( "newIdentity" ); 
	testString = act->getIdentity(); //should still be "Actor_#"

	act->setName( "Werewolf ");
	testString = act->getName();//should be "Werewolf"

	act->setPosition( Vector2::ZERO() );
	testString = act->getPosition();//should be 0,0

	act->setSize( Vector2(32, 32) );
	testString = act->getSize();//should be 32, 32

	act->update( .003f );

Now if I were to compile this code, it would spit out a bunch of errors. “Set Name? .. Get Identity? I don’t know how to do that!” and that’s the point! These functions have not been written yet. The basic idea is to construct what you want your actor class to do, and then write the code to DO it. The next step is to write JUST enough code to get the project to compile, so… to the actor class we go! Quite literally, all we’ll be doing in the next step is to write the skeleton functions like such (NOTE: The various helper classes like Vector2 have been written and added to the engine, they are already created and have already been tested using this approach and do not come ‘standard’ in C++ (or Obj-C as far as I know);

//in the Actor.h file
	bool setIdentity( const string &value );
	string getIdentity() const { return identity; }

	bool setName( const string &value );
	string getName() const { return name; }

	bool setPosition( const Vector2 &value );
	Vector2* getPosition() { return position; }

	bool setSize( const Vector2 &value );
	Vector2* getSize() const { return size; }

	bool setAlpha( const float value );
	float getAlpha() const { return alpha; }

	virtual void update( const float deltaTime );
	string identity;
	string name;
	Vector2 *position;
	Vector2 *size;
	float alpha;
//in the Actor.cpp file
bool Actor::setIdentity( const string &value )

bool Actor::setName( const string &value )

bool Actor::setPosition( const Vector2 &value )

bool Actor::setSize( const Vector2 &value )

bool Actor::setAlpha( const float value )

void Actor::update( const float deltaTime )

This code should now compile and run, even though it doesn’t do anything. Well we know what we want to do, and we now have a skeleton to do it… so we should get going on writing the code!

For example, we know that we want the identity of the actor to be unique, and that the setIdentity function should only set the string if it currently does not have an identity.. so since this is going to be the most difficult function to write, lets do that one real quick.

bool Actor::setIdentity( const string &value )
	//	if the identity has already been set, do not
	//	re-set the identity. Object must be destroyed
	//	and re-created to reset an identity. 
	if ( identity.length() != 0)
		return false;
	//	if the identity has not been set, set it
	//	and return true
	identity = value;
	return true;

really, thats it. The actor doesn’t know if its identity is unique, nor does it know how to obtain a unique identity. It just says “Okay, I don’t have an identity right now, so I’ll take this one and make it my own!” The idea is the actor class exists on its own, and functions as its own data. To obtain a unique identity and to keep track of all actors in the game world, we will use an ActorController (remember that pesky thing called the Model / View / Controller? ) The Actor class is the data (model) while the Controller will manage that data and when needed, present it to the view for rendering.. but that is a topic for another post.

The last thing we should do is COMMENT COMMENT COMMENT! I am a big fan of commenting my code, and documenting not only what the function does but why its implemented the way it is. If you ever look over your code 3 months down the line, you’ll say to yourself “I didn’t write this… what was I thinking?!” … well if you commented your code, you’d know! its a good habit to get into, and if you look at my Screen Controller from a few posts back, you’ll notice just how much I comment.

So that is all for today. Test Driven Development is a HUGE area, and this is just the very very basics of how it can be done. Once you get into the frameworks, it can be pretty complex, but very much worth the effort.

Happy coding everyone!

No more teachers, no more books… until next semester!

Wow, I didn’t expect my first semester back at college to be that difficult! It turns out that every project I was doing was put on hold until I could finish my semester. My next semester schedule isn’t any lighter though, although I have cut my hours down from work as to give myself more time to work on my projects. 

So here is where we stand, The map editor is very close to release 1.0, and 1.0 is a basic update. It will do what you need it to do, but it isn’t “polished” .. more “functional.” While on winter vacation I am working with my friend to push out a release, and once that is done we will start opening up the source and add whatever features we may need.

I’ve found that my goal for this project was ambitious, but in line to what we could accomplish. I wanted this editor to work primarily for XNA projects, but not only RPGs. Any game that used a tile engine could take advantage of this project. But what about other platforms? iPhone development? Well it would just take some tweaking to the exporter and you’d have a fully functional XML file.. could that work with iPhone development? Not sure.. but I think it would be fun to tinker with :)

As always, check out my right bar links, there are a lot of awesome projects (Including EvilNando’s Animation editor) that i’ve been keeping tabs on. Lot of great things goin on in the world of XNA, here’s hoping that I can get a final push out and start my actual project here soon.

RPG Editor: Exporter Settings – First Preview

With the first version of the RPG editor just about ready to be tested, I thought I’d take the opportunity to share some of the things we’d like to implement. So lets take a look at some of the custom XML exporting!

From this first screen shot, you will notice that on the left half of the form is all of the fields that can be changed, while each change will be reflected by the XML Output on the right. Using this data, it will be easier to see how your final XML will look, before you export the XML file. 

You can also see that we’re trying to make any map created with our editor be directly “plug and play” with an XNA project. For example, the XnaContent tag is automatically implemented, and so is the Asset Type= but the user will be able to specify their project namespace as well as the map class name that will be housing the data in-game. Obviously every XNA project needs this information unless you are using a custom importer / processor for your XML data, so you can not opt out of having this information exported.

Attempting to make the XML as flexible as possible, you will notice one feature we’ve already put in. You can specify the “Output Type” of your data to take advantage of the various importing techniques of the XNA Content Pipeline. For example, if you wish to import your “MapDimensions” data as a point, the output XML will look something like:

<MapDimensions>X Y</MapDimensions>

while if you wish to import it as a custom data and write your own Content Reader / Writer for that data, you can and it will export something like:


and naturally, all fields are customizable so if you wish to change “Width” to “MapWidth,” you can.

So, for now… this is a small snippet of what we’re working on. Again, we expect this project to be open source once we get further down the road, so anyone can take what we’ve done and expand on it or use it for their own editors.

I hope this project encourages the creation of some great RPGs, because I love me some RPGs :) See you all soon!

Community Games has a date

If you’re working on your own game, or know someone who is.. You should be excited to know that the Community Games has a formal date!

“independent game developers will be happy to know that XNA Game Studio 3.0 will be available for download on October 30, 2008 so they can to convert their creations and prepare them to be a part of the launch of Xbox LIVE Community Games on November 19.”

Good news indeed. Looking forward to playing some of your creations :)

Content Creation

With the Dream Build Play project “Complete,” I’ve turned my attention to a few items that will aid in the creation of not only Meir, but any future RPG I write. Content creation is a tricky subject, as the goal is to create something flexable enough to re-use in any RPG project, but dynamic enough and easy enough to use so if I had a few people working on any given project, they would know what to do.

Well me and a buddy from the shacknews chatty decided that he didn’t want to use TileStudio anymore, but wanted something more suited for his game.. so we started colaborating on an editor that would be built specifically for XNA games, but flexable enough to use in any project. Obviously this editor will have to support several major features of basic RPGs, but how in depth are we going to really go with this thing?

Create and edit tile maps? Basic feature, has to be included.
Exporting XML in the same style of the XNA Content Pipeline? Basic feature, has to be included.

but what about features like adding a “tile” to the texture, and having the map build the texture and exporting that to a PNG file? What about creating a system that can export to multi dimensional or single dimensional arrays based on the project needs? How about a dynamic XML system that lets the user edit how their XML should look, then hitting “Export XML” and having their XML formatted correctly? There are many many more ambitious goals we wish to include, and we’re thinking a bit larger scale then just these… but its pretty interesting to see what we could come up with. As always, I’ll keep everyone up to date on whats actually going on. 

So if you had to pick and choose a few “Must Have” features of a game editor, what would you want included?

Meir available for download on Creators Club Beta

The Dream Build Play entry ‘Meir’ is now available on the Creators Club Beta for peer review. Official link to the Creators Club entry is:

I am now on a mission to make substantial improvements to both the engine, technology, and adding the sub-systems that I could not impliment for the Dream Build Play competition. My goal is to have a working framework for my Role Playing Games, and then start working on assets such as quest creation / story / artwork. I figure the engine touchups and technology will take a month or two, but the rest will take longer, so I will probably be looking for either help or outright purchase assets (such as characters, tilesets, etc) from aspiring developers. But… until then, let me know what you guys think!

In order to download titles from the Creators Club Beta, you will need a premium membership. Feel free to leave feedback here or via email at:

Meir is an official Dream Build Play project

When I started this project, I couldn’t tell you the difference between a float, int, or double. I didn’t know how to program, and had no clue where to even begin on a project as complex as this… but here I am.

Typical combat screen in Meir

Typical combat screen in Meir

Obviously its not a complete game, nor is it as polished as it could be.. but its good enough to prove a point to myself. Good enough for me to say “I set a goal for myself and reached my deadline with a specific quality in mind, and I hit it.” Next step for me is going to be putting together a story, finishing everything I couldn’t get done for the demo, and working towards the Community Games. Until then, enjoy the promotional video we had to put together for the Dream Build Play competition.

For some reason, the video is currently not showing. Direct link is:

I would like to give a few thanks.. because there were some people along the way that really pushed my goals forward. Most notably from the shack news community ( People such as MitchWalker, RomSteady, and Mittense, DHAvatar, and everyone else on that crazy site.

I would also like to point out that the music for the demo was crafted by Delaric, and it is fine music indeed. Several people have contacted me wishing to help on a possible final version of the game and if you’re interested, all you have to do is shoot me an email. I would like to point out, however, that the final version of the game is a LONG… LONG way off. This i would consider, a very basic demo.. and the final version will be a full fledged RPG. You do the math :) But for now.. one milestone is down.. and thank you EVERYONE who helped along the way.