About a mongth ago, a friend asked me what kind of work is needed to create a game like Funky Phishing? It surprised me that I had no clue. When working on your time and terms, not answering to anybody, seems like there's no reason to keep track of time and effort spent, right? Hmmm. funky phishing is not your normal commercial gameOne thing to keep in mind when looking at this analysis is that Funky Phishing is not your typical commercial game, built on a budged with planned returns etc. It's a concept game, primarily created to explore browser based technologies as a gaming platform. And also because my kids thought that it would be a cool game to play. So, no Unity, Crafty, Lime or any other productive and mature platforms have been used to produce Funky Phishing. It was 100% handcoded in plain JavaScript, hand drawn and painted on a PC, composed using free sound samples in a simple tracker. So could it have been done quicker? Yes, some planning and tools would have gone a long way. Could parts of it been outsourced or split among couple teammates? Definitely, graphics, sound, publishing, all of these things could easily have been split among several people. But in the end, this it how this game was done, and this is what it took. so, how was effort measured then?So I didn't keep track of time, yet I'm breaking down effort here. How's that? Well, primarily, I analyzed source control records: number of source files, their size, number of revisions roughly gave me idea about time spent programming different parts of the game. I rougly recalled time spent working on certain graphics and music elements, and assigned comparable time to other pieces of art. I know total time spent in months and rough weekly time I was able to work, so I was able to fit all these assumptions into that timeframe. In the end, figures here are not 100% exact, but I'm guessing they're somewhere within 10% of the actual figures, so good enough I guess. work breakdown
programming
artwork
other time
conclusionAlthough Funky Phishing is atypical game in many ways, and many things could have been done a lot simpler and quicker, in the end, developing it did provide many insights into state of the web today, and its future.
Cross-platform development in Javascript is very much possible, but still suffers different cross-browser-and-platform issues and is still subpar to native in terms of performance. Graphics artwork: It would proably be a lot quicker and would produce better quality to do graphics using vectors instead of pixels. Pixels are big, and you need to do everything in super high resolution because of new retina displays. Takes space scales poorly. Not very suitable for deployment to all possible form factors. Use vectors. Music artwork: Funky Phishing is special because of precise sync between music and gamaplay, so doing music inhouse made sync easier. For any other type of project, use musicians. Rendering: DOM can be pretty fast when done properly using requestAnimationFrame, careful DOM manipulation etc. Still, done right, Canvas is faster. Haven't tried WebGL since it's not yet widely supported, but that will probably be a blast too. Web graphics are good and promising. Audio: The worst part ot HTML5. Works differently on all platforms, offers different features, neither audio tag, nor WebAudio are clean or capable enough, and neither gives correct control over playback timing at the millisecond level. While on the web, stick with simple background music and simplify sound design as much as possible. Javascript: Pretty fast, pretty unreliable. Some things are fascinatingly fast when done in Javascript, however, on-the-fly optimizations, memory management and different browser engines, will give you a bumpy ride if you're doing a project that requires constant and high framerate. Native wrappers: There are many of them available (Cordova, CocoonJS, Node-Webkit...) they're getting close to really delivering native performance and look and feel, but are not there yet. They're either more massive than native because of incorporated browser runtime, or unreliable and slow because they rely on something native. Choose native wrapper per project and target device, design to easily switch.
2 Comments
It took a while to complete Funky Phishing. It looked like a simple enough game. Three weeks, a month of late night work tops. Well, nine months later, here it finally is. You've been there, done that: start off with a simple concept and aim for a "minimum viable product". Yeah, but minimum viable product is not something you're comfortable sharing. It's ugly, it breaks - it sucks. Not being a person that likes things that suck, so you decide to polish that one thing, and you're off. And yeah, that one too. Hopefully, you reach the light at the end of the tunnel and get to your MVP before you run out of juice and give up on the poor thing. So yes, I did and redid bunch of stuff - audio subsystem was written and rewritten about two dozen times, graphics subsystem about a dozen times. Artwork has been completely redone. Screens? Yep. Hell, even the general story changed once. Check out some of the graphics, v1: And look at the baby now: Some of the changes were purely tecnical. Other purely aestethic. Then there were conceptual changes. Some of this was pure waste of time due to lack of planning and sleep. But mostly, this was a great jurney through latest and greatest web tech and game development and it thought me a lot.
In the end, after a lot of struggle, and with a lot of help from my superhero friends, everything settled to a MVP that is before you. In the following weeks I post all the juicy stuff I picked up during Funky Phishing development, so stay tuned! In the meantime, install Funky Phishing. and let me know what you think! |
AuthorThe Phabulous Phantom ArchivesCategories |