Archive for Development

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 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.