Facebook Twitter RSS
formats

Sequels

Published on April 17, 2013, by in Games.

Sequels. I get requests for a sequel to something, like, every day. You ask for a sequel to:

  • 400 Years,
  • A small talk at the back of beyond,
  • Deep Sleep.

Let’s get through this together:

400 Years is a closed, complete story. I understand people like the idea and the game mechanics. I also understand people are disappointed by the length of the adventure.  Last time I said I’m not planning to make another instance of 400 Years – not because I don’t like the game or something, but mainly because I want to develop other ideas that I have. But, well… Seeing how many people want to play more of time-delaying game I might reconsider this decision. Although, still – a sequel is not very likely at this particular point. Maybe I’ll return to this later, with more experience gathered?

 A small talk at the back of beyond. Well, what can I say. No, there will be no direct prequel/sequel to this story. No additional endings because what is already there builds the entire story. Adding more would just render everything flat and pointless. BUT that doesn’t mean I’m not planing to explore the field of adventure games of this kind. I mean not standard point-and-click kind. I have some ideas that are – in my opinion – both original and interesting and I think you’re gonna like them. Will it be a typing-game? I’m not sure yet. But it’s going to be “different”.  Sadly, you’re not going to see it before summer – I have a queue of games that I need to finish before I start another project (but frankly speaking, I’m tempted to throw everything away and focus on this one).

Deep Sleep. This is the one you don’t need to ask for. Yes, there will be a sequel to Deep Sleep. It is currently in production. Well, it has been since December, haha. But other projects – like 400 Years and A small talk – postponed it a bit.

I’m probably not going to make my version of Mateusz Skutnik’s workshop progressbar thingy (unless you really want me to :D) but if I had to do a quick summary:

  • [▓▓▓▓▓▓▓▓▓▓] 100% Story
  • [▓▓▓▓▓▓▓▓▓▓] 100% Puzzles
  • [▓▓▓▓▓▓▓▓▓░] 99% Locations art – (still needs few adjustments here and there)
  • [▓▓▓▓▓▓▓▓░░] 80%  Animations
  • [▓░░░░░░░░░] 10% Items art
  • [▓▓▓▓░░░░░░] 40% Sounds
  • [▓▓▓▓░░░░░░] 40% Ambients
  • [░░░░░░░░░░] 0% Engine updates
  • [░░░░░░░░░░] 0% Coding

It might look as I’m hardly halfway there but it’s not that bad – locations art is what takes most of the time, at least that was a fact with Deep Sleep 1. Additionally, this time I already have working point-and-click game engine, I just need to update it a bit.

When are we going to see next part of Deep Sleep?

Difficult to say. I was hoping to finish it in April but now that’s impossible. So the next possible deadline is: end of May/first days of June.

As for now, I have 2 teaser screenshots for you. Enjoy! :)

preview2

preview1

formats

One Way Dungeon

Published on April 12, 2013, by in Games.

One Way Dungeon

My recent game, One Way Dungeon, can be played on Armor Games and will be available on other portals next week.

The game itself – despite its simplicity – was another little experiment. This time I was checking two things:

  • How fast can I make a  decent, playable game
  • How good will it be

I’m not into Ludum Dare or game jams simply because I don’t work very fast. But as the March’s #1GAM deadline was getting closer and my current game was nowhere near finished, I decided to start a new project and finish it ASAP.

I never wanted this game to be innovative in any way, on the contrary – the idea was to create something straightforward (what can be more straightforward than a game with “One Way”  in its name, haha). Entertaining and challenging, a no-brainer requiring just some skill to play.

Perhaps I needed a break from the deepness of other games I was making.

The idea had to be simple – and one of the simplest games out there are avoid games. Making the dungeon procedural-generated helped me a lot, because it saved me lots of time that I would otherwise spend on designing the level. This was, in fact, the most interesting part of the creation process – to design a semi-random pattern of obstacles that will always be possible to pass. Always. There are no no-win scenarios, it’s all calculated – if you fail it means you just weren’t fast enough.

