Secret project part 3: On Hiatus

As is goes, Secret Project’s development is currently frozen. It has been for the last two months, actually. Not super for the project, but good for the company.

We decided to freeze development right after coming back from Gamescom, because a big contract got signed and we needed everyone on that job to get the ball rolling. Additionally, since the signed project is in the roughly same genre as Secret Project, it would look bad releasing it while initial development was going on on the other one.

And yet, this may turn out to be for the best after all. I am able to take a few steps back on the design and look at it with fresh eyes (the time before Gamescom was pretty crazy in that regard, we completely overhauled the look of the game in 4 weeks!), and we’re also getting to develop some finer technical infrastructure that I hope will carry over to Secret Project once development resumes.

Meanwhile, we’re also getting good vibes from the few people we showed the alpha to in GC, and I still get to go ahead and fill the backlog while no one’s looking to sneak in more important features.

I hope to report back soon with part 4: the Thawing!

Secret Project part 2: The Prototype(s)

After getting the pitch shortlisted, our first task was to actually prove that the mechanic was viable ASAP. This was a rather unique challenge compared to other selected pitches, since they mostly had to build a regular First Playable.

We had two weeks to make it work. I’m kind of freaking out thinking on how to actually get the mechanic implemented in networked multiplayer under such a short deadline. The project would have most certainly failed its first milestone if it weren’t for the heroic arrival of… El CTO! *cue Mariachi fanfare*

Continue reading

Secret Project part 1: Threading the needle

There have been …interesting… developments at work with some clients, the result of which ended up in our doing a company-wide brainstorm for ideas, geared towards internal development and eventual publication.

One of the selected projects is an idea I pitched, and I now find myself at the lead of that project, one with a very nerdy mechanic.

I kind of need to tell someone of how that goes, even though if I cannot yet share what the project is.

So, here is what has been happening so far…

Continue reading

Using BitmapData.threshold()

Since one of my objectives is to be able to publish this yet unnamed game to the web, one of my main concerns is keeping the total download size low, relying on as little static art as possible.

One cool thing I’ve always wanted to try out is palette swapping: basically you take the same bitmap and you replace color values to change the way it looks. Most widely known for its ability to recycle the same beat’em up enemy in several levels by changing pixel colors without requiring a whole new bitmap being stored on the ROM.

In my case, I use it for far more utilitarian goals: to signal player ownership of a given vehicle.

Thanks to openFl’s near perfect port of the flash API, BitmapData.threshold() is available. You give that method a source bitmap, a threshold color, a replacement color and an operation (==, <=, etc) and all pixels that match the condition will see their color set to the replacement color.

I added the color swap method right into my asset manager class:

 public function getColoredTank(p_color1:UInt, p_color2:UInt):BitmapData
 {
 var coloredTank:BitmapData = baseTank.clone();

 //apply first color, replacing Magenta (0xFFFF00FF)
 coloredTank.threshold(
     coloredTank, 
     coloredTank.rect, 
     coloredTank.rect.topLeft, 
     "==", 0xFFFF00FF, p_color1);

 //apply second color, replacing Yellow (0xFFFFFF00)
 coloredTank.threshold(
    coloredTank, 
    coloredTank.rect, 
    coloredTank.rect.topLeft, 
    "==", 0xFFFFFF00, p_color2);

 return coloredTank;
 }

This allows me to turn this:

TEST

Into these:

Workspace 1_004

Both tanks in the bottom image share the same source bitmap.

Since I’ve had some fun playing with this, I decided to see about allowing players to set their own color preferences for their vehicles, which might be a nice touch in multiplayer.

Borrowed time

The recurring problem when working on such a project on borrowed time: coding in & hour increments, between 1 and 2 a.m., if the kids don’t wake up.

About awe6

For this project, I decided to use awe6 as an underlying framework to the game.

It’s a mashup of many different design patterns I was unfamiliar with when I began, and it served as a very good excuse to learn about that.

Other than that, it makes almost 0 assumptions about what your game looks like. Theoretically, it could even be used for 2d and 3d games, but I have yet not found a concrete example of the latter on the web. Who needs 3d anyways, right?

I looked at haxeflixel and haxepunk, but those frameworks are heavily slanted towards making arcade-y games. If you choose another path, you will have all that leftover code lying around doing nothing.

Yes, I’ve had to reinvent the wheel with awe6 a couple of times (I’m looking at YOU, drag&drop!), with the benefit of having learnt something about wheels along the way.

Anyways, I can already predict there will be a point in the future where I will curse myself for going with that framework for X or Y reasons. The most important thing for me to remember when I hit that rough patch is not to give up so easily!