Month: November 2012

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.

Experiment Number 2: A Single Screen Shooter

Dragon Fire

Continuing with my experiments in Flixel and the Flixel Power Tools, I have put together Dragon Fire. It is simple shooter game. You play as a dragon protecting your nest from invading monsters. Don’t read too much into it. The game was just to help me play with a few more features of the Flixel Power Tools.

I am really enjoying this time exploring these great Actionscript libraries. The people who developed them are really talented and I hope to be able to provide similar tools for aspiring programmers in the future.

One thing I would like to mention about this game is the importance of balance. During development I spent a fair amount of time playing around with the number of fireballs, the time between firing, the number of enemies, and the speed of the enemies. Each of those played a key part in the overall balance of the game. Set one too lenient and the over all game was way too easy or set one to restrictive and the game was too hard.

For example, as I was working on the game, I had only a single enemy coming at any given time. No matter how few fireballs I allowed and how long between firing them, the game was way to easy. I couldn’t make a fun and challenging game with just one enemy at a time. So I added two and the whole game changed. Now it actually mattered how many fireballs I allowed. Now the rate of fire mattered.

I can only imagine the work that a much larger and more in depth game would require to properly balance it. As I look around at the vast number of shooters with their varying types of enemies, enemy behaviors, player power ups, life meters etc, I stand in awe at the time it takes to properly balance such a game. Even them, you could completely throw off the game by making one too powerful attack or one too powerful enemy.

That is just the beginning. Think of the tremendous balancing work that goes into an RPG like Final Fantasy or Torchlight. Or a card game like Magic: The Gathering or Pokemon. These games have far more intersecting elements that require a fine tooth comb when balancing. For example, Magic once had a card called the Black Lotus that made the game super easy for players of Black decks. The card had zero cost to play and could be tapped for three mana. This allowed the player of such a card to completely dominate the game early if he got it in play in the first hand or two. That was just one card out of thousands.

Anyway. I hope you enjoy this small game and the discussion i have found in making it.

Making Games While Experimenting With Flixel

First of all, I am sorry for the lack of updates. I have been busy with a variety of things that have held me up. I wanted to be way farther along with Demon’s Hex than I am right now. That is really frustrating to me and I know to those of you who want to see the game made. Part of my frustration is with the limited knowledge of the Flixel engine i am coming into this with.

For a little background, I graduated with a degree in game design. I have not really been putting that into use the way I should have been. Since graduating, I have been working in web development as an employee of government contractors. Not really the best use of my talents. So I have been working in my spare time whenever I could. But it never seems to be enough.

So in order to help me learn Flixel better and do a better job programming Demon’s Hex and get it to be th best game I can get it to be. The game you deserve. So I am working on a number of smaller games to help me familiarize myself with Flixel and the Flixel Power Tools created by PhotonStorm.

You can play the game, Dragon Punch. Nothing special. A simple Duck Hunt style game starring dragons.

Dragon Punch

So this is what I am working on right now. After a few of these types of games, I will most likely feel much better about my game programming skills that I will make some heavy progress on Demon’s Hex.