I bought this book before its release. It took months for it to arrive which was a pain since my expectations were quite high. You see… I’m an 8bitrocket fanboy. I have devoured time and time again the ideas, thoughts, tests and code from Jeff and Steve Fulton and even being a fanboy I have a mind of my own and there are a lot of views that I don’t share. So I’m a fan I admit but I’m also an independent thinker.
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!
Some days ago GamesChart Barry White brought to my attention a problem with Mochi’s version control system but there was a bit of a mystery around it since it only affected one of the possible implementations of GamesChart API: if it was implemented with the drag-and-drop component, it would not work, if it was added to a Flex project, it would.
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. 
Hi all,
Some months ago I had the opportunity to meet Servet Ulas through FGL forums and chat where he is known by the username Pixelful.
So after an informal chat Servet showed interest in doing is internship with us, which naturally filled us with pride. But since it’s easier to be said than done, we waited for some news and when the news arrived it was official: everything was ready for the internship to start and he has been working on a project since last week.
I have an admiration for people that make things happen and Servet did that, he took care of everything so that he could do a project with us.
I’m glad and feel fortunate that developers want to work with us. I hope that this experience is a rich one for Servet and productive for us. First steps sure make it sound that way.
Cheers!
Following the first post of the series (no need to click it’s not that interesting) I did some initial testing with some SWF encapsulation and obfuscation software. Let me remind you that the exact same testing many months ago wrecked our game, by that time Tech Wars.
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.
FIGHT! no wait, it’s “GO!” is it? “Kick each other’s @ss!”, I don’t really know how its translated, but I know what it means. It’s an order to do your best and take out your opponent. And it’s the name we chose for our game, and we are happy with it.
So without further due, here is the logo for it and some combat screenshots.
Keep in mind though, the backgrounds need some work still! No time for everything!
So, here they are, in full glory, the first peak into the combats in Hajime.
Take care!
Marco
