Archive for Development

Meet The Star Of Our Next Game: Charnette

CharnetteWho is Charnette?

Charnette was raised by her father from a very young age. Her mother died during a plague that swept through her home country when she was 5 years old. Her father did not have the money necessary to hire a nanny to raise her as a young woman is typically expected to be raised, so he did what he could.

Her father was part of the national army and spent much of his time with his regiment. But since he had to take Charnette with him, she worked as his page and later his squire.

Although she spent much of her time training with her father, she still took an interest in the girls in town. She would do her best to fit in and participate in their games and activities. This effort ended up influencing her skills and talent in fighting. For instance, the skills she picked up in sewing and fashion helped her design a suit of armor that better fit her body and fighting style. She also gained many skills in tending wounds and treating the sick.

Over the course of her early years, she gained significant experience in swordplay and became quite skilled in fighting with both sword and shield. She also spent time training with a variety of weapons in order to push herself.

In the summer after her 17th birthday, her father and his regiment were called to fight in a war with a nation on the other side of the sea. With her still being his squire at the time, she was brought along to help in this effort. During the trip across the sea, a huge storm arose and destroyed the ship she was on.

She woke up on the beach of a strange island along with her father who suffered a terminal wound during the sinking of the ship. Her father knowing his death was coming soon bestowed his sword and shield to Charnette for her protection.

Upon his death and burial, Charnette set out to explore this strange island and to search for a way off. While exploring she comes across a man being chased by a monster and saves him. This man, recognizing the crest found on the shield as on described in legend, implores Charnette to save his country from an army of demons and monsters who have cursed the land and the people.

This is where your journey as the gamer begins. And as a special treat, here is an early look at her in game sprite:

Charnette SpriteWe are currently running a GoFundMe campaign to help us buy a banner and some swag for Super! BitCon. If you donate, you will get some of this swag as well as early access to this game.


The Power Of Free: The Tools We Use

Just yesterday, One Game A Month featured my words of wisdom on their twitter account. They had been posting these statements from various developers for the last few months as a way to promote those developers and the project. Here is what I had to say.

If you can’t read it, here is what it says:

There are plenty of great free tools available for you to make great games. From art to design to IDEs to APIs. Explore them and find something that works for you. It is only after you find something that works for you that you can bring about the best you have to offer.

This got me thinking about our own development pipeline. If we don’t follow our own advice, then what is the point in sharing it? The good thing is that we do follow that advice.

What is our pipeline then? Let me break it down for you.


For our game engine, we have chosen to use HaxeFlixel. This is a very powerful and very useful game engine for creating 2D games of all types. Using this engine, we created 7 games and prototypes last year.

I even recently gave a talk about HaxeFlixel at the January Oklahoma Game Dev Meetup. Here are the slides from that talk.


What good is a game engine if you can’t program with it? Thankfully, Haxe and HaxeFlixel have a lot of great IDEs that are compatible. For use, we use a mix of IDEs depending on where we are currently developing.

If I am on a Windows computer, I use the great FlashDevelop IDE. this was originally designed for Flash development using Flex. Now it has been expanded to fully support Haxe development.

If I am working on Linux, I use Geany for now but am still experimenting with other IDEs but Geany is the one that works best so far.

There are some paid alternatives, but they are out of our price range as they often cost several hundred dollars.

Graphics With GIMP and Inkscape

Creating games requires a lot of graphical development. There are tons of tools available for you to use, some better than others, some easier to use than others. But the two tools that I use more often than any others are free and powerful.

GIMP is an alternative to Photoshop. It may not have all the features of the paid software and might not be as powerful, but if all your doing is creating 2D graphics for games, then it certainly meets the need.

Inkscape is an SVG graphics editor similar to Adobe’s Illustrator. It can be used to create all kinds of banners, logos and even game graphics. Again, this is not as powerful as the paid software, but it gets the job done for no cost.

We do have plans to use other software, some paid, some free, but these meet our current needs. We have a paid license for the 2D animation software Spriter which has HaxeFlixel support. When we get into 3D game development, we may use 3DS Max, but if I can convince Willis, we could use the free Blender.

Sound and Music

Sound and music is something we are currently working to expand. Music is a little more difficult for us to do ourselves as neither I nor Willis are musically inclined. But I have been practicing with LMMS, a great piano roll music creator. Of course, this is one of those areas that would be much better suited for outside contracting.

For sound effects, we are currently using SFXR to create the basic sounds for our game. It has some really cool features for creating base sounds and experimenting and altering them.

