Archive for the ‘FlashGameBlogs’ tag

Palisade Guardian – the new instalment

Our good friend Mark Loika has made available the beta version of Palisade Guardian 3, a game I had the pleasure of making the art for.

I must say its my favorite of the 3. The guns feel really nice and the overall tone of the game is really my thing. It was a really fun project and I hope you all enjoy playing it.

Try it here:
http://palisadeguardian.com/

Marco (from VGS)

 

Posted: February 10th, 2012
at 6:48pm by Marco

Tagged with , ,


Categories: Caught our Attention,The art of VGS

Comments: No comments


AI problem with an elegant solution

Hi everyone, Vlad here!

I’m excited! It’s really nothing special but I had one of those eureka moments!

Here goes:

The problem

The current game has a number of mechanical hazards. To test the animations Marco designed I simply added a counter that would put the hazard on a waiting state and then run the animation. While the animation was running the hazard was on an attack state that checks if any actors are in the area it affects.

Easy enough but this had these problems:

1. In theory every hazard of the same type has the same loop. Game design wise suspension of disbelief fails.

2. In practice and since the game updates only part of the map what happens is that each hazard has its own loop but the level designer has no control over it.

3. To give a wider control to the level designer the game would need to update every hazard per frame… see the problem here?

The solution

What if most of the hazards had a central AI point? The first time we discussed something like this was when Marco and Pedro were working on Hajime. The objective was to have the AI army making better decisions considering the overall scenario instead of having each unit deciding the next move individually.

In this case we want that the most basic hazard behaviors to be the same regardless of being updated or not while maintaining the suspension of disbelief. The generic solution (we are considering having configurable groups and individual hazards still) is to have chained hazards based on their tile position.

I’m currently writing the class that will serve as the hazard commander. It is amazingly simple. The following code is almost pseudo-code and a very simple version of what I’m writing because there are several hazards and each has a different frame count.

1
2
3
4
5
6
7
8
9
10
11
12
public function update():void {
    // For each hazard
    frame++;
    if (frame == hazardTexture.collectionLength()) {
        chain = chain == maxChains ? 0 : chain + 1;
    }
}
public function getFrameOf(id:int):int {
    if (id == chain) return frame
    else return 0;
}

The commander is updated each frame. The code is pretty simple, it just increments the frame (not just one counter but one for each hazard type) and if the animation has ended it restarts and increments a chain counter.

Each hazard has a place in the chain. If it is on a part of the map that is updated, it will ask the commander what frame it should have passing its chain id. Even if it has not been updated recently it will update perfectly in sync with the rest of the game.

For this to be pretty and make sense and allow several automatic behaviors we have to understand what chain id means.

1
private var id:int = (tileX + tileY % maxChains)

Ok, looks simple, what does this mean? The graphic below is a capture of the spreadsheet where I tested the formula. The top left number is maxChains and in each cell is the chain id of each tile.

So if we have several hazards of the same type in a row, they will act in order, both horizontally and vertically. If there are a lot tightly grouped the player will see a diagonal movement giving a sense of some automatism behind the hazards which is a nice add-on since it fits the game.

But that’s not all, we can use the exact same code commander and give the hazards a different way of using their id. For instance we can have a method that will give an attacking frame to odd and then even ids making more active zones of the the map.

Ok… that’s simple, what’s the Eureka all about?

To be honest this problem was haunting me for a couple of days. I knew I wanted a central decision point (not really a big AI thing but still…) for most non-manually configured hazard for performance and consistency reasons. Everything I thought of was too complicated. Then I thought about this simple chain and the only problem I really had was to have a formula that would allow  a consistent behavior, like horizontal, vertical and diagonal chains. That little id formula was the eureka moment because it is so simple, so elegant and solves one major problem.

Like Einstein said:

Make things as simple as possible, but not simpler

Posted: February 10th, 2012
at 12:04am by Vlad

Tagged with , , ,


Categories: Dev Journal: Danger Zone,The code of VGS

