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

I read Flash Multiplayer Virtual Worlds mostly because it is an area that interests me a lot and crosses many aspects that are part of my daily work from a design point of view. The name could not be more obvious regarding the intentions of the book: to create a virtual world using flash technology, so what’s in it?

The good

There are many good things about this book, but probably the one that doesn’t stand out immediately is that it will get you up and running with SmartFox Server in no time! From installation to technicalities to server-side implementation, the amount of examples surrounding SmartFox Server should make this book interesting for anyone that wants to pick up this server-side software even before considering MMOs and virtual worlds.

One of the really good things about this book is that it covers every standard implementation that is present on a virtual world. Starting on architecture and going through in-game systems such as avatars and messaging up to the social aspects like Facebook integration and even some quite smart details that I personally would not remember or know. I admit that in such a wide area, maybe something is missing, but I can’t really remember any.

Another good aspect is that it seems written to a lone wolf kind of developer given the detail of some particular aspects (such as extracting 3D renders) that most coders working in teams or companies would not care because it would not be their work, but it doesn’t really get in the way.

The bad

The last paragraph brings me to what I didn’t like in the book. I can look at this book from two perspectives: the game programmer or the game designer. From a game programming point of view there’s too much game design in different depths of detail and even some stuff about handling graphics that I admit is important but should be as important as the assumption of AS3 programming of the book. From a game designer point of view, not only the code is not my core work, but the design is not in depth enough. I sometimes felt that the level of detail was not constant, when comparing how to integrate tiles in isometric perspective (extremely well explained and detailed) and the implications of designing a solid online economy (well explained but no detail).

Conclusions

So, is this book for you? Like any book, it depends on who you are. Are you a AS3 coder that wants to work with SmartFox Server or create virtual worlds? Are you a lone developer that wants the overall knowledge about this topic? Or even a designer that codes a bit and wants to try it out?

Then yes, this book is for you and I do recommend it!

I’m a fan of Newgrounds. The principle behind it, the motto “Everything, by Everyone” is absolutely brilliant from a creative and sharing person point of view and let’s face it, Newgrounds is simply different from the other portals. One of the most satisfying aspects of Newgrounds is that a author’s work is judged and commented by other authors… or at least that’s the idea…

Newgrounds due to its size and history packs a great deal of business also. If your game scores big on Newgrounds, it will probably spread easily and give you a nice change of getting some non-exclusive deals in case you are allowed to.

The problem with this is that the scoring system in Newgrounds is tricky. As many may know there are a lot of crews on Newgrounds. Most (I hope) are quite legit and base their presence on doing collabs. But there are a lot of crews (let’s just called them mafias) that simply exist to uprate votes of their members and downrate votes of other submissions. If you are “lucky” and low-life enough to be part of more than one of these mafias you can get a bunch of 5′s while other submissions get 0′s. This happens until the daily prizes are announced.

This issue is way more serious than developers might imagine. For starters, many portals base their selection on NG score so if your game is lost in the mess of down voting, you might have a setback because of it. Second,there are portals that base their choice for non-exclusives and the money they offer on your prizes and scores.

Your game can go from 4.1 to 3.1 in a couple of hours and loose a daily prize and exposure… shouldn’t that be extremely serious? I think it should. But don’t trust my word for it, read this thread: http://www.newgrounds.com/bbs/topic/1198036

This is happening for a long time. It’s been either subtle or amazingly obvious and many, many, many developers are not aware of it and there is no official voice that I am aware from Newgrounds, which is sad. Remarkably amazing games can escape this because they will be up voted almost instantly, but if you have “just a good game” against a submission from one of this mafias, your game is going down.

No excuses can explain the silence. It is not valid to say that it could happen on other portals because other portals have a higher ratio of non-authors so competition does not strike you that obviously. It is not valid to say that it is just how it works because that means the best and brightest can’t compete with untalented yet organized mobsters.

I want Newgrounds to be better and I want their system to be taken seriously. It’s pretty much the place where author’s matter the most, but this is seriously hurting all legit authors.

