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:

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.

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!

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.

Hi everyone, Vlad here.

Time for a new game (actually two new games, more on that later August) and this time we follow our cutest franchise: Atomik Kaos! I could tell you much about it but it’s not 100% ready although it should be up for licensing in a couple of days.

Without further delay, here’s a video… by Marco!

Hi everyone, long time no see. Vlad here!

We never had one person to take care of our sound effects and music. Sometimes we hired, sometimes we got some sound packs and both me and Marco have made some music for some of our stuff. But the truth is that we were never 100% satisfied with the results.

When Marco was producing Hajime, we had the opportunity to work with Francisco Furtado. The result was amazing. Hajime is a much better game with all that vibrant music and amazing sound design. We spoke about future games and projects and Francisco agreed to cooperate with us.

After Hajime came The Adventures of Dear Explorer and with it a fantastic work and environment was created from the dungeons and sound and music carved in each wall, skeleton, boss… it’s almost unfair that we don’t let the rest of the world know about Francisco’s work. It is truly a work of love and high quality.

So I invite you all to visit his page at Bandcamp: http://franciscofurtado.bandcamp.com/ where you can check the OST for both games and much more.

Cheers and thanks Francisco, hope we can do more and more of these.

Talk to you all soon,
Vlad out!

We just uploaded this video to our youtube channel to give everyone a quick glance of our newest game. Anything you need, email me at mail [at] vortixgames [dot] com.

Our newest game The Adventures of Dear Explorer is up licensing. It tells a story of a jock whose cheerleader girlfriend was kidnapped by a mighty wizard. Armed only with a shotgun and guts, the hero walks through caverns to the depths of hell to rescue his loved one. Zombies, demons, bosses and much much more awaits our hero in a game that is part RPG, part dungeon crawler and all retro!

If you did not get an email from me with the link, please let me know through mail [ at ] vortixgames.com and I’ll send a link your way.

Projects

Lot of stuff happened… Hajime finished and was sold, we worked on Warlords 2 and Async Racing with Ben Olding, we finished two major contracts and started a couple of other ones.

I must say that project wise I have split feelings. On one hand we did put a lot of stuff out. On the other hand most of our time was used with client IPs, which can be heaven or hell, but never our heaven or hell.

Couple of other small victories I reckon… not entirely relevant for the company has a whole.

Business

I don’t know the exact figures of 2010 yet, but I’m pretty much sure we grew more than 100%. This would mean that 2010 was the year of our stability. While this is somewhat true it is not that black and white. Right now my predictions are that we will match 2010 in the 1st quarter of 2011 and still I’m not happy. My biggest concern is related to passive income. We have not yet found a way to have a steady passive income and the rest simply has too many variables, plus taxes…

Yes, 2010 was good, but we are growing and in a very decisive year in VGS, so we need to really be less dependant of overall market… stuff…

VGS Most Valuable Player

I bet we are the only company in the world with more than two people where 50% of the people are named Pedro Santos. While none of ‘our’ Pedro Santos are in fact and legaly employees of Vortix, both of them have the same spirit of the three guys that started up Vortix: they put their effort into something and make it happen, which is a rare thing nowadays. In my opinion ‘The Pedros’ share the MVP place in 2010.

The Flash Game Space MVP

I really have to make this special note here… There’s this Ben guy better known has benologist. He bootstrapped something we know as Playtomic, which is pretty much awesome and that I won’t describe because you either know it or you should follow the link. When devs were bitching and whinning about blocked links he put pressure on portals and created Portal Blacklist.

And still managed to release games… no doubt, my personal choice for Flash Game Space MVP.

And one last word

Marco, my partner, friend and brother. You are one in a million mate. If we find the other 6000 that are like you, we’ll rule the world! Keep up the good work!

If you want to contact us regarding this game (or any other matter), use the contact form: http://blog.vortixgames.com/contact-us

I’ve been present in some discussions in the FGL chat about the whole Programmer VS Artist war, and it annoys me every single time.

The reason for this is that there seems to be a very amateur approach to game development in the flash community. The very simple act of dividing people into different parts makes it look like one side wants distance from the other.  The point is exactly to put TOGETHER the two or the three or as many parts needed to make a game.

This is of course an old habit from the old “one-man-show” format usually associated with flash development.

There’s obviously a lot of young developers who are just starting out, but there’s also some people that have been doing this for some years and have actually already sold some games. The insistence in this “war” will not only deprive some good developers from creating long lasting bonds with other developers, but it will also keep the production value of flash games very low.