Comments: 1 comment


Performance vs Error Checking

Hi everyone, Vlad here!

Seems like on a thing versus some other thing rampage with Application Design vs Game Design shortly followed by this post. I guess that’s a good thing, it means there are challenges and doubts and that we need to research.

This post is also inspired by some books I’ve been reading lately and that I highly recommend: The Productive Programmer that was influenced by The Pragmatic Programmer.

Problem #1

We are writing code and there’s not such thing as writing code without bugs. Sometimes our oldest, most used code, that code that we trust each of our games with gets into a specific spot where a hidden bug appears and we spend hours and hours figuring out what’s happening.

Solution #1 is Problem #2

There are several solutions to this. Writing code that includes testing is in my opinion the best. The problem with this, game development wise and specifically in scripted languages such as AS3, is that this makes the code much slower. The solution was checking for inconsistencies and not performing operations instead of throwing errors and exceptions.

I ended up creating conditions for use. For instance our blit package uses three different types: the core, the object and the texture. The core keeps the state of the whole system, the object keeps the state of what and where to render and the texture keeps the state of BitmapData. If the object did not have a texture it would simply not render. Sounds pretty cool, right?

To be honest… wrong…

Problem #2.1

First problem was the times where the position had NaN value instead of a Number. This rarely happened but every time it did it was a huge headache to identify why and then track the source of the bug down. While this seems unrelated, the fact was the it looked like the texture did not exist. So I had to check if the texture was created, if it was passed, if it was there at all and the worst part was that if the texture was there as it should, where the hell was the problem?

Problem #2.2

Performance wise checking if there is a texture is absolutely dumb! 99% of the times there is a texture present. More, the object class has a visible variable. If the object does not have a texture why is it visible in the first place?

So while apparently I solved a problem by checking if the texture was present and not performing any blit operation if it wasn’t, the truth is that both performance wise (not that serious by the way, it’s just a if statement) and the unwanted problems it induced in the code backfired from time to time.

I spread this type of behavior through the code. While one if statement does not have a large impact in performance, a lot of checking piles up and I had a lot!

Solution #2

A short story and a riddle both taken from those books that explain my thoughts on the ‘final’ (we’ll see about that!) solution for these problems.

The first one was when one of the authors was hired as a consultant for a development project where the coders sent broken code to the version control system. What he did was to create a routine where the version control server would compile the code that was pushed. Every time the compilation didn’t work the server would send an email with the error. With the amount of mail with errors constantly piling up on mailboxes, one of the coders asked if there was a way of not getting that much email. The consultant replied: “Sure, don’t push code with errors!”

The riddle is… what code takes not time to be executed? The one that is not compiled.

So the solution is to write code that allows zero error tolerance while not compiling it. The way to achieve this is with conditional compilation which can be used in several way but these are the ones I believe the most useful is to use code blocks, like this:

1
2
3
4
5
6
7
8
9
10
11
private function someFunction():void {
    CONFIG::debug {
        // Development code
    }
    CONFIG::release {
        // Final code
    }
    // Both dev and final code
}

Inside the same function, different code is compiled depending on the current configuration. We can have several checks with exceptions and errors being thrown and then have a ‘don’t check at all’ version in the release configuration.

This is a two stage solution really. On one hand every time I do something stupid, I get errors so my code has to be perfectly implemented at least when it comes to our framework. On the other hand the same code that make me code as best as I can is also the code that does not run in the final version.

 

Posted: February 5th, 2012
at 12:55am by Vlad

Tagged with , , , , ,


Categories: Dev Journal: Danger Zone,The code of VGS

Comments: 4 comments


Application Design vs Game Design Round 1

Hi everyone, Vlad here.

Let me start by saying that the title is a bit misleading. For starters it is not an actual bout but more a decision making process. It also gives the impression I’ll write more about this or that I have some kind of plan about this subject. I don’t, it just happens that I think I’ll travel this road again.

Game Design

The game design for this game states that:

