Improving F2P

 Posted by (Visited 31735 times)  Game talk  Tagged with: , ,
Jan 092012
 

Are you one of those game developers who think that free-to-play games suck? You think they’re soulless, or that their builders do not understand how to treat a customer? Or why games are sacred and special?

After all, f2P developers are often looked down upon by traditional game developers, particularly indie ones, as not being artistic.

Well, in the spirit of greater understanding on all fronts, I’m here to tell you how to understand these developers.

The thing to understand about the free-to-play market, and its best developers, is that F2P developers treat everything as science. Everything is subject to analysis, and everything is subject to proof, and the business process is about seeking what works. If what works happens to also be an original, innovative, interesting design that meets a checklist set of criteria for being art, well, all the better. But really, it’s about what works.

We have to be honest with ourselves. There is an awful lot of stuff that we have cherished for a long time in the games business which turns out not to work. Sometimes it takes us years to shed the scales from our eyes about the fact that hoary conventions of yore are just that — conventions, mutable and open to change.

A screenshot from the Atari version of Panzer-Jagd.

A screenshot from the Atari version of Panzer-Jagd.

After all, was not the great innovation of World of Warcraft that it “removed the tedious bits”? Many of those tedious bits were “proven mechanisms.” And regardless of whether we feel that some babies went out with the bathwater, there’s a certain part of you that has to go with what worked — and if a few babies going out with the scummy water is the price, then, well, it can be hard to argue against.

There is also the plain fact that it takes a player to play a game. What worked for grognards  who were willing to fix the BASIC errors in Panzer-Jagd on the Atari 8-bit (*sheepishly raises hand*) does not necessarily work for the player who delighted in Doom, which in turn fails the player tossing angry red birds at hapless pigs.

The field moves on because the audience does, and what works moves with it. Having some science in the mix to track, assess, and predict those movements is only common sense.

And the more the audience divorces itself from we who make their entertainment, the more important it is that we be clear-eyed about what their tastes and behaviors actually are. And that, in turn, greatly undermines the value of “experts,” — because we are in many ways, the most likely to be hidebound and unable to see past the blinkered assumptions precisely because we built them up with hard-won experience.

But! And it’s a big but.

Continue reading »

Pics from Anime LA

 Posted by (Visited 12859 times)  Misc, Watching  Tagged with: , ,
Jan 082012
 

Here is an assortment of pictures from yesterday at Anime LA. I spent the day there shepherding a gaggle of teen girls who were all doing Homestuck cosplay.

If you watch my Twitter feed, you have already seen these. The one of Darth Vader as #1 dad went a tiny bit viral. There are also a TARDIS, a bunch of candids as people try to eat hamburgers while in costume, a
walking rage comic that was my favorite costume of the show, and of course, there is an arrow to the knee.

Continue reading »

Some times you should write new code

 Posted by (Visited 7055 times)  Game talk  Tagged with: ,
Jan 072012
 

A fair amount of folks have taken the last few posts (on making games more cheaply and on rigid programming philosophies) to a bit of an extreme further than I intended. So in the spirit of contradicting myself, here are some good reasons to write new code.

When you have something new to learn.

I still remember how proud I was when I independently invented the bubble sort in response to a problem. Then how baffled I was when I tried to figure out how quicksort works.

Writing your own version of a known solution is a fantastic learning tool.  Trying to learn how to write jazz progressions? Grab a jazz song, change the key, and start modestly tweaking the chords (an 11th into an augmented, or whatever). Then build your own melody on top of it. Trying to learn how to draw? Start copying people who know how. Trying to figure out how a given game genre works? Try cloning or reverse-engineering a game in that genre. It’s a classic method of learning and there is no shame in it. If you have any creative spark, you’ll quickly move past this sort of journeyman work and start adding your own elements to it. (This is one of my caveats to Dan Cook’s post on game cloning).

Continue reading »

 Comments Off on Some times you should write new code

More on making games cheaply

 Posted by (Visited 12199 times)  Game talk  Tagged with: ,
Jan 062012
 

I only offered 6 points, but 3 of them are ones that people are wanting to argue about! 🙂 I suppose that is a pretty good hit rate…

A few folks took exception to my comment that “code doesn’t rot, our ability to read it does.”

The first objection is that most code is born rotten, that it is rare to find code written to the standards that allow it to be easily maintained. I can’t really argue with that, though of course there are plenty of practices that ameliorate this: code reviews, code standards, etc. I’d answer with “that’s just code where our ability to read it perished as it was being typed.”

The second objection is basically that platforms shift out from under code. This is absolutely true — but is also a sign that you’re not actively maintaining your codebase. Times of truly catastrophic platform shifts where everything you did is invalidated should be relatively rare these days, honestly.

Continue reading »

My biggest coding takeaway

 Posted by (Visited 11205 times)  Game talk  Tagged with: ,
Jan 052012
 

Rigid programming philosophies are the devil.

Look, I am upfront about the fact that I am not an amazing programmer. I am not even a really competent one. I hack. I didn’t go through a CS degree, I don’t actually know a lot of the lingo, etc.

On the other hand, I have in fact been credited as a programmer on published games. I have programmed in quite a lot of languages, I prototype my own stuff regularly, and my name is on several technical patents. I seem to have a knack for seeing architectural solutions to problems, and for inventing technical solutions. (I generally prefer to partner with a genius coder for the actual implementation thereof — and have been lucky enough to work with many of them!).

So take everything I am about to say with the appropriate grain of salt.

Continue reading »