Archive for Development

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 Ouya.tv. 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);
      }
      else
      {
           sprite = new FlxSprite(tree[1]*32,tree[2]*32,TreesImg);
      }
      add(sprite);
}

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

DRM Is Evil. Game Maker Has Horrible DRM. Game Maker Is Evil.

Game Maker DRM is EvilI will never understand why companies continue to insist on using DRM. It makes absolutely no sense to punch your paying customers in the gut, call them pirates and tell them to stop stealing your stuff. These are your paying customers. They paid you. Why would you insist on treating them like thieves?

DRM is absolutely one of the most evil inventions in software. If you read anything I write here or elsewhere, you will know how I feel about DRM and companies that use it. I will never use it in any game I develop nor would I be willing to deal with DRM as a consumer. As a Linux user, I have to deal with the fallout from DRM on a most everyday basis. I am not legally allowed to watch DVDs on my computer. I couldn’t until recently watch Netflix on my computer. (I only can now because some very clever developers not affiliated with Netflix made it possible.) And many games will not run properly even through Wine because the DRM is incompatible. All these things have soured me to any company that uses it.

That is why the recent news of Game Maker’s absolutely disgusting DRM implementation has me gagging. YoYo Games goes so far beyond what most companies do with DRM that they are beyond redemption. This company has designed their software that if it so much as gets a hint of you being a pirate, it will permanently vandalize your game project. Seriously. They will force images of the Jolly Roger onto all your sprites in a bid to shame you into… what… paying? Paying for software you already paid for? That is the kicker. The people getting hit by this “retribution” paid for the software. They are not pirates.

The problems with this DRM seem to be so bad that the only way to recover from it is to completely uninstall Game Maker, delete every last trace of the program from your computer and reinstall. That is absolutely unacceptable. So not only is the developer out the time it take to clean up their computer and reinstall the software, they also have to spend days possibly weeks restoring their artwork. For what? They privilege of paying? I am sorry. That is evil.

To make matters worse, according to one former paying customer, they have absolutely horrid customer service that will at the earliest possible moment, accuse you of piracy. Then they will treat you like crap and silence you if you try to complain. No. That is wrong on every level.

I had long ago made the decision to not use Game Maker in my game development work. Primarily because it lacks support for Linux. But this seals the deal for me. I will never recommend this tool for any game developer, ever. I will never willingly submit anyone to such destructive and abusive developers. No one deserves to have their hard work destroyed in that way.

It doesn’t even matter that YoYo has promised to strip out that particular action from the DRM. Why? Because they will continue to rely on other just as bad if passive attacks on you the paying customers. It is time that this company felt the pains that come with such tactics. They need to lose business. Those using the tool, need to stop. There are plenty of other great tools available that you could use. I have talked about several. There are many more that I have not talked about.

We just need to stop supporting DRM using companies altogether. If they insist on treating paying customers like trash and thieves, they do not deserve our business. They deserve to fail. That is all there is to it.

Play Testing: It Just Might Be Important

Dragon Fire

Why can’t I fire?????

Over the weekend, I released the oh-so-clever and distracting game Dragon Fire. The game probably took me a total of 12 hours to program thanks to the awesome suite of tools in the Flixel game engine and the Flixel Power Tools. (I seriously cannot stress how awesome these are). However, even when programming something as trivial as Dragon Fire, it is always important to do thorough testing.

I have already updated the game on the site, but if you managed to play the game before today but if you play the old version which I listed second on the game page, you would  notice that sooner rather than later, your dragon lost the ability to spit fire. From a fresh load of the page, you would not have noticed this. This bug only reared its head if you selected the “Play Again” option in the game over screen. During my program and testing modes, I never really tested this extensively and so never noticed the bug.

It was only after I uploaded what I thought was the finished build of the game that it was noticed by my brother and co-developer Willis. He told me that certain dragons could not fire. This confused me initially as I did not program the game to have specific fire capabilities for specific dragons. So I started really looking into it and found that bug in the game. Once I found it, it came time to fixing it.

This is where things can get hairy. I am still learning Flixel and the Power Tools, and so my ability to debug games based on it is still building. So it took me probably around 4 hours of Google searching and code crunching to find it. If you really care, the problem came about by me forgetting the line “FlxControl.clear();” in my play state’s destroy function. This function has the exciting purpose of cleaning up the keyboard controls when the game is ended. Without it, the game gets confused and muddled and loses the ability to function properly.