For more detailed and mixed sounds, we are using Audacity. This is a great free tool that gets the job done.

Recording and Video Editing

This is an area that is a little more difficult for us to get right. There are so many free tools but not all of them work as well as we would like. So we are still experimenting. For a while, we have been using OpenShot for video editing and it works for now. We would like something a little more stable and powerful, but you can’t really complain for the price.

Recording game footage is the real tough one. We have found and like Simple Screen Recorder, which works really well. However, it does not support recording to GIF files. So far we have been experimenting with GifCam and that seems to be working how we like it. But we need more time to play with it.

Version Control and File Sharing

This is probably the easiest no-brainer list for this category. The two most popular and powerful version control solutions are both free. Our current webhost provides free Subversion support and that is what we use. But Git is also a great alternative.

For sharing files outside of version control, we use a service called Copy. I was able to get a lot of file space for free just by sharing my referral code (which that link contains). Also, anyone who signs up using that referral code gets free space on their account.

DropBox is also a good free alternative and they have plenty of ways for you to get even more space for free. You can use either one to share large files between members of your team.


This is our main development pipeline. There is plenty of room for improvement as we expand our work flow and develop more detailed and expansive games, but I don’t see us changing very much in the near or far future.

But I hold true to my original statement. If you are just starting out developing games, use free tools. If you start making money, then you can expand to using paid tools that have more features. But you may just end up using what is familiar and fast.

Our Latest HaxeFlixel Contribution: Zelda Style Screen Transitions

The title is probably a little deceptive. The truth is that HaxeFlixel already has such a camera transition. However, it didn’t function 100% in the way it needed to. You can follow this problem in this HaxeFlixel forum post.

The problem was simple. I was using grid based movement for my character. I was following that character with the camera. When that character moved off the current screen to the north or west, everything was fine. You took one step off screen and the camera switched. However, when you tried moving east or south off the screen, you had to take two full steps off the screen.

This presented a problem as the character might have interactions waiting for them on the next screen that could be impacted by taking a “blind” step into it.

Consider the original Zelda game. In some rooms in the dungeons, there are spiked blocks that move quickly to damage you when you cross their path. These blocks are often positioned so that the path is the very next row of blocks after a doorway. In Zelda, you always start a room standing in the doorway. So if the camera in Zelda functioned the way it did in Flixel, you would have had to move directly into the path of the spikes to switch the screen.

Proper Screen Transition when moving up.

Proper Screen Transition when moving up.

The fix was really easy. The camera was checking to see if you were on the next screen, but was using a greater than sign (>) to do it. This meant that the player character had to be 1 pixel greater than the screen width to trigger the change. In many games, this wouldn’t be an issue. But with the introduction of grid based movement, where the player moves a set number of pixels with each directional press, this is a huge problem. If the squares in the grid are 16 pixels wide, that means you have to move a full 16 pixels into the next room to trigger the camera shift.

Improper Screen Transition when moving down.

Improper Screen Transition when moving down.

So the fix for this was to simply change the greater than sign to a greater than or equal to sign (>=). Once again, the change is nearly imperceptible if you are not using grid based movement. But for those of us that are, it makes a world of difference.

So this makes my second HaxeFlixel contribution and my first to the actual HaxeFlixel API. If I keep this up, I might just become a HaxeFlixel contributing junkie.

I have made my First HaxeFlixel Contribution

Recently, I have been working on my June One Game. I decided to take the level that my son built and turn it into a quick game. So I did what I thought was all that was needed and pulled it into a HaxeFlixel project. And it borked. This is what I got.

Several Layers Failed To Show.

Compare that to the level my son created.

Alex's Full Blown Tiled Map

I hope you can see the problem. So I turned to the HaxeFlixel forums to figure out what went wrong. Read more

Tiled Map Editor Is Making A Big Difference

Tiled Map EditorSo I have been working with the Tiled Map Editor and I am super excited about using this cool new tool. I already mentioned it when I wrote about my May One Game Project. But I wanted to share some of the cool things I have found when messing around with this tool.

First off, I cannot emphasize more just how darn cool this map editor is. This thing is super easy to use and super fast. I can churn out basic levels in no time. The sample map I am going to show you in this article was tossed together in about 5 minutes. I didn’t have to really work at this at all.

In comparison, my prior efforts to create hand coded levels were a bit convoluted in retrospect. That one took me over an hour to put together.

So let’s explore a sample level I created. This one is inspired by the level I created in my other attempt that I linked above. It isn’t quite the same, though. Read more

One Game A Month January Entry: Dragon Canyon

