Deliver faster or die trying
The second week flew by quickly, with all seven days spent entirely doing research in several fields concurrently.
When plagiarizing an existing game, there are a few tasks which are already done for you; you don’t need to rethink the wheel, it’s almost finished.
In our case, I know there will be “Goodies” and “Baddies”. There will be resources produced by the Goodies (in the case of PvZ, the sun produced by sunflowers) that are used to place new allies (plants). The playing field is laid out in a grid, which the Baddies march into.
Although the mechanics are quite simple, humans are programmed complicate things (overengineerng is the most common example of this plague).
The time I didn’t spend on game design was thrown away on finding a purist way to make the game multiplatform. Experience has taught me that multiplatform by technology is not a big deal, you are always constrained by the technology promoters. Personally, I was (and still am still) a Flash Architect.
Adobe has claimed many times that Flash is a multiplatform technology. Unfortunately, this definition is not accurate, and it’s becoming less accurate day by day. Flash is a famous example of how hard it really is to develop technology that is truly multiplatform.
When I say ‘Flash’, I’m usually referring to the Flash platform in general, comprised of the language (ActionScript 3), the virtual machine (Flash Player, AIR), and the tools provided. The last option, tools (which includes ide, authoring, etc.), should also be considered when evaluating a technology as multiplatform; not only the consumer, but also the developers need to be taken into account.
The Flash decline (if we can call it that) as a multiplatform solution started with the buzzing war if HTML5 paladins lead by Steve Jobs as Apple decided not to include Flash Player on their iOS devices. I’m not going to discuss this matter further, as many battles have already been fought upon this topic, of which I’m sure you are already aware.
Over time, Adobe started cutting platform resources, and a few AIR branches (first AIR on Linux, and later Flash on mobile devices), while other branches were potentiated, such as the iOS Packager (an LLVM translator for targeting iOS devices)
My point is, embracing a technology has it’s risks. Putting all your faith in a technology controlled and developed by others (especially by corporations that put profitability above all else) is foolish. You must face this fact: a technology will rarely (if ever) answer to all your needs. If you think all your problems can be solved by one single technology, there is something wrong.
I’d like to quote my university teacher of Concurrent and Distributed Systems. He believes that languages and technology in general are just elaborate ways to represent simple things that modern developers don’t want to deal with. Rephrasing that, it all ends up as a series of bits, what differs is how you choose to generate them. Keeping this final purpose of all technology in mind can help avoid extremism and unhealthy attachments and to specific technologies, and keep you from getting overwhelmed when those technologies change.
What I came up with was a typical architectural approach (although, I must admit that my decision was biased).
One of my virtual mentors is Cliff Hall, the creator of the PureMVC framewok (promo time, his book was released a couple of weeks ago, and I highly recommend it). PureMVC has been ported to over 15 different languages,
and it can virtual target in one of his incarnation any device out there.
PureMVC offers a middleware architectural layer: as long as you write code with the framework’s philosophy in mind, you are not bounded to the underlying technology. This allows for framework abstraction and a language agnostic approach.
The MVC pattern allows you to isolate dependencies of the language’s API to only the visual parts (mediators handling the View) and few lines in the Model proxies (the ones that deal with the OS or i/o operations).
Back to the game, using such a framework over-complicates things at the bootstrap phase, but as long as you know the way, you get faster day by day, and the feeling of being safely bounded within the framework encourages you to reduce iteration circles.
True game developers will tell you not to complicate things by introducing architectural frameworks, but as long as you want to target a wider marketplace, an abstraction layer must be introduced to speed things up; PureMVC was my choice.
Back on the game side, I strongly prefer using a runtime scripting language. It happens quite often that large projects lead to high compilation times. Last Monday morning, I decided to track how much time I spent waiting for the compiler. The result? About 30 minutes for one standard work day.
I was looking for an in-game tool to quickly arrange things without recompiling every time.
I’m a fan of Unity3d, and one of the best first impressions that a flash developer notices in the IDE is the play button. You just push it, and your game starts running.
One more time i spend hours in deciding how to reach this result. I was tempted to write my own virtual machine within the technology I pick, or just go for an existing one (note: up to now, I have still not revealed which one, or more, technologies I have chosen).
My final choice was LUA. I don’t want to spend too much time talking about LUA itself, let me just say that I was rude towards LUA in the beginning. I’m not a fun of the language itself, but I’m immensely fascinated by the community around it that keeps pushing it day by day to the Olympus of scripting languages!
But this was another digression. The post title was about fast delivering, and up until now I have been showing off how I introduce delays to the project.
So the remaining three days of the week I decided to speed things up and start working on the game.
As a first action, I forced myself to write out the goals of the week. Always write explicit aims, even if it is a solo project. This is a inner exercise to force yourself to keep the project rolling along. Always set deadlines on short-term goals. There’s no need to decide now that I want this game out 12/12/2012, but there’s a great reason to set the spritesheet stress test for next Friday at 12:00.
My goals were:
- test the basic rendering engine on an iOS/Android/Playbook OS/Windows Phone 7, and stress-test the rendering engine with 100 plants + 100 zombies + 400 bullets
- implement a collision detection system
And the results:
I tested it on an iPad2, and an iPhone 3g. I think I got the chance to work with the top and the lower tier devices running iOS at the moment. It works on both, but unfortunately, the lack of support for Open GS 2.0 on the iPhone 3g slowed things down a lot, and I was not able to reach higher frame-rate during the stress test (stack @10fps).
Now i have two choices, cut out the 3g support and go for the 3gs as a baseline, or just reduce (tweak) the loads in case the games run on a 3g device.
On the android side it was madness. Performance was higher than expected testing on phones with 2.2,3.0 and 4.0. But the fragmentation of colorspace and resolutions scared me a lot. I didn’t think about it at first, but responsive layout design wasn’t enough in such a case. Here is a deeper analysis of my frustration
On the Playbook side I was satisfied enough; great performance even if a weird aspect ratio.
No chance to put my hands on a WP7 device, nor to the Sony S1 & S2.
On the implementation side, the collision system was pretty nice to introduce. I first got into rough box collision with a O(n*m) algorithm complexity (where n are number of shots to test each ticket time, and m the number of zombies). It works but with unacceptable performance.
I later went for a radial collision detection. Faster, since the case were there is no collision is higher than the case were there is. But still not efficient enough.
I decided to exploit the grid structure of the game and implement an R-tree collision system, first using both of the two dimensions, and later using only one dimension (the X axis, since shots fired on one row can hit only zombies in the same row).
The result was quite fast, so I decided to stop my refining process for the moment (even though I’m sure that with a linked list data structure I can increase the performance further)
In the following screenhot, the plants (mushrooms) come from Tado’s Funghi collection, while the zombies (scarecrows) are a CreativeCommons spritesheet, both are used here as placeholders.
In the upcoming days I want to research the marketplace opportunity. I’m particularly interested in the Rim one since it seams Plants vs Zombies was not ported there. I’m also looking forward to digging into these steam statistics >>in order to decide early on how to distribute time resource over single desktop version development.<<