Archive for the ‘The code of VGS’ Category

A small fighting AI test

Although me and finite state machines are good friends for sometime, implementing a more in-depth artificial inteligence algorithm is something I’ve been looking forward to test for some time. I did manage to take sometime to do some learning and testing and I’d like to share the results with you.

What you see below is a simple FSM ruling the behavior of two fighters. Each fighter selects one of six attacks randomly, moves into position, attacks and steps back. If the fighter is attacked before starting his own attack, it has a 50% chance of dodging and then proceed to attack. If hit, after being in slight pain, it steps back. Everytime it steps back, a new attack is chosen.

The discussion I had with myself is if it would make sense to make a round based combat disguised to create the illusion of real time combat or a real time combat directly. Funny enough, I found it easier to make it real time directly.

More can be done in terms of complexity layering, but as a learning experience done with just some hours, I’m more than happy, so see you all later! Vlad is out!

p.s.: oh and cheer Marco for this character! It’s a long time favorite of ours, waiting for the right opportunity to pop up into the web!

Handling local high-scoring

Hi folks, Vlad here.

We just tackled a code problem that is as complicated in nature as simple in resolution.

Problem

To have a high-scoring table that works not only on websites, but also localy, in our case, while ran from a DVD. The second issue is that we need a custom high score table, not the standard one size fits all ‘showboard()’ solution that most APIs offer.

Original approach

Our first thought was to communicate directly with a web service using AMFPHP. This works indeed, but the user must allow the local Flash Player to access outside content. We didn’t like this… on one hand, security warnings and the software asking to confirm security stuff scares the common user, on the other hand many of the players of these games are kids, so this would be a pain!

Further investigation

But we know that there are a lot of APIs that allow a lot of off-site communication, even localy! There are security protocols that Flash Player enforces, so how are they dealt with? If someone else has done it, it is possible…

The answer is: the APIs communicate with a swf that lies in the same server where data communication is handled. The APIs connection methods are in most part the download of that specific swf and it is the swf that holds all the ‘inteligence’, does making the whole process more troublesome, but more secure…

Solution

We investigated this because of a thread I created at FGL’s forums. I explained what we needed and the answer was: try Mochi’s APIs. Which we did, easily. Mochi’s API does exactly that: it connects to the webserver where it downloads a swf that holds all the methods to communicate with their databases, so there’s no security issue here. As long as there is a internet connection, it will work.

Code

And here is the code to handle the custom table. I’m not including the standard stuff, like connecting or sending scores, that’s pretty straight forward. The only weird and somewhat confusing and somewhat oddly documented feature is the request for high scoring data from Mochi’s servers.

Hope this helps! See you all soon!

My code tricks #1: All around consistent data

Sorry about not having posted too much, but deadlines have this strange habit of having a higher priority. Vlad is here trying to stay awake in this awkward coding night and to celebrate this fine hour of coding I decided to take a small break and create a new ‘series’ in the blog. I’ll call it “My code tricks” and #1 is dedicated to the neat little trick I use to have a lot of standardization across my code.

Not my original idea at all, actually it’s so simple I’m amazed that I haven’t found any blog post or article that talks about it. But here goes!

Finite State Machines

Once upon a time I had the need to start using state machines. Like pretty much all code I write and as noted by a fellow coder, my code is OOP enough to make coding easier but not a by the book approach, far from it. So my state machines are quite simple:

Yes, those constants there are the heart of my state machines. They offer two great features: they are extremely simple to use and they are very intuitive and readable, making my coding life easier. As time passed and projects grew bigger and more complex, I started to have issues with controlling all the states and all the constants, especially when I had to get information across objects and classes.

Moreover, some constants had to be public in order to be checked or I’d have to put getters or some other coding artifact to do it.

Objective: reusable and consistent

The way I found to address this was to create one class that would hold static constants for everyone! This way I know that a TOKEN_RUNNING is a  game entity that is running and that this data is consistent all around the game. It does not matter who needs to know that value. What I know is that I have a very easy lightweight way to address states. Check it out:

But by all means, don’t assume this serves states only. As you might have noticed by reading the package, this class is part of the Bold Pixel Engine. The package holds several classes with static constants. The type of entities the blit engine uses, easing codes for the (future) tweening class and color tables. Everything in that package is a constant int that allows data to be consistent and readable.