January 2014 One Game A Month Entry: Dragon CanyonAs we posted on our new year resolution post, we are trying again for the One Game A Month challenge this year. We had made an attempt to do so last year, but only managed to get through February. But even those games were not ones that we actually worked on that year.

This year, we are actually going to go for it. As such, we have finished our first game for the year, Dragon Canyon. Dragon Canyon is a game in so much as there is gameplay, a scoring mechanism and an end condition. It isn’t a complete game in that it is missing a few things.

Before I get into all that, I wanted to explain the history of this game. It kind of fits into the mold of my previous entries into One Game A Month. Both of those were dragon themed and fairly simple. Dragon Canyon is kind of a successor to Dragon Fire in many respects. It is a shooter and you play as a dragon shooting various flying monsters. But it is very different from it too.

For one, Dragon Canyon allows the player to choose which dragon they want to play. Each dragon has its own projectile as well. With Dragon Fire, the player was given a dragon at random and all dragons fired the same thing.

Additionally, Dragon Fire restricted the player to only left and right movement. The player was unable to travel vertically. This has changed with Dragon Canyon. Along these same lines, rather than a top to bottom shooter, Dragon Canyon is a bottom up shooter.

Finally, the enemy behavior is greatly altered. With Dragon Fire, all enemies appeared at the bottom and flew straight up. In Dragon Canyon, I wanted to add variety to the enemies, not just in looks but in how they act. So I have some very basic enemy behaviors in the game. There are four enemy types and each behaves slightly differently.

I would like to expand on this game in the future. I love to play shooters like this from time to time and it could be a lot of fun when improved. I had originally started the game idea as a test for Ouya development. So the goal is to add controller support as well as play for up to four players. I would also consider increasing the screen resolution to allow for full use of HD televisions.

I also need to add a lot more variety to enemies and their behaviors. As of right now, there are no enemies that shoot back and that is something that needs to change. There are also a lot more movement patterns to experiment with.

I also want to further differentiate the player dragons. While it is great that they look different and have different projectiles, I would love to add special moves that are unique to each dragon.

The background is something else that really needs to improve. I want to add a scrolling background to the game as well as different stages with their own enemies. Each stage could be themed around the different dragons.

Outside of all that, the other improvements to the game would include sound and music, pixel perfect collision detection and player health and lives.

Overall, it isn’t that bad of a prototype to be used as my January entry into One Game A Month. I look forward to working on my February entry.

We Got Our Ouya And Are Excited For Its Potential

The Ouya ConsoleLast week, our Ouya arrived. This little guy has the potential to change console gaming for the better. With the news that the XBone will be blocking used games trades, game lending and game rentals, people are going to be looking for an alternative. Additionally, rumors have it that the PS4 might be following suit. While the WiiU might be able to provide a decent alternative to those two, I think the Ouya holds much greater potential to capture the hearts of gamers.

The biggest part of this is the low cost. Right now, the console is selling for $99.99 over at This low cost of entry for the consumer will allow a greater number of people entrance into the gaming fold. Similar to how the Wii brought in new gamers, the Ouya can do it too. The cost savings don’t end there. All games will have some sort of free component to allow gamers to try the game before paying out money for it. So it will be easy to find games you will like without risking your wallets. Read more

Rebuilding Demon’s Hex In Haxe And Achieving Goals

The new year brought with it a change in technology. We had been working on building our games for Flash using Actionscript 3 and Flixel. That is a very powerful pair of techologies to work with, if you want to target the web almost exclusively. However, our goals are to eventually target desktop environments as well as mobile phones. While it is possible to work with Actionscript to target those environments, it would require us to use something like Adobe Air. However, that technology is not particularly liked nor does it have continued support for Linux. So we needed a change.

Lucky for us, some awesome game developers ported Flixel to a very Actionscript like language called Haxe. HaxeFlixel has made it possible for us to fairly easily port our existing code, which honestly wasn’t a whole lot, and get ready to target all the technologies that Haxe targets.

HaxeFlixel About Diagram And Target PlatformsBy using HaxeFlixel, we will be able to create the types of games we want to make and bring those games to the web, desktops and mobile devicess.

This brings me to� our goals. Development has been slow, very slow, too slow. This is primarily because I work full time and have a family so the time I get to work on the game is not a lot. With all that in mind, Willis and I got together to lay out some realistic prospects for what I can do. I have broken out my tasks into monthly goals and plan on working them. Here they are for you:

  • February
    • Finalize the Haxe Project for Demon’s Hex
    • Set up the Title Screen
    • Set up the initial Map Screen
  • March
    • Get the Tokens Figured Out
    • Get the Inventory Screen Working
  • April
    • Get Battles Working
    • Create the AI
  • May
    • Create Story Elements and Progression