1. The player’s objective is to reach the top of the “structure” (named just to make sense) where the action rolls;
2. The “structure” has several “floors” (again just for easier comprehension);
3. The player can fall to the previous “floor”;
4. It is guaranteed that the player will see at least three “floors”;

Application Design

One thing that I know for sure is that we will be blitting all graphics and that the player token has three different blit objects and two of those rotate thus negating copyPixels and putting the dreadful draw method to work.

Another thing I know is that each “floor” is a tilemap, also blitted and that each tile is 64×64.

And now the assumptions begin. How big is each “floor”? I have no idea but let’s say that a rather large “floor” has 50×50 tiles. If the player will see at least three floors and on later stages all “floors” are rather large we are talking about 7,500 tiles to be rendered with a astonishing number of 30,720,000 pixels to be copied… each frame.

The “floor” where the player is will only render the tiles on screen (88 max) but the other two lower “floors” can potentially be fully rendered given the camera specs. Even if all three “floors” only rendered tiles on screen (which won’t happen by design) there would still be 7,500 objects to manage and that’s tiles only since we need to add to this all the remaining entities: player, enemies, decorations, effects, etc, but to make it worse the bottom two levels will be zoomed and probably in full view which means not only that all their blit objects will be visible but also that at least 5,000 of those objects will use draw instead of copyPixels… Did the headache kicked in already or is it just pure performance insanity?

Implementation

One of the great things about copyPixels is that it only renders the intersection between the target bitmapData rectangle and the source rectangle positioned at the destination point. What this means is that if we have 1,000 objects to render but only one actually has an intersecting rectangle, most of the processing time is running the array, vector or list and – more important and processor heavy – calling the functions that will in the end render.

The draw method also does this with a matrix… more on this later.

The solution was to write a BlitTileMap class that builds the tilemap in one big texture before it is used. While it uses much more RAM this class allows to address pretty much every problem stated earlier.

First and foremost the number of objects managed and therefor the performance lost with running their container (in our case, a linked list) and calling functions. From a potential 7,500+ we now have 3. The other issue that this addresses is the number of pixels it will render or try to render, from potentially 30,000,000+ to the worst case scenario of 1,050,000. And last but not least, considering the lower “floors” will be zoomed out, instead of using draw to render 5,000+ objects it will render… 2!

But the draw method also has a funny and helpful consequence. The smaller the scale, the faster draw executes which in terms of performance is relevant considering the zoom out will be achieved through scale. Less objects taking less time to render will be (I hope) quite a performance boost.

Did I just write all this? Wow!… Later!

Posted: January 25th, 2012
at 12:15am by Vlad

Tagged with , , ,


Categories: Dev Journal: Danger Zone,The code of VGS,The design of VGS

Comments: 2 comments


2012 Update

Hi everyone, Vlad here.

Yeah, I know… long time, no writing. 2011 started great, didn’t finish that well for a lot of reasons, mostly unrelated to Vortix but we are catching up and have some stuff rolling. Here’s a quick update.

As you might have noticed in the last post Marco and Pedro are working on some cool stuff that involves kicking, punching and 3D!

In the meantime I’ve been messing around with some cool stuff too. First and on top of our priorities is a new game that if it is as fun to play as it is challenging to put, should be a great game. I’ll post my thoughts on some of the challenges we will face as we walk the dev path.

But that’s not all… Doing R&D has become almost a hobby of mine. Weird to have a hobby that involves coding when I’m not coding but it’s fun and I admit that I like to maintain codebase and have codebits ready to evolve when needed.

I’ve played around with client-server stuff, dual-screen stuff, multi-platform stuff. Right now multi-platform is my main focus and haXe and NME the weapons of choice. This means that I have a lot of duplicated code but it’s getting pretty!

And this is the quick (or not) update and the promise of more blog posts with less interval.

Posted: January 23rd, 2012
at 8:16pm by Vlad

Tagged with ,


Categories: The life of VGS

Comments: 1 comment


« Older Entries