Consistency means two things: no constant has the same value EVER! and I can add whatever other states I need and data will be backward compatible.

Here’s another example, a class that holds key codes and that uses the key code to feed a name array with key names. We use it to get key states from an input manager. It was migrated some days ago, to be honest I know the input manager is working but I don’t know if the name array has any use as a static member, still, feel free to use it, the keycodes are REALLY handy!

Downgrading from engine to toolkit

While I was discussing the release or not of Bold Pixel Engine, I came to the conclusion that it was not an engine, but a framework. What’s really the difference I wonder… I don’t know, but I did conclude that. Without googling for some reasoning and from the experience I have with game engines (not a lot but enough for what I’m about to write) I’d say that an engine runs while your game logic is processed.

On the other hand, a framework is a pre-build codebase that you use to raise your productivity. It does most of the work and takes control of the most obnoxious tasks. Our engine does that but it does not run while processing logic.

So it was kinda easy to conclude it is a framework, but not an engine.

Then I found out that a framework will take control of the dreadful tasks by creating automation for it. That would be an issue I read and I read that a toolkit is a much simpler approach, with a much lower maintenance overhead that assumes the programmer is in control of getting it done, while the toolkit only provides functionality.

“Damn!” I thought while I was reading… our engine is a toolkit.

And what’s the purpose of this post? None! While semantics are being discussed, our engine is currently being used to create games. And we will call it engine because regardless of what we call it, it will do what it was designed to do and because we really love the notion of engine regardless of the actual name being right or wrong.

So, engine, framework or toolkit: Bold Pixel Engine is alive and well and it will be released freely as soon as it has some games out just to be sure that it is stable enough for game development.

Engine misconceptions

Maybe I’m a bit overwhelmed with what happened this last week, but the topic that doesn’t seem to leave my head is our engine. While I was discussing the topic in FGL chat I noted again two distinct definitions of engine. What I’m aiming for with this post is to address the common misconceptions that, in my humble opinion, exist to many flash developers.

Each game is an engine

This is the start of the difference of opinions. For many developers reusing a game engine equals to creating a sequel to a game with small tweaks and new graphics. To me, reusing a game engine is reusing multiple classes across games, but not game logic.

Coding your engine is nothing more than to write separate classes for the code you often use. Great simple examples are keyboard input, sound and music handling. On the more complex side we have collisions, AI and bliting. All of these can be coded separately to create a library of code that we can reuse with ease across games. That is the game engine.

It’s impossible to code a cross-genre game engine

Again, this misconception comes from not separating engine from logic. If we detect keyboard input the same way across games, if we preload the same way across games, if we blit the same way across games, regardless of genre, why can’t we write code that fits all genres? It is better to manage some exceptions to your code than to rewrite it over and over again.

If you think about it, that’s how cost is cut in other game development markets, like consoles and PC development. The use of engines is more than common. Huge corporations like EA have their own technology to serve their cross-platform needs, others use commercial engines, like Cry Engine for their target specific development.

So, if a high-end, complex environment like console development can pick up a game engine and write different genres, where lies the difference for a much low-end environment like Actionscript based development?

Extending the core classes of Actionscript is enough for me

This is not a misconception, it is more of a easy way out kind of thing. When I started coding in AS3 I had this exact opinion. To be honest, extending MovieClips was pretty much all I was doing. I can assure you that it is easier but it made my life harder in the long run, as soon as we needed to move forward it became obvious that this presented some performance issues, not to mention that extending classes is probably the least reusable way of coding in AS3.

Final thoughts…

I believe that this generic opinion towards flash game development and engine technology happens because many developers don’t separate engine from logic, for example, a game that needs collision detection has the collision detection code written within the class that controls the level, assuming there is a class in the first place.

Yet, and with our own engine slowly but steadily maturing, I feel that it makes all sense to take the first step which is to create our own reusable classes and then take the second step and code an engine that makes our life as easy as it can possibly be in the long run. We wrote the first class because it would save work, considered a “full” engine because extending MovieClips was clearly damaging our work and right now, I can’t imagine the amount of code I would need to write to sort some design issues that appear almost weekly.

Vlad out!

« Older Entries    Newer Entries »