I have completed February’s goals and look forward to tackling March’s. I already have some great ideas on how to tackle some of the problems I had been facing previously when it comes to the tokens. A lot of that will be done outside of Haxe, though, as I will be creating some game tools for us to use.

As for Willis, his portion of Demon’s Hex is mostly completed and at this point he is working on things for it on an as needed basis. So he will be working on expanding his craft and learning to better utilize some tools that we plan to use on our next game. A lot of this is animation. I look forward to seeing what he does in that regard and plan to show them off when I can.


2013 Resolution: Create One Game A Month For Twelve Months

I don’t know if any of you guys have heard about the latest craze hitting the indie game dev community. It is this idea of creating one game a month for 12 months. That is, by the end of the year, anyone participating should have 12 games done. It all started with a blog post by one Christer Kaitila, aka McFunkypants, in which he described his effort to make one complete game each month in the year 2012. This article sparked a lot of interest from fellow game developers and ended up becoming a thing. It is also a full blown website as well. Complete with a full slate of gamification to help prod developers along.

Needless to say, this has sparked something within me and I am planning to rope my brother into helping me do this. As you know, We are still working on Demon’s Hex. It is not as done as it should be and I feel ashamed. So hopefully, this will help. I am not sure if I can complete it all by the end of January, so I may split my time between it and another game for the first couple of months. It all depends on how far I get in the first couple of weeks. So yes, Demon’s Hex is my first effort, but my be pushed for full completion a little later, while smaller games fulfil my challenges.

The idea of completing 12 full games is kind of daunting. However, the goal is to just get in the habit of taking something from concept to completion quickly and simply. That means no filler, just meat. Take a simple concept and run with it. You will be surprised what can be done. Take a look at some of the current submissions for the project. For example, McFunkypants’ first submission is a clever use of A* pathfinding. Placing barriers in the way of the two AI characters is the primary goal. Simple concept and a number of maps to fill it out. That is all that is required. Can the games be bigger fare? Sure if you have time to work full time. However, for me, it will probably be something smaller. Not like Dragon Punch or Dragon Fire small, but something in between that and Demon’s Hex.

For example, I have had one game idea floating around in my skull for several years. This is a politically themed editorial game all about raising awareness for Oklahoma’s horrid ballot access laws. The object of the game would be to collect enough signatures to gain recognized political party status in the state. With a new legislative session coming in and signature requirements at a high point following the Presidential Election, now would be a good time to get people aware so that they can pressure the state legislature to pass reform. I would just need to come up with a clever gameplay mechanic to not only demonstrate the trouble new parties face, but also frustrate the player.

Other game ideas are a more fleshed out Dragon Fire that turns it into a full fledge vertical shooter. Or a board game inspired on the Lego Heroica games I got for Christmas. Who knows where the year will take me. Perhaps within all these games we will find our first mega hit that gets us working full time for ourselves.

Regardless of what happens, the primary goal is to build a games portfolio for us to show off as we expand our company and seek funding from outside sources. So cheer us on and follow our progress over at my One Game a Month profile page.

Tiling Sprites With Flixel To Make A Map

So this week I have been working on something a little more closely related to Demon’s Hex. I want to get this done soon and feel that I needed to start working on some of the issues inherent in the original build posted on its page.

For 1, the game map is a static image with the nodes placed on top of it. This is not how I want the game to work. I want to be able to create a world via a tilemap, which Flixel has support for built right in. I wasn’t exactly sure how to go about doing this as all the demos and such on the Flixel site were for platformers. So I went searching for something that would work.

That is when I came across this tutorial for creating a top down RPG style game. That tutorial didn’t go into all the details of creating an RPG, but it did give me enough information to create the tilemap for my map. So I set about doing it. So I took the map image I originally had and I laid out a grid of 32×32 squares. Then I took a tally of what map components I had and then build a comma separated value list out of it.

So here is the map:

Demon's Hex Demo Map

Looking at this map, I came up with the following CSV list:

