Wednesday, September 5, 2012

Constrained mode support

FlashPlayer 11.4 was released recently and now many more users will be able to use  hardware  3D-rendering in Flash. Earlier versions of FlashPlayer 11 support hardware rendering for devices   manufactured after 2008. The constrained mode extends this support to all devices released since 2005. For example, almost one third  of TankiOnline players will be able to use GPU rendering thanks to the constrained mode support. (Around two third of the players already have GPU support and less than ten percent still use the old version of the Flash player that doesn’t support hardware rendering at all) Incidentally, your application should be ready to work in constrained mode as well as FlashPlayer on the user side. This is easy to achieve with Alternativa3D 8.32.

How does it work?

In order to make your application work in constrained mode you just should set the second parameter of stage3D.requestContext3D() when requesting the context, in the following way:
stage3D.requestContext3D(Context3DRenderMode.AUTO, Context3DProfile.BASELINE_CONSTRAINED);
Context3DProfile class appears with API of the 11.4 version of FlashPlayer so you need to update your playerglobal.swc (or use hardcoded string constant – "baselineConstrained"); If you wish to enable constrained mode only if normal hardware rendering is unavailable, you can request the context as usual then check which mode is set and, if after you receive it, the software rendering mode is set, you should request the context again, this time in constrained mode.

What do you get with Alternativa3D in Constrained mode?

[...]
Read more: Constrained mode support

Saturday, September 1, 2012

How To Make Better Games

I don’t get out anywhere near enough these days, so my boss sent me off to the Edinburgh International Technology Festival. I must admit, there was a great mix of presentations over the two days, but it was the gaming related talks that I found of most interest, and I’d like to share some of what I learned. Over the last year or so at WeeWorld, we’ve become increasingly focussed on mobile games development, and I was curious to see if our approach to development was at all similar to what others do. So I was pleasantly surprised to hear from CEO of Denki, Colin Anderson, who gave a great overview of the process that they used when writing their hit iOS game, Quarrel. Reassuringly, it looks like my current project is following a similar path to Denki’s. There was also a huge number of great points from the many other speakers, which I’ll attempt to summarise along with Colin’s suggestions.

90% of games revenue is generated by less than 10% of releases

It’s a sobering thought, but the reality is that very few games actually make any money. There’s nothing more frustrating than spending 6-9 months writing a game that doesn’t sell. Even simple games are expensive to make, so it’s important that you do everything in your power to ensure you create a game that stands a fighting chance of actually recouping it’s costs and then some.

Find fun first

It may seem obvious, but when you hit upon an idea you have to make sure that its core element is fun. Be it in the real world or digital, making games starts with play. It’s a concept we’re all familiar with, as playing and having fun is something we all did as children. And we all invented our own games by making up rules as we played. Of course, some attempts were more successful than others, but games that didn’t engage or entertain us were quickly discarded and forgotten about. Creating video games is really no different. Latch onto a simple concept that’s fun and then apply some rules. And remember, your ultimate goal is to design something for other people. So don’t be selfish; invent with others in mind. And if your idea isn’t fun from the beginning, then it probably never will be.

Fail fast but fail small

The quality of your game doesn’t guarantee success but it’s safe to assume that the better your game, the more chance it has of succeeding. Therefore, if it looks like you’re working on a stinker then it’s better to know this as soon as possible and move onto a different idea. Again think back to when you were a kid. You ever spend months refining a game idea that wasn’t working? Of course not, kids are pretty unforgiving and just quickly move onto something else. Games developers really should do the same. Companies such as Denki takes this very approach. They evaluate their project at various key points and identify as early as possible whether or not their idea is worth continuing with. Here’s roughly how Denki went about developing Quarrel for iPhone:
  1. Started with a simple concept image and statement.
  2. Produced concept art
  3. Developed an internal prototype
  4. Developed an external prototype
  5. Game production
This approach provides ample opportunity to bail out if the idea isn’t working. Early steps in the process are fairly inexpensive compared to the later steps and also take considerably less time to complete. I’m a great believer in rapid prototyping so it was great to see Denki working on two prototypes of Quarrel before committing to the final game. How a player will interact with your game in the real world will be entirely different to what they will do in your head. This point alone makes prototyping critical as you can relatively quickly determine whether it’s worth continuing with your idea. It also gives invaluable feedback that can be used to improve the final game or a second prototype if you choose to continue.

Creatives love to talk more than they like to listen

An audience member had stated that he’d worked with many excellent creative directors over the years, and that not one of them had managed to create a decent game. Speaker, Mark Sorrell, responding to this by saying rather controversially that “Creatives love to talk more than they like to listen”. There’s a lot of truth in what Mark said, but I think it extends to all of us. It’s really important that you aren’t precious with your ideas. If something isn’t working then don’t be afraid to drop it, or at the very least attempt to change it. Of course, when you’re so close to a project, it’s not always easy to tell if something isn’t working, that’s why you really need to listen to others. You’ll get nowhere if you, or your team, decides to work in isolation. At WeeWorld we’ve been making changes to our prototypes based on invaluable user feedback. For our earlier prototype that feedback was purely from those within the company. However, we’ve gradually opened that up to external play testers, which has lead to significant changes being made. User testing is vital, but you still need to make sure you take that feedback on board. It’s all too easy to collect valuable information from user testing and then simply ignore it because it will lead to more work. You also need to learn how to sift through the noise. This is particularly important when you have performed a large number of user tests. You’ll need to focus and identify the common complaints rather than trying to address everything. Ultimately don’t be afraid to admit when an idea of your own isn’t working. The worst thing you can do is push through an idea that negatively impacts a project. I know it sounds like common sense, but it’s something that most of us are guilty of [...]
Read more: How To Make Better Games