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.”

We’ve done some work with Ben Olding. Well… Marco has! I guess I’m just proud that through him Vortix is involved in games with the quality of these. Warlords 2 Rise of Demons has left the building and landed at ArmorGames. Marco did the graphic work with the exception of illustration.

Good luck to Ben and to his new game Warlords 2 Rise of Demons!

Check it out: http://armorgames.com/play/6999/warlords-2-rise-of-demons

We will be using Nape for physics. Nape is a physics engine developed by Luca Deltodesco (aka deltaluca on FGL and Nape’s forums) that focuses on performance. For more about Nape, visit also the Project Page on Google Code and the Documentation.

We’ve been authorized by Luca to make Nape a part of Bold Pixel. In order to do this work, Bold Pixel releases (starting at v2) will include the AS3 SWC and our own wrapper. The wrapper is being designed to provide presets, easy management and a debug view that can be integrated with both other pieces of Bold Pixel (namely and most evident good use is the blit engine) or a typical Flash/AS3 project. Obviously it will have a lot of conventions and to make full use of Nape you’ll need to know how to use it, but the worst case scenario is that any coder will much less code to write and maintain.

We wish the best of luck to Luca and wish we can pull a lot from Nape and Bold Pixel. As soon as we have a tech demo of what we are doing with it, I’ll post it.

See you all tomorrow!

Vlad out!

A bit of historical perspective

Bold Pixel Engine started with our first flash game because of a simple music management class. Back then, both me and Diogo were coding and I remember (and I admit I deeply miss) our discussions about code standards and organization. I’m a bit of a dictator when it comes to have stuff organized, credits to Marco that has used the word “dictator” more than once and with a large amount of reason and giggles.

Soon our bunch of classes were our own internal library and I even posted some of my own experience while organizing that library. Some of the most important definitions of Bold Pixel where then starting to emerge. July 27th 2009 we announced Bold Pixel Engine was alive.

I was quite excited about it!

The turning page from internal library to public engine was the blit engine. We had so much help from many amazing developers that we would not keep it for ourselves. We wanted to share, we wanted to hear what others had to say and that’s what we did. After two games under his belt and a lot of opinions, the engine was publicly available and his version 1 life was pretty much that until the version 2 turning point a couple of months ago… but I’ll get to that eventually.

What went right!

The learning process was amazing code wise. After Diogo left I really had to raise my standards and get to work and the engine allowed that. Coding such a piece of technology made me contradict myself several times and pushed me forward. I’m absolutely convinced that I am a much better ActionScript programmer now than I was before and I feel I learnt little from the games but a lot from the engine because I forced myself to respect the principles I wanted to see applied to it.

And speaking of principles, these stay true from the first line of code until today and are something that really went right. And these are:

Convention over configuration: Bold Pixel Engine is written assuming some conventions. For example, if the programmer tells the Scene Manager to create a new scene, the previous one and all dialogs will be removed, which makes a lot of sense but maybe it makes less sense to say that all scenes have their pivot point at 0,0. This means that scenes and dialogs are simply added to the display list and that’s it, nothing to configure since there is a convention.

Ease of Use: This goes hand in hand with convention over configuration. If there’s something that really makes my head hurt is to look at the code needed to make something happen in libraries like Flixel and Box2D. I appreciate the effort put in these libraries and the flexibility and power provided but I believe that if we have to configure every single tiny detail the code becomes cryptic and extremely difficult to debug. I don’t mind loosing flexibility because I will create more mechanisms that will help me achieve my goals as time goes by.

Modularity: There is only one dependency in Bold Pixel Engine, which is the Manager class. If you want a single loop or to manage scenes and dialogs, you need to start it up. Apart from that Bold Pixel Engine started modular and will stay modular. The reasoning behind this were two questions I made once:

1. What if I don’t want to use the blit engine?
2. What if I want to add something that will wreck dependencies?

The answer to that was that I wanted it to be flexible, meaning, I can use whatever I want with only one dependency and that’s it. I don’t want the engine to behave like an engine. I want it to be a toolkit at my disposal. I even had a laugh about this.

What went wrong…

First and worst aspect of thing that went wrong was that I did too much stuff that we didn’t need that was requested and I didn’t do it with the same dedication I did the rest. That will never happen again. I’m convinced I got carried away by the kindness of a lot of devs, but we can’t have the engine restricted to the needs of others, which was something I said it wouldn’t happen from start. But what it really makes me feel bad about it was that other devs got involved in the project and this collided with either our work or their work making it a bad solution for everyone.