I really like books. My biggest flaw is not owning a e-reader, but it will arrive mid-September, don’t worry! While I read some non-technical books occasionally, like most of you (our dear friends and blog readers) I mostly read technical books. One of the issues with technical books is to find those that match your needs. Like me, I bet that you will not buy a book that doesn’t pack the the promise of growing your knowledge considerably. I also bet that you, again, like me, have bought a book or more that was less than what you expected.

On occasion I’ve read books that seem awesome and has time goes by prove themselves wrong… so is life…

The best books I bought were through word of mouth. People I trust having a opinion on a specific book that would meet my needs. Reviews help also, naturally. Bringing the two of them together on our blog sounds fantastic to me!

Packt Publishing released two new books that sound amazingly interesting for todays flash market space. Flash Multiplayer Virtual Worlds and Flash 10 Multiplayer Game Essentials. The book titles are self-explanatory are they not?

I’ll read the books in the near future and review their content from flash developer to flash developer. All that is left is to say thank you to Packt Publishing wish them a lot of success and hope for more books that are interesting for the flash gamedev community.

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.

And it is as a unbiased independent game developer that my advice is: BUY THE BOOK!

Why should I? – you ask. I’m not going to review it like you would probably expect a book review, a chapter by chapter analysis of it, acting like a dumb fan or a scholar on the subject. I’m not even going to rate it, I’m going to tell you why this book should be read by all game developers, especially aspiring ones: it has in it the lessons that seasoned game developers share with aspiring ones. It has that subtle juicy stuff that no programming book can give but it is written and thought like a coder would.

It is not a book for coders or a book for designers. It is a book for flash game developers. The best one I’ve read about the subject. I hope Jeff and Steve don’t mind this little quote:

Second game – what about the first game? Well, of course, you need to make your first game, but inevitably your first game will not be all that you hoped it to be. It just happens. Don’t blame yourself. You will cut features for time, get frustrated, and sometimes, not even finish. However, this is the most important thing we want you to do: finish your game, and move onto the next. It is the only way you will get better at making games. This is the second game theory.

This is the first paragraph of the book’s first chapter. This is what game developers that have a couple of games under their belts say to aspiring game developers: finish a game, as simple as it might be, finish it!

This book could be all about code (and it has a lot and very good code) it could be neverending lines of code of bad games, one after the other with no real connection, just trying to explain feature after feature of AS3. It is not, this book is about real game development, from mindset, to design, through code.

Enough independent thinking, time for the fanboy in me to write…

Go buy the book… Steve and Jeff gave the whole flash game development comunity a lot through 8bitrocket, they put a lot of effort in this masterpiece and from a game development perspective, there isn’t anything like it regarding flash or AS3. They deserve our support for all the support they gave us and it is not like you’ll be doing them a favor and buying a bad book, you will be buying the best book about flash game development.

Just noticed I really didn’t review it… but hey reviewing this is like reviewing Mona Lisa… it smiles in a misterious yet perfect way.

GO BUY THE BOOK!

Mochi’s Version Control works as a wrapper, which usually brings some issues related to accessing the stage property. I concluded that dragging and dropping the component to the stage was for sure the problem but couldn’t find a workaround to it. Has far as I could have thought, I couldn’t call the component the same way I did with a Flex SDK project.

Barry then showed me a work around that is just amazing for its simplicity. Robert Köhler (check his games here) didn’t drag the component to the stage but rather exported it as a class. In the timeline he wrote the setup code and it worked.

After a chat with Barry and Robert, it was obvious that it was the immediate access to the stage that created the problem with Mochi’s Version Control. With the Flex SDK implementation, the setup is made AFTER the stage is ready.

To make things simple for everyone, here’s a CS3 FLA showing how to do it, but the rule of thumb to use GamesChart with Flash IDE and Mochi’s Version Control is: don’t drag the component to the stage, call the setup method from the timeline or your code as long as you check if the stage is available.

All credit goes to Robert! We are just spreading the word.

What I want to achieve

For any of the software tested to pass this initial test the game I chose had to run without breaking anything. As a reminder I checked the previous testing and the problems were:

1. Sound not playing
2. Actions not being called (like opening a menu or something)
3. Problems with text

Assuming no new issues would arise I would keep an eye on these three.

Software and prerequisites

I downloaded the following demos (in alphabetic order in case you are wondering):

1. Amayeta SWF Encrypt 6.0
2. DComSoft SWF Protector 2
3. Kindisoft SecureSWF 3.4

One thing I recall was trying to get help to make Tech Wars work and found myself tunning preferences and stuff like that. So I decided that I wanted nothing of that! All my effort had to be minimum. I would install the demo software on my harddrive and throw an SWF at it, check for problems, try some minor things. I wanted no complications and no tunning.

Maybe I’m being to picky, but my know-how doesn’t include encryption, not to this extent. As a game developer there is so much stuff I have to learn every week, that software like this, while extremely important is just a tool. I just want it to work with minimal fuss.

Last but not least, the chosen game was Atomik Kaos 2. I did some small testing with a build of Hajime, but I guess that’s a perfect game for later testing, right now I needed something that I knew in and out, so AK2 it was.

Amayeta SWF Encrypt 6.0

Amayeta’s SWF Encrypt Interface looks easy and fine. Choosing and protecting the file was an easy job, but my problems with dynamic textfields emerged almost instantly and the game had a slight hicup when a level was finished. Apart from that all was fine. The hicup wasn’t serious, but I had to take a look at the textfield issue.

On the left SWF Encrypt, on the right the original SWF

Took a deep breath, looked at the options before me (not many, minimalist, just the way I like it) and I had a vague idea about encrypting names being an issue. So I decided not to encrypt names… it worked perfectly. A little tiny thing, but nothing serious.

DComSoft SWF Protector 2

Next on the list DComSoft’s SWF Protector 2 and I must say I’m really impressed. The interface is just perfect and it was begging for a drag and drop of the SWF, which I did and it worked wonders. I had to do nothing, absolutely nothing, just drag the file and click a button.

It was perfect! Just like I imagined it.

Kindisoft Secure SWF 3.4

Secure SWF doesn’t need installation, that’s a big plus in my book. The interface feels old though but it does the job. I tried to drag and drop the SWF and that also did the trick, cool! Time to protect the file and run it. A couple of severe problems happened. For starters as soon as the swf opened the player threw an error. The game went fine after that until I checked the achievements screen where dynamic textfields were messed up.

Flash debugger error

Problem with textfields, again left is protected SWF, right is original SWF

I returned to secureSWF to try a different approach. One fine thing is the protection presets it offers. Being my middle name “minimal” I enjoy not having to go through all the options trying to find out what it is and what it is not. So I chose the preset “Safe – less protection but will always generate working files” but the results were exactly the same, both for the starter error and the textfield issue.

I started to look at all the options, aiming for a custom solution, but I was overwhelmed by the amount of stuff I had to try on to eventually make it work. I gave up at this point.

Conclusions

I’ll give decompilers a shot next and see what happens, what can I see, extract and so on, but for now Amayeta’s SWF Encrypt and DComSoft SWF Protector 2 did the job although I’m very impressed with SWF Protector 2 because it just did its job and I did not have to worry about anything. If I recall correctly that was what I was not able to do with Tech Wars testing. If I had to make an early pick, I’d go SWF Protector 2.

There will be a lot of news in the upcoming days, stay tunned.

Almost two years ago, I went through the trouble of using some trials of encryption/obfuscation software in order to protect our swf files. I don’t know how that worked out for you, but to me it didn’t work at all.

I tried and retried and tried again. I messed around with several settings and it never, NEVER worked perfectly… or actually it did if I turned out most if not all useful stuff.

Well… I really put it behind my back and never really thought about it again. But today I tried it again… and it worked… and it worked nicely!

So this is good news and since it went so nicely I’ll be making a small series of posts with our findings, from initial testing to a final game. Stay tuned.

A must see video from one of the most intelligent and visionary game designer and game design theorist out there.

http://fury.com/2010/02/jesse-shells-mindblowing-talk-on-the-future-of-games-dice-2010/