0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,
0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,1 ,5 ,5 ,5 ,2 ,0 ,0 ,0 ,0 ,0 ,
0 ,0 ,0 ,0 ,1 ,5 ,5 ,5 ,5 ,5 ,5 ,2 ,0 ,0 ,7 ,19,19,19,10,5 ,2 ,0 ,0 ,0 ,
0 ,0 ,0 ,0 ,7 ,19,19,19,19,19,19,10,13,5 ,9 ,19,19,19,19,19,8 ,0 ,0 ,0 ,
0 ,0 ,0 ,0 ,7 ,19,19,19,19,19,19,19,14,19,19,19,19,19,19,12,4 ,0 ,0 ,0 ,
0 ,0 ,1 ,5 ,9 ,19,19,19,19,19,19,19,14,19,19,19,19,19,19,8 ,0 ,0 ,0 ,0 ,
0 ,0 ,7 ,19,19,19,19,19,19,19,19,19,14,19,19,19,19,19,19,8 ,0 ,0 ,0 ,0 ,
0 ,0 ,7 ,19,19,19,19,19,19,16,15,15,17,19,19,19,19,19,19,8 ,0 ,0 ,0 ,0 ,
0 ,0 ,7 ,19,19,19,19,19,19,14,19,19,19,19,19,19,19,19,19,8 ,0 ,0 ,0 ,0 ,
0 ,0 ,7 ,19,19,19,19,19,19,14,19,19,19,19,19,19,19,19,19,8 ,0 ,0 ,0 ,0 ,
0 ,0 ,7 ,19,19,19,19,19,19,18,19,19,19,19,19,19,19,19,19,8 ,0 ,0 ,0 ,0 ,
0 ,0 ,7 ,19,19,19,19,19,19,19,19,19,19,19,12,6 ,6 ,6 ,6 ,4 ,0 ,0 ,0 ,0 ,
0 ,0 ,3 ,11,19,19,19,19,19,19,19,19,19,19,8 ,0 ,1 ,5 ,5 ,2 ,0 ,0 ,0 ,0 ,
0 ,0 ,0 ,3 ,11,12,6 ,6 ,6 ,6 ,11,19,19,12,4 ,0 ,7 ,19,19,10,5 ,2 ,0 ,0 ,
0 ,0 ,0 ,0 ,3 ,4 ,0 ,0 ,0 ,0 ,3 ,6 ,6 ,4 ,0 ,0 ,7 ,19,19,19,19,8 ,0 ,0 ,
0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,3 ,11,19,19,12,4 ,0 ,0 ,
0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,3 ,6 ,6 ,4 ,0 ,0 ,0 ,
0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,

You can see the shapings of the two islands in all that fairly well. If you want to know what all those numbers mean, well those are the placements of each tile in the sprite sheet the tile map uses. The first 32×32 square is zero and it goes from there.

Sprite Sheet for the Map

The buildings were easy, for at least this. I may change the way I am doing this in the future, but for now, I am just loading them as sprites and adding them to the scene. However, the trees and mountains were the tricky ones.

I had thought about just doing another tile map like I did for the land and water. However, I soon learned that would not be possible. You see, the sprites for the trees and mountains are 64×64 and I tile them out on a grid of 32×32. So that each one overlaps the one before it. That is not supported in the default Flixel. So I would have to extend the tilemap class if I wanted to get it fully working. I may end up doing this in the future, but for now, I decided to do something a little different.

First off, I created and array of arrays that represented the trees and paths (mountains have mountains, paths and caves). This included the location of each sprite and what it was. I then looped through the array and added a sprite to the scene for each time. This got the trees to display properly. Here is the code to get this working for the trees.

var trees:Array = new Array(new Array('T',6,3),
                            new Array('T',7,3),
                            new Array('T',8,3),
                            new Array('P',9,3),
                            new Array('T',5,4),
                            new Array('T',6,4),
                            new Array('T',7,4),
                            new Array('T',8,4),
                            new Array('T',5,5),
                            new Array('T',6,5),
                            new Array('T',7,5),
                            new Array('T',8,5),
                            new Array('T',3,6),
                            new Array('T',4,6),
                            new Array('T',5,6),
                            new Array('T',6,6),
                            new Array('P',7,6));

for each(var tree:Array in trees)
      if(tree[0] == 'P')
         sprite = new FlxSprite(tree[1]*32,tree[2]*32,TreePath);
           sprite = new FlxSprite(tree[1]*32,tree[2]*32,TreesImg);

Not too complicated, and it works. Each array inside the array has an element that tells the program what kind of tree it is, where it is located on the X axis, and where it is located on the Y axis. Those last two values are the grid location based on 32×32 grid squares, that is why those values are multiplied by 32 in the for loop.

I have a lot more that I want to do with this especially for the game. For example, this is just one screen. I want to be able to have several interconnected screens that will load as you travel through the world. But this is a start and that will come soon.

But just so you don’t miss out, you can see the finished tilemap program here: Tile Map Demo