The second thing that went wrong was that I overcomplicated somethings because I felt it made sense. For instance there is a Scene Manager and a Input Manager and a Manager. All of these managers depend of a Display Object and/or its stage. While it sounds easier to manage code and it looks more tidy and clean, having a gazilion classes doesn’t make it easier to code with. I found myself looking through the classes to find what I wanted… that doesn’t sound like a good thing, right? I mean, I coded it!

And last but not least, I think I really rushed things. The idea behind the public releases of the engine were that we would make two games between each release, which we actually did with v1, but as soon as I had the mechanics ready and all the engine’s juicy code was on a actual project, I went head over heels with it. It lacked documentation, it lacked cross-testing (so, just because I did two games, I should have tried against the two games again) and most important it lacked a critical look and a some honest and critical analysis.

Conclusions

Great experience and I really appreciate all the kind words that I got from developers. I think the really cool thing that most developers got from it was the ease of use, probably the YouTube channel with some nice overview on it. I could’ve written a post trying to sell the idea that we are overwhelmed with joy and l33tness, but I would be failing to be honest. I truly believe that BPE v1 is a great piece of software, but I was naive in the approach and maybe over-friendly in the “pleasing my fellow devs” department.

We have a game going with v2 and I think I sorted my doubts about what is going to happen with the engine. Many things that were wrong with v1 are already gone and there is a lot of stuff that isn’t even started, like moving the Music class which started all this into the current version.

There’s a lot to be said about v2, but this is a hell of a long post mortem and I’ll write about that soon.

I have several motivations to write this blog post. I knew I wanted to call it game design perspectives because it is about game design and perspectives about it but I didn’t really know how to put it. So I decided to put up an image and made a search on my favorite free image plugin. I searched for “perspective” and found this one: perfect.

When I coded my first game I had no idea what game design was. Some years ago, right before starting up Vortix with Marco and Diogo I had no coding knowledge whatsoever so I focused on game design. Problem with game design back then was that everyone wanted to be a game designer… it was the game designer wanabe boom period.

Back then (and it wasn’t that long ago) every guy that played games and wrote two paragraphs of a Tolkien ripoff considered himself a game designer, me included. Many of them didn’t make it up to the professional stage. Looking back, the only ones I know that got into the game development industry are either artists or engineers. The only game design wanabe that managed to pull it was me… and I’m more a programmer than a designer nowadays.

The perspective back then, the passion, was about the game. We all steped our of the dream and learnt that game design is about decision making, getting feedback and more decision making. All game designers, wanabe or not, had only one goal: the game! Like the two crossed railway lines, game design is all about crossing left and right sides of the brain. See the whole while addressing the details. Be able to analyse data and crunch numbers while being able to… well… feel…

It is sad to observe that on a market such as the flash game space the perspective is that a designer’s objective is to make a game that is sponsorable. I find this not only sad, but wrong.

Squize commented on a blog post of his that:

(…) it’s all about the creative process now, so I’d rather push myself and fall short than work to someone else’s design. (…)

Julian from LongAnimalGames mentioned today in the FGL Chat that he considered more interesting the psychology of players than game development itself.

It is a trend I find in many high profile developers. They care about business and particulary money when hiring, when selling, when paying, when discussing deals. Money doesn’t get in the way of design and they have other interests… the creativity, the psychology, the technical expertise and others. It is interesting that these are the ones that make the great, memorable and amazingly sponsorable games. I know one exception… that simply confirms the rule.

Like them we are not against the commercial or business side of all this and we take it very seriously, but game design is about the decisions, the rules, the player, the big shiny paradigms. Production, marketing, whatever, that’s the business part, our job as designers is to reach as many players as possible. We might argue that the bottom-line, that’s what will make the game sponsorable, but it is not the motivation when making game design decisions. Money is a unnecessary distraction while designing.

To be successful we have made decisions. We developed our own activities:

1. Sponsorship and licensing because it is our current form of monetizing our core business and our core business is creating games.
2.  Collaboration projects as an low-risk extension of #1.
3. Contracts as a very-low-risk activity that would allow us quick and steady monetization.

Everything we did, was done with a purpose. There are a bunch of things you can do as a flash or game developer. Some devs operate portals, some devs create software that helps other devs, some devs have a day job, all is fair game, but doing things with a purpose allowed us to set goals and each goal that is achieved is a step forward into that purpose.

It boils down to this:

Do whatever you have to do to be able to do whatever you want to do.

Less than that it’s either a hobby or a bad model. What you need to ask yourself is:

1. What do you do best? Capitalize on that.
2. What do you want to do? Improve on that.