All that is beside the point though. The point is, that no matter how simple a game is, it is always important to play test it. Not just you, however. You should try to get a third party in to test as well. Someone who is not as close to the project as yourself. Someone who will play the game in a way that you would not. As you see, while I tested to make sure the game started over upon selecting “Play Again”, I did not properly test that the game continued to play as expected upon playing again.

Of course, this is all avoiding the most important aspect of play testing, the impact on you the gamer. You have all played games recently, whether browser based, PC or console, that have glaring bugs that only a blind, deaf and mute person could miss. These bugs that break your immersion in the gaming experience and drive you nuts. Proper play testing helps avoid all that. It is up to us the developer to make sure that you the gamer has the best experience possible when you pick up our game. Our paying (or in some cases non-paying) customers should never be forced to participate in a beta-testing experiment. Unfortunately, many game developers force you into that role. That is a disservice to you. It is one thing to invite you into a beta experience, but a completely other thing to trick you into one under the guise of playing a finished product.

Final verdict, play test and play test again. When you think you are done, play test some more. Only then can you release the best game possible, which gamers deserve.

A Udactious Look At Python For Gaming

Making Games With Python and Pygame

In my efforts to get game programming further under way, I have been busy going back to school so to speak. I have been in web development for so long, I have all but lost my touch in adapting to new programming styles and projects. Since most of what I have done over the last 5 years has been almost nothing but form handling , I have all but forgotten what it means to program something as dynamic as a game. So I have decided to not only work on Demon’s Hex via Actionscript and Flixel, but explore a new language and library as well.

In deciding what language to take up, I stumbled across a new venture called Udacity. This excellent online curriculum for computer science (and more too) has been a great resource for me. They have courses on Algorithms, AI, Physics and more. All the programming courses are based on the Python scripting language. but the processes and ideas are universal.

As I spent time taking the Intro to Computer Science course, I have grown a fondness for Python and what it can do. The potential for such a language is excellent. As I grew to love it, I decided to see what it has to offer for a game developer. Knowing the game development scene and hobby, I figured that someone out there has already put Python to the use of making games and I was not disappointed.

Enter Pygame. This game engine seems to be a powerful engine for making any number of 2D games. The library, much like the nature of Python itself, is cross platform for Linux, Mac and Windows. There are also many people out there working to port the games to Android and Iphones. So it could be a great engine for what we have planned once Demon’s Hex is done. Shoot, it might also be what we use to bring Demon’s Hex out of the browser and onto phones.

There is also a really great and free book on using the Pygame library. I am always a sucker for books. Of course it is only free if you don’t mind getting the PDF version. The paper book will cost some money, which is fine by me. I have run through the first couple of chapters and played around with it. The book is a good introduction to Pygame. However, you should be familiar with Python before you dive into this book, which is where Udacity comes in. Or you could also look at the Invent with Python book by the same author, which introduces the reader to Python..

Beyond 2D, there are also plenty of options to make 3D games with Python. For example, the popular and free 3D modeling software Blender uses Python in its game engine. Another engine I have looked into is Panda3d. This one isn’t as full featured as I would like, but it does hold a lot of promise. I am sure there is more out there.

I can’t wait to really dive into Python programming on a much larger scale.

Cross Posted to Oklahoma Game Developers.

2012: The Year Of The Linux Game

Tux the Penguin: Linux MascotThere are a lot of claims that a certain year is the year of something. The year of the PS3, the year of the mobile, etc. Many people make these claims long before anything truly remarkable happens and pretty much all of them fail to live up to their expectations. So rather than look forward and make predictions about whether a certain year will be the year of the Linux game, I am rather going to look back at the last few months and proclaim that 2012 is the Year of the Linux Game.

It seriously took a long time and a lot of trouble to get to this point. Game developers have dismissed Linux as a viable platform and have ignored the pleas of gamers for Linux support. For many years, Linux gamers have resorted to rolling their own solutions for gaining Linux compatibility in the form of emulators and compatibility wrappers. Some companies have sprung up in the past in the hopes of expanding the availability of Linux games, but have failed due to poorly thought out business strategies. So what makes 2012 so different from all the previous years?

