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.

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);

The secret of Princess Rosalina

This post is a copy from my old blog at kinsmangames.com.  It was the most popular post there by far; so, while I decided this blog would mostly start fresh, for this one post I decided it would be best to save a duplicate.

In an interview with Yoshiaki Koizumi, the game director for Super Mario Galaxy, he once talked about how Shigeru Miyamoto, the project’s godfather, wanted him to take the storyline of the game and scale back its presence – make it more minimalist and background.

He did – the story of Princess Rosalina, the Lumas, and the Comet Observatory in the final game are background elements, touched briefly upon at the beginning and end of the game, with a optional small story in the game’s “library” that you can unlock as the game progresses.

But when he did that, he buried a secret deep inside the game, about Princess Rosalina’s true origin.

The storybook in the library tells a fairy tale; about a girl who saw a spaceship crash one day, that contained a Luma who was looking for his lost mother.  She joins him on his search, and eventually, the two of them become lost in the universe together.  They promise to take care of each other, and build a new life in a castle on a blue comet; other Lumas join them, and soon the girl is the foster mother of a whole crowd of Lumas.

Most players slowly figured out that the story of the girl was actually the origin story of Princess Rosalina as they watched the story unfold, and the last two chapters of the storybook, accessible when you complete the game, more or less prove it.

But inside that storybook is something odd.  Chapter Four, “The Dream”.  The girl – young Rosalina – has a dream that’s also an omen about her losing her mother back on Earth.  We only get to see her mother’s face once, the lower half only –

Is that Princess Peach?And looking at her earrings and hairstyle, it’s obvious Rosalina’s mother is Princess Peach.  But – it’s just as obvious that this couldn’t be Princess Peach; in the main game, her and Rosalina are the same age, and Peach never had any children anyway.  (Not even Bowser Jr. in Super Mario Sunshine.)

So, players seeing this for the first time will either shrug and forget about it, or never even notice the resemblance in the first place.  It’s a piece of trivia that goes nowhere, until the end of the game, when the second strange thing happens.

Well, actually, the “strange thing” is the whole ending itself.  Super Mario Galaxy’s ending is pretty spectacular.  Bowser’s huge lava planet at the center of the universe implodes, creating a massive black hole that threatens everyone there – Bowser’s army, the Comet Observatory, Peach’s castle, and all the main characters.

They’re rescued when all the Lumas pour themselves into the black hole, transforming it into something resembling the Big Bang.  They all come out as newborn stars, and Rosalina explains: stars turn to stardust, and then form again as new stars.  “But the cycle never repeats itself in quite the same way…  So.. you’ll see.”

Mario, Peach, and Bowser all wake up back on their home planet and the Mushroom Kingdom, to find that it’s been transformed and “remixed”, with all the characters they’ve met on the journey taking up residence in the Mushroom Kingdom.  The voice of Rosalina explains that all life, not just planets, come from the essence of stars, and Mario joyfully shouts, “WELCOME!  WELCOME NEW GALAXY!” as the camera zooms out of the atmosphere to show the newly created galaxy the Mushroom Kingdom is now a neighbour to.

But the cycle never repeats itself in quite the same way..Nice ending, and surprisingly heavy for a Mario game.

But did you remember that single page in Chapter 4 of the storybook?

If the cycle of the universe repeats itself in mostly the same way, Princess Rosalina’s origin becomes clear…

She’s the daughter of Princess Peach from a previous cycle of the universe.

That Princess Peach was the loving mother of a family with two children, and she died sometime after her daughter disappeared, following a lost Luma around the universe.

In another interview with Koizumi about Super Mario Galaxy, he explained that Princess Rosalina was originally intended to be related to Princess Peach, but they changed her to be an unrelated character later in development.

This, it turns out, is only half-true.  She’s not related to the current Princess Peach, true; but here, we see the remnants of the previous idea, turned into a secret that’s been buried deep into the game’s minimalist story.

When Miyamoto asked Koizumi to scale back on the game’s storyline, I wonder if this is the effect the two of them intended?

And when Princess Rosalina says, “So.. you’ll see..” what did she mean by that..?

There's something I'd like to give you..