Never stop moving, choose what you have to do and choose what you want to. Be smart, create value, raise the bar, raise your worth.

To finish, keep in mind that you, like us, are probably small fish in a world of sharks. Here’s something worth reading: The Bootstrapper’s Bible. That should put it in a wonderful, motivating new perspective.

Most flash game developers, be it coders or artists, usually lack the other side of the coin. Many coders don’t have design and/or artistic skills and many designers/artists don’t have coding skills. This gap became deeper with Actionscript 3 for well known reasons.

Collaborations the activity that we planned the most. The main goal was to monetize schedule holes. To do this we started by marketing it at FGL. First slowly and carefully, we were absolutely clear that we were not looking for “any game”, but rather targeting potentially high profile projects. We behaved a lot like a sponsor, checking every proposal we got by email, discussing the pros and cons of each. About a handful of projects never started, one was never sold (or put to sale as far as I know) and a couple did well.

Now it is important to determine what “doing well” exactly means. Maybe you are imagining that doing well is getting 5 million plays or we earning $5000 per game. It isn’t. We clearly defined the objectives we wanted from Collaborations:

1. Our collaboration must create enough value in the game so that the developer that proposed the game makes more money than he would if it wasn’t for us. All games that were sold achieved this.
2. Our percentage of the collaboration must cover our cost. I didn’t crunch numbers on this one, but I think we rarely achieved this. It is always a win situation for us since like I mentioned earlier, our initial motivation was to monetize schedule holes that would never make any money.

It was a bit disheartening that as soon as developers create a hit game with us they prefer to hire us. I admit that from a commercial point of view that is the right call and we say from the beginning that we don’t won the IP in any way so we really have no take on the subject. But from a personal point of view, I feel sad that our share of risk and support is left behind and given a lower priority against money… I don’t let these personal feelings get in the way and I share the same amount of respect and even friendship, but it’s a bit… sad…

Final thoughts on collabs and why we did it this way: we monetized, created value for ourselves and developers that worked with us which was exactly what we wanted to do. To achieve this we didn’t consider this activity as part of sponsoring and licensing since we never owned the process of production and sales. Collaborations are half sponsorship and half contacts. That was the only way to fit it into our business model.

Sorry about the lack of updates, but things have been somewhere between messy and overloaded here. A lot has happened since Marco wrote the last post, so this is a quick update now that we are back on track.

Projects that you can know about

While we were missing in action (from a blogging point of view) we worked on some contracts and collaborations. Not all have met the light of day yet, so those won’t get free advertising here, but two of those projects not only are amazing games, but also gave us the opportunity to work with top notch developers.

Palisade Guardian

Mark Loika designed and produced an excellent game in which we had the pleasure to collaborate. Palisade Guardian is a WWII shooter game where the player struggles against the forces of the 3rd Reich.

Try it out!

Crunchball 3000

Soon after, we had the pleasure of working on a contract with Ben Olding aka DJStatika, creator of IPs like Starfighter and Warlords. The result was amazing. Based on the oldie but goldie Speedball 2 for Amiga and PC, Ben Olding created Crunchball3000, an amazing futuristic violent sports game.

…and yes, clicking here will take you to it!

From a production point of view, both games were an amazing task for Marco, featuring full 3D animated models rendered to be animated in Flash objects. There’s more happening with both Mark and Ben and in due time we’ll let you know about it. As far as we are concerned here at VGS, it was a pleasure to have the opportunity to work in both these projects but, more important, to have the opportunity to work with both these developers of enormous quality, both technical and human.

So… now what?

Well, we have a couple more projects to announce but those are not out yet, so we need to be silent. We’ll also try to get some more action to the blog, I have a couple of easy and neat ideas for it… and I won’t tell Marco about it!

I really don’t know when we’ll release our next self published game for several reasons, but the two more relevant ones are that we are getting a lot of contract work which always hurts internal game production and that the new game is a complete new chapter in our offer… just take a look at the previous post.

PhotonStorm

There are a number of developers I trully admire. My developer wise admiration often triggers when two factors are present in the same person: technical quality and the capacity to openly discuss any subject in a true open minded way.

Richard Davey, better known as PhotonStorm fits the description perfectly and I can prove that! Or at least the technical quality…

PhotonStorm entered The Flash 4K Competition and his results are astonishing. Infinite Ammo is his entry and an admirable feat on my book. I know some other great developers are running, maybe Richard’s entry isn’t even the competition winner, but after chatting with him about it and going through the source code I have to say I’m surrendered to the quality of his art and code and can only wonder what would he do if he could use 16KB.

Well done mate!