WIP: PitSweeper 2

I’m working on a new Flash game. I’m about one-third of the way done, but it’s probably far along enough to put up a screenshot:

PitSweeper 2 WIP Screenshot

PitSweeper 2 is going to be the first sequel to a game that I’ve made, and I’m aiming to make it my most complete and polished one as well.

I’ve made a few games so far, and I feel that while I like to make games with interesting ideas, I don’t polish them as thoroughly as I could. With PitSweeper 2 though, I’m going to focus on execution and refinement; the fact that it’s a sequel helps.

My goal is to make this my first game to get a sponsorship before release, and so far I feel I’m going to do it.

Here’s an unordered list of improvements over the first game, and other comments:

  • A larger and non-square playing field, that makes it possible to have level layouts that are less abstract and feel more like a place you’d find on a map. The levels also have more visual detail like floor textures, and extra features like keys and doors, to give the levels a stronger sense of place.
  • More ambiguous sweeping. When I designed the first game, I wanted there to be more of a balance between sweeping and adventuring, and moments where you had to go through tense guessing games to avoid danger. However, I found that instead, it was possible to just surgically sweep, extracting treasures, avoiding monsters, and treating the game more like pure puzzle than a puzzle/adventure hybrid. So I’ve replaced the numbers with codes instead, that only tell the player if one thing or many things are nearby – to help encourage the adventuring side of the game.
  • Not only that, but I’ve expanded the altars and vending machines of the first game into their own class of objects called ‘Landmarks’. Landmarks automatically turn the sweeping marks yellow (the same as if there were both monsters and treasures nearby), making pure sweeping more difficult.
  • Uncovered monsters will ram tiles in order to get to the player, sometimes breaking them in the process – encouraging the player to sweep nearby themselves instead of testing far-off pockets of the map before moving.
  • Stats have been simplified. I’ve swapped out the D&D style dice notation for weapon damage and replaced it with simple ranges; I’ve also made the rules for how Speed and Power affect combat more straightforward.
  • I’m using Flixel instead of flash.display as my display engine. The game is using mainly bitmap and sprite graphics instead of mainly vector, and the overall look is much cleaner and crisper.
  • Not shown on the screenshot is a new Mana stat. As you sweep, you build up magic points, which you can cash in for various sweeping effects – for instance, remove all the squares next to a green mark, or reveal all the wall squares on a level.
  • Finally, PitSweeper 2 is going to have a proper story mode – with multiple dungeons, checkpoints, and cutscenes. Sweeper is an innocent yellow ball in an otherwise dark world – and his ability to sweep and sense also gives him the ability to connect with some awfully powerful figures..

That’s all for now. Next progress report will probably focus on the story and background of the game.

Advertisements

Securing a Flash game’s variables using flash_proxy

If you make Flash games, and you have a high score table, or some sort of community achievement system, you may want to make sure that people can’t cheat the system and put up fake scores or achievement reports.

For a Flash game, though, this can be difficult – there are easy to find tools, such as Cheat Engine, that can peek into the variables of your Flash game and their current values, and then change them to something more to the player’s liking.  A player does this by searching for a value that they can visibly see in the game, and finding any memory location that matches that value – and then searching again when the value changes, until the possible locations are narrowed to one.

Information about your game can be protected by keeping it on a server separate from the client game – however, since most Flash sites are portals in which individual designers submit their own games, and since they often submit their games to several different portals, security needs to handled at the client level instead.

One other possible way of protecting your variables is by obfuscating them – disguising them as some other value, or breaking up their value across several different variables and having the game recompose them when needed.

A handy method of doing this is taking advantage of a lesser-used feature of Actionscript known as the flash proxy.  A Proxy is a data type that’s a cousin to the basic Object – but it has additional abilities that let you define what happens when properties of the Proxy object are accessed or set.

This isn’t the same as setting getter or setter functions for an object property.  If you wanted to use getters/setters, you’d need to write a pair of functions for each property you wanted to obscure. A Proxy object lets you define what happens when any property is accessed or changed.

Here’s an example object that can be used to disguise numeric properties in a game. If someone wanted to poke around your game for variables to change, they couldn’t do a search based on the visible numbers; also, the functions are written so that the exact formula for disguising the variable’s value changes from game to game.

Notice the use of the keyword flash_proxy. This lets the compiler know that this special feature of Actionscript is being used.

package
{
    import flash.utils.flash_proxy;
    import flash.utils.Proxy;

    public dynamic class Obfuscated extends Proxy
    {

        private var _multiples:Object = { };
        private var _additives:Object = { };
        private var _subtractives:Object = { };

        private var _values:Object = { };

        public function Obfuscated()
        {
        }

        flash_proxy override function hasProperty(name:*):Boolean
        {
            return _hasProperty(name);
        }

        private function _hasProperty(name:*):Boolean
        {
            var propfound:Boolean = false;
            for (var n:String in _multiples)
            {
                if (n == name)
                {
                    propfound = true;
                    break;
                }
            }
            return propfound;
        }

        flash_proxy override function setProperty(name:*,value:*):void
        {
            if (((value is int) == false)&&((value is Number) == false)	)
                return;

            if (_hasProperty(name) == false)
            {
                _multiples[name] = (Math.random() < 0.5) ? 2 : 3;
                _additives[name] = (Math.floor(Math.random() * 100));
                _subtractives[name] = (Math.floor(Math.random() * 100000));
            }

            _values[name] = value * _multiples[name] + _additives[name] - _subtractives[name];

        }

        flash_proxy override function getProperty(name:*):*
        {
            if (_hasProperty(name) == false)
                return 0;
            else
            {
                var fn:* = _values[name];
                fn += _subtractives[name];
                fn -= _additives[name];
                fn /= _multiples[name];
                return fn;
            }
        }

    }

}

By creating an Obfuscated object and assigning properties to it, you can safely store and retrieve game information while keeping their internal values disguised.

Note that there are other pitfalls in securing game variables; for instance, if you have the game increase the player’s score by 100 every time a target is hit in a shooting game, a cheater might not be able to find the “score” variable, but might be able to track down the constant value 100 and change that instead. In that case, it would be a good idea to store the constants in a disguised way as well, and also take care how they are initialized:

function multiply(a:int,b:int):int
{ return a*b; }

var obfus = new Obfuscated();
obfus.amt100 = multiply(5,20);