The first step in making this year the year of the Linux game was the introduction of the Humble Indie Bundle. Originally the brainchild of Lugaru developer Wolfire Games, it made it a requirement for inclusion in the bundle to have native Linux support. This bundle has gone through five primary incarnations and numerous brand specific bundles. All of them included Linux support for the games. As a response for this inclusion, Linux gamers have paid on average far more than Windows and Mac gamers and have made up anywhere between 15 and 25% of all payments to the bundle.

Humble Indie Bundle #1 Stats

The final sales stats for the original Humble Indie Bundle.

The next major shift towards developer support for Linux gaming was Kickstarter. While Kickstarter was a lot slower on the draw for its influence on Linux gaming, it has really shown its power to shift trends in that direction. Recent high profile games such as the Double Fine Adventure, Wasteland 2 and Shadowrun Returns have revitalized the desire to not just  add Linux support as a reward for exceeding funding goals but also as a primary selling point for funding. The number of game projects on Kickstarter supporting Linux has done nothing but grow. A recent Ubuntu Forums post highlights dozens of game projects that support Linux.

Because of these successful Kickstarter campaigns promising Linux support, we have also seen a major shift in middleware providers as well. With the success of the Wasteland 2 project, Unity3d will be adding support for exporting games to Linux with version 4. This was something that developers have been requesting for several years. It is now happening because of this shift in the market. Another high profile Kickstarter game, Double Fine Adventure, has also resulted in the addition of Linux support for the growing 2D engine, Moai.

Finally, we have also seen the largest digital distribution service for games making the shift toward supporting Linux. Yes, I am talking about Steam. Valve had recently released a Mac client for the Steam platform and with it came many rumors that Linux support was in the pipeline. Earlier this year, Valve finally came clean with the news that, yes, a Linux version of not just Steam but also its Source Engine was coming. The largest digital distribution platform in gaming history is making its way to the smallest PC market. If that is not validation of Linux as a viable platform for gaming, I don’t know what else could convince you.

So with all these events in the last few months, I am confident to say that, yes, 2012 is The Year of the Linux Game.

Slow And Steady: Game Development Plodding Along

Game development is plodding along. Certainly, not a fast as I would like it to be. I have been trying to work in as many hours as possible into the game as I can (I hate to make excuses) but between my full time job and my family, some things just have to take a back seat. But there is some progress. There are also a number of problems.

I have been trying to get the tokens in the game to load in dynamically. I want to be able to add new tokens to the game without the need to recompile whenever I do. So I have implemented a call back to the server to request all the tokens in the player’s inventory. Things are working fairly well for this, but I am hitting some issues.

First among the issues was Flixel’s lack of native support for loaded graphics. Flixel was designed to work most efficiently with embedded graphics so I had to extend FlxSprite to implement support for loaded graphics. With that out of the way I hit a couple of other issues. You can see an example of them in the following snap shot:

Loading ProblemsThere are a few things wrong here, but one that is probably more noticeable to an outside viewer. You can see all the white stuff around the images. For some reason, when I load the images from the server, I get a lot of white around and over the graphics. It was a lot worse before I switch everything but the character art to use embedded images. I don’t think this is a problem with Flixel as I have seen something similar with other games. It may be a problem with Flash running on my Linux development computer. I remember being able to fix it before, but can’t remember exactly what I did. Since Flash has been upgraded as well, I don’t think that fix would work with this version. I still need to test this on another computer.

The second issue here is that of the character images stacking on top of each other. This one is a little more frustrating and seems to have more to do with the fact that Flash is loading them way to fast for it to render properly. I think I can get rid of this issue by using a utility called LoaderMax to help me load them up correctly and before I add them to the tokens. Again, I also had this issue with the sword and shield icons as well when I was loading them from the server rather than embedding them into the swf object.

The final issue is that of the big fat zero for the attack (and nothing for the defense). Each of these tokens have an attack and defense value that is a positive number. But for some reason that value is not making it from the database to the game. It might be an issue with the xml file created or the conversion from a string to an int back to a string. I am not sure yet.

So that is the major news for now. I wanted to let you know that, yes, we are working on the game. I plan on having something playable before Indiecade. It is a prerequisite for me. I am not going to go there with nothing to show those in attendance. It will make it.

Thank you again for your time. If you are interested in making a financial contribution toward getting this game made (so that I can devote some extra time towards it) I wrote about some ways you can do that on my personal blog.