I have to say I’m still doubtful if I should address this in our blog. I will not go into the details of what a business model is what it is not, how it influences strategy and all that stuff. For that a Wikipedia link to Business Model is more than enough.
As I think it notices in other posts in our blog, I still feel that developers are not fully aware of where they are positioned in the flash game market. I’m not 100% sure but I think that what I spoke most with other developers was about business. I admit I feel quite comfortable with the business side of things and I understand that with the average age and work experience of most flash game developers, business is not something they feel comfortable or knowledgeable.
On the other hand there’s the problem of developers that feel they have a life of experience because they sold one game for $100. They use the word “noob” like there were no mirrors left on Earth. I would add to these a significant number of developers that advice others not to do something that they haven’t tried.
And where does a business model fit into this? Well, most of what defines a business model is well known by developers. What is relevant to discuss, in my opinion, is what are the options available in terms of activities and revenue. Many developers ask me how did Vortix achieve this or achieve that. How do we do it? How much do we earn… stuff like that… I can only be theoretical about it because I’m not fully aware the most sensitive piece of information: THE DEVELOPER!
You need to know yourself, you need to understand, not business but your business and you need to neglect all opinions that are negative in nature to what models, activities and revenue streams that are available to you as a flash game developer.
In the next few days I’ll address Sponsorship and Licensing, Collaborative Projects and Contract Projects as activities and their revenues but I feel that what is important is how do these activities affected us at Vortix so you can relate to your own business model. Because there is no perfect or good business model, there’s only YOUR business model.
Been a while since I write here. This post will be a bit like therapy. 
So life is treating us so-so. A couple of contracts are approaching the end and after speaking with Marco we concluded that we won’t be doing contract work for a good while. We have too many good stuff right now to work on that has caught way too much dust.
Looking back over the past few months, a lot of what we did was neglected because of contracts. They were alright in a way, some for the money, some for the knowledge, some for something else. But unlike our own games, there’s always a part that is missing, regardless of how good the project is. We feel that has to stop and that what moves us forward is our ability to pursue what we want: pride and happyness.
I also feel that both can go hand in hand with stability and stability is what we found in the past months. We need to step up and do our thing. We need to improve what we did for us.
Project wise, that means that we have to put Hajime on FGL, we have to decided what we want for M:A:D and we have to have time for our most promising game. Code wise this means that I have to reflect if we want to keep Bold Pixel public considering that the current version suits our needs more than it suits the initial user friendliness. I strive to keep things simple, to impose convention over configuration as a standard. Right now I’m not that sure that this will fit developers needs to the point that BPE is helpful.
We’ll see about that in the next couple of weeks. Thanks for reading and the therapy session.
Vlad out!
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!