One of the problems of this discussion is that its set to die at its birth. It’s always the “programmer” vs the “artist”, which I come to find that in most of the situations it stands for the “Coder+Idea owner” vs the “Graphics designer”. If we were to call people by their occupation it would put the discussion on a new light. Suddenly, the “artist” which is a generic figure, is now the guy that does the graphics. But the artist could also be the SoundFX guy or the Musician or even the Game designer. The same way the programmer could be the Coder, or the producer, or the Game designer as well. This will usually have people cheering for one of the sides because they understand the hard work it is to do one of the parts of the game, but they neglect to see the other part.

This also leads to the second problem with this discussion which due to a simple statistical fact, most people will assume “programmer = idea owner = game designer”. This is true for a big chunk of the reality, but it’s not a rule. It’s not an indicator. It’s a consequence of most programmers being able to do a complete game on their own without the need of external help. A programmer, who wants to be a game developer, will in most cases start developing on his own, and as he does, he comes up with ideas for other games, and when the time comes to collaborate, he will have a pocket full of ideas to use. This in itself will put the visual artist in a dependency position. He will work under the direction of the person whose idea it is. He’s just doing the art, while the programmer is doing the code AND the design. This however is not a RULE. It just happens to be like this frequently.

So again, people tend to overlook the fact that along with the production itself, either it be graphics or code, one person may also be accumulating the work of designing the game.

And this takes us to the third problem I tend to see in these discussions. The one I heard recently was “He never complained about how much money he got, he just started complaining after seeing how much the game sold for”.

I’ve worked on titles that have sold for quite a lot. I’m happy to say that whenever I work with Ben Olding, for instance, I know I’m going to get huge visibility, because he usually makes very popular games. He’s also known to sell his games for a very good amount. It would be ridiculous, not to say unethical, to be knocking on his door saying “Right, you made more money then I though you would make, where’s my share?”

The reason the game sold for a specific amount may not be even remotely related to the graphics. In the specific case of Ben, he usually has really awesome game ideas. And those turn into good sales.

The programmers reading this will probably think “yes cause a good idea will always be a good idea, even if the graphics are crap”. And I say “True, but aren’t the good graphics and good sound the difference between a really good game idea and a really good game?”.

But before you start thinking that I’m saying that an artist should set his price, get paid and let the game sell, I have to say one thing. I do believe graphics have a huge impact on sales. Graphics may not be the single most valuable feature of your game, but they will get you views. They will get interest both sponsors and players. And even if the player tries the game just once to realize its “just graphics” the sponsor has already made some money out of that. Sponsors know this, and even FGL has stated that you should put an effort into making better graphics for your game. They will sell for more. And artists should know this. They should know their work can have a huge impact on the figures a game sells for. But they should know this going in. Not wait for the game to sell and say you want a cut. If you want a cut, say it right away. Say you charge $$$ plus a cut. Say you will only take a cut, or say you want to get paid and not have to worry about if it sells or not. Some programmers won’t give you the option of a cut, so figure out how much you think your work is worth for the overall value of the game.

Now if you’re an artist on a collaborating format with a coder, then both are, in my view, worth the same cut as long as they both work at their best abilities. Maybe the graphics won’t be the best, or the game won’t have as many features or the sounds aren’t perfect as expected, but the point is that all the team did their best.

Programmers should realize that graphics can make a game a completely different experience, and game artists should know that there a good chance their creations need some code to actually turn into games. AND they should BOTH realize that the best creations come from collaboration, from sharing of knowledge and know-how and from being a development force.

Programmers will most of the time have the upper hand, because they can code. That means they can make games. Doesn’t mean they can make a good game.

I’ve seen mediocre programmers make huge sales, and I’ve seen people bored to death with amazing graphics. It’s not the graphics that make the game, it’s not the code either, and it’s not just the idea. It’s the game that makes the game.

So, on a final note, if you’re a developer, looking for people to work with you, be fair. Sure, it’s nice to get more money than the other person. But is it really worth it in the long run? How many people will want to work with you? How many times will you have to resort to inexperienced cheaper people, who will not be able to deliver content that is above par?

And I don’t mean just art. We’ve hired a programmer to make a game. He’s good. We want to work with him again. We have to make sure that all parts are satisfied.

In the game development community, there seems to be an ambient of symbiotic relation between the logic and the art. But I’ve never seen so much discussion about it as in flash community. Probably because most programmers have to pay for their art. Its like it’s a war. And as Sun Tzu said: “There is no instance of a nation benefiting from prolonged warfare.”