Infamous combo – enemy standing next to a pit – can be beaten if you properly time hitting ‘chop’ and ‘jump’ buttons.  And if you run in the top lane and the path switches to the bottom lane – you can totally make the turn if you do it fast enough. Even on the highest difficulty – why and how? Because the faster you run forward, the faster you move sideways.

screenshot-640x360

I started on Friday evening and the game was somewhat playable on Sunday evening – but it wasn’t anywhere near the finished state. I’ve spent over a week more on tweaking and polishing it.

I’ve been building my own framework for some time and now I know what needs to be improved: UI management, all the menus screens and buttons – surprisingly it takes huge amounts of time to implement. This is because – like most of devs out there, I think – I postpone the “add main menu” task until the very end. 

This was a valuable experience for me, as I’ve learnt how fast can I work and how much time polishing the game takes vs. making the actual game.

And please – don’ t take this little game too seriously :D Just have fun playing

OR DIE TRYING HAHAHAHA

formats

Game lags on Chrome – solved?

Published on March 12, 2013, by in Tutorials.

EDIT: Well, it seems that the problem goes deeper than just that – while this article resolves part of the issue, there are other things that may cause framedrops on Chrome/pepperflash that I haven’t yet identified.

Some of my games have this sad problem of not working very well on Google Chrome browser because of mysterious framerates drops. Yesterday I’ve found what seems to be a reason of this issue… so if you’ve ever bothered with your Flash not working well under Chrome browser, keep on reading!

 

What exact issue does this post tries fix?

My problem with Flash performance under Chrome was – as it turned out – connected with using BitmapData objects. So, since there is probably more than one problem with Flash on Chrome, if you’re not using BitmapData anywhere in your code, this might be not for you :(

 

BitmapData is fast as hell, but its birth is pain for Chrome

There, the heading nails it. It seems that the Chrome performance problem (like with 400 Years) is caused by creating BitmapData objects.

Here is some meat, I know you’ve been waiting for it:

 

The code

(I’m also attaching source files of this project, so you can play with it yourself.)

First, let’s set up a simple AS3 project with a single Bitmap object on stage. This bitmap will be displaying a BitmapData object. We will need one more BitmapData for the showcase.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private var bitmapData:BitmapData;  // main BitmapData
private var bitmap:Bitmap;    // main Bitmap
private var squareBitmapData:BitmapData // BitmapData for color squares
 
private function init():void 
{
  bitmapData = new BitmapData(stage.stageWidth, stage.stageHeight, false,
    0x000000);
  bitmap = new Bitmap(bitmapData);
  addChild(bitmap);
 
  squareBitmapData = new BitmapData(2, 2, true, 0xFFFFFFFF);
 
  addEventListener(Event.ENTER_FRAME, loop);
}
private var bitmapData:BitmapData; 	// main BitmapData
private var bitmap:Bitmap; 		// main Bitmap
private var squareBitmapData:BitmapData	// BitmapData for color squares

private function init():void 
{
	bitmapData = new BitmapData(stage.stageWidth, stage.stageHeight, false,
		0x000000);
	bitmap = new Bitmap(bitmapData);
	addChild(bitmap);

	squareBitmapData = new BitmapData(2, 2, true, 0xFFFFFFFF);

	addEventListener(Event.ENTER_FRAME, loop);
}

 

OK, so we have our bitmap on stage and we have added a listener that will call loop() function on each frame. This function will simulate complex 2D graphics operations by calling a certain method 500 times :-)

 

1
2
3
4
5
6
7
8
9
10
11
private function loop(evt:Event):void
{
  bitmapData.lock();
  for (var i:int = 0; i < 500; i++ )
  {
    // call EITHER methodA() OR methodB()
    methodA();
    //methodB();
  } 
  bitmapData.unlock();
}
private function loop(evt:Event):void
{
	bitmapData.lock();
	for (var i:int = 0; i < 500; i++ )
	{
		// call EITHER methodA() OR methodB()
		methodA();
		//methodB();
	}	
	bitmapData.unlock();
}

 

Both methods – A and B – do the following: draw a picture on our main bitmap. To make things simple, our “picture” will be a 2×2 bitmap with a random color and random alpha.

Method A takes our squareBitmapData object that we have created before and fills it with a random color. Then it uses copyPixels() to put the result pixels in a random spot on our display.

1
2
3
4
5
6
7
8
9
private function methodA():void
{
  squareBitmapData.fillRect(squareBitmapData.rect,
    Math.random() * 255 * 255 * 255 * 255);
 
  bitmapData.copyPixels(squareBitmapData, squareBitmapData.rect,
    new Point(Math.random() * bitmapData.width,
    Math.random() * bitmapData.height));
}
private function methodA():void
{
	squareBitmapData.fillRect(squareBitmapData.rect,
		Math.random() * 255 * 255 * 255 * 255);

	bitmapData.copyPixels(squareBitmapData, squareBitmapData.rect,
		new Point(Math.random() * bitmapData.width,
		Math.random() * bitmapData.height));
}

 

Method B creates its own local BitmapData object with a random color.  Then it uses copyPixels() to put the result pixels in a random spot on our display.

 

1
2
3
4
5
6
7
private function methodB():void
{
  bitmapData.copyPixels(new BitmapData(2, 2, true,
    Math.random() * 255 * 255 * 255 * 255), new Rectangle(0, 0, 2, 2),
    new Point(Math.random() * bitmapData.width,
    Math.random() * bitmapData.height));
}
private function methodB():void
{
	bitmapData.copyPixels(new BitmapData(2, 2, true,
		Math.random() * 255 * 255 * 255 * 255), new Rectangle(0, 0, 2, 2),
		new Point(Math.random() * bitmapData.width,
		Math.random() * bitmapData.height));
}

 

The result – let the FPS speak

Perhaps I’m just stupid. Perhaps it should be an obvious thing right from the start that creating new objects instances is time-consuming activity and will kill performance.

…But it doesn’t do that.

At least on browsers OTHER than Chrome.

See for yourself: I’ve added a simple FPS counter to the previous example.

 

Method A – should have good performance on all browsers Method B – if you’re using Chrome it will probably lag as hell.

The project is published to run at 60FPS.

If this example doesn’t work for you or you don’t have both Chrome and other browser installed, here are some screenshots:

Method A - Firefox Method A - Chrome
Method A – using single BitmapData for each iteration

 

Method B - Firefox Method B - Chrome
Method B – using new BitmapData for each iteration

There you have it. Instead of nice and smooth 60 frames per second, we barely get 16 fps, which is of course unacceptable.

 

Why is it different on Chrome?

Why would Flash work differently on Chrome? If you’ve ever had problems with it, you probably already know this one – Pepper Flash plugin.

pepper flash plugin

While other browsers use Flash Player installed from Adobe’s website, Chrome has its own plugin that is automatically updated.  How cool is that?

Not cool at all, especially that Chrome’s Pepper Flash isn’t particularly good Flash player – even according to Google Search that will point you to the most relevant results like  “How to disable Pepper Flash”  ;-)

Even worse thing – it sets itself as a default Flash player. What can you do about that?

As a user? Disable it and keep disabling it after each Chrome update (yes, it switches back without asking you).

As a developer? Nothing. You can’t expect your users to all disable Pepper Flash plugin. If you’re lucky, maybe 1% of your audience manages to do that. Others will rate your game 0/5 because it doesn’t work fast enough for them.

Sadly, the only solutions to all Chrome problems are:

A) find little pesky details and use workarounds

B) wait for Google to fix it.

Which option is more realistic and probable – guess yourself.  Maybe it’s all a part of Google’s secret master-plan to kill Flash  :roll:

» Click here to grab source files «

FPS Counter by kaioa.com