Game Geek Speak

Everyone wants to know how to be successful at what they do. Some people get angry when others succeed (because it isn’t them), and some people get inspired. Lots of people fail, and that’s normal (especially in business). Wasn’t it Edison that said he didn’t fail 1000 times, but rather found 1000 ways not to make a light bulb?

Are there principles that can help you succeed? Maybe understanding what it takes would help you finish.

This video from TED talks describes what Richard St. John believes are the ingredients necessary to brew your own batch of success. I found it inspiring, and I hope that you might, too.

John from the Darkstar forums (and project team member? I’m not sure), has posted a short video of Keith Thompson (one of the Project Darkstar Server engineers) showing a demo at 2009’s Austin GDC. The video is a bit hard to watch if you’re sensitive to shaky motion, but it’s worth it if you’re a big enough geek, like me.

Apparently, the Snowman demo game is running on two servers, and the load can be dynamically managed so that if one server reaches a limit, clients will be moved onto the second server. Interestingly, this means both clients that are logging in and clients that are already in the middle of a game. The load is balanced transparently by Darkstar, with clients continuing without a hitch.

Looks like they also have some decent monitoring tools. I wonder if those will get released to the community?

I wish them all the best, because I’m using Darkstar for most (possibly all) of my future games. Go Darkstar team!!

I’ve taken up the role of Director of Games for an exciting startup called Yawma. It’s an online retailer specifically for digital goods of the indie variety: games, music, applications, etc. The twist is that Yawma has a unique distribution model (which, unfortunately, I cannot say anything about right now). The developer revenue share is generous compared to portal sites like Big Fish Games, Amazon, etc. If I had some downloadable games I thought were worthy of sale, I’d sign up with Yawma myself.

So, if you have a downloadable game you would like to talk about, I can be reached at jason [@] yawma.net.

–Jason

P.S. This doesn’t adversely affect my development progress, because I’m a multitasking madman. *howls at the moon*

The microtransaction bug seems to be going viral these days among the Flash community. There are a growing number of companies offering managed payment services to Flash developers: they handle the dirty backside, and you give them content and share the income.

I personally think that it is worth it to build your own system (and I’m usually the guy saying, “Use the middleware, fool!”). But I think it depends on the scale of what you are planning. In my case, I want total control, and I want to own access to my customers so that I can continue to communicate with them. I also don’t want my games to become advertisements for a payment service.

I don’t view virtual item sales as just a sales channel. It’s also a gesture that means a player cares about and is emotionally invested in the game, and I want to maximize that relationship to make my players happy, long-term customers. Without access to my customers, the payment service is crippling my business. I don’t know that all these systems insulate the developer from his/her customers, but that is a major issue to bear in mind.

These Flash-specific services could be really useful to someone who is making much smaller scale games and wants some add-on sales or someone experimenting with virtual goods in an effort to diminish reliance on ad revenue. I’m not reviewing any of the services, just announcing that they exist. I haven’t investigated them all very deeply, but I will be poking around.

75% – andrograde.com
70% – www.nonoba.com
60% – www.gamersafe.com
60% – www.mochimedia.com
50% – www.heyzap.com

Which is best? It depends on your goals and plans. If you’re just making little quickie games (90% of Flash games), then any of the above would work. If you have a more broadly scoped business plan, you might want to steer clear and look into services that are not Flash-specific and spend the time/money to do the integration yourself.

Java’s ‘instanceof’ keyword is not the same as ActionScript’s ‘is’ keyword. In theory, they do the same thing: find out if an instance of an object implements a class or interface. In reality, they’re quite different.

Java compares for an exact match. ActionScript compares for a match or any subclass of the class being compared.

Let’s say we have class A which implements interface I. And we have class B which is a subclass of A (and implicitly implements interface I).

Java:

if( A instanceof I ) // True
    print( "yeah" );

if( B instanceof A ) // True
    print( "yeah" );

if( B instanceof I ) // False!
    print( "yeah" );

ActionScript:

if( A is I ) // True
    print( "yeah" );

if( B is A ) // True
    print( "yeah" );

if( B is I ) // True!
    print( "yeah" );

So, having learned a lot of ActionScript before diving into Java, I expected ‘instanceof’ to behave just like ‘is’. But no. And that was annoying not to realize at first. So, you’ve been warned!!

Update: Hmm, now I wonder if overloading method parameters behaves the same way as instanceof in Java? I’m going to be safe and make an interface for any classes that have multiple subclasses (ie, categories of entities which require special behaviors). It’s still polymorphic, so I guess it’s “good design.” I haven’t had quite enough experience digging into the reasons for Java’s language design choices.

Update 2: Of course I had to test the behavior of overloaded methods. Turns out that Java isn’t as exacting with overloaded methods–which is a relief!

For example, I have an Entity class, and a subclass called ItemEntity. I need to do some special handling on an ItemEntity (or any subclass of it) in a method that takes Entity as a parameter. Overloading that method to take an ItemEntity gives me the desired behavior for ItemEntity or any subclass of ItemEntity. Yay!

I’ve just finished building my client/server communication loop for Spirits of Gaia. The client is Flash (Flex), and the server is Java (built on Project Darkstar).

Darkstar uses a binary message format, which is a different approach from something like SmartFox, which uses strings (“raw”, XML, or JSON). I had experience with SmartFox, but I hadn’t tried to implement a binary format in Flash before. It really wasn’t bad in the end, and most of my time was spent just learning about ByteBuffers and ByteArrays in ridiculous amounts of detail.

And–of course–one of my bugs probably induced more research than necessary as I attributed malfunctions to various other possible causes. The bug was that I inherited one of the command processing classes from a base class which didn’t implement what I thought it did, so it was silently failing. But I learned a lot. A whole fricken lot! And that’s enough learning for anybody.

So one issue is that you can’t be sure what the endian-ness is for the server or the client. Well, maybe you can, but before now I didn’t know enough about it to make any assumptions. Darkstar uses ByteBuffers to hold incoming messages, and the default for Java is big endian for ByteBuffer. Thus, I use big endian on the server.

I had a feeling that Flash would take care of it for me, but of course I wanted to make sure it was using big endian, too. For a while, though, I didn’t know how to make a ByteArray use big endian or little endian.

My first approach was to get around it entirely by encoding all values that require more than 1 byte into hex strings. What a joyful aside that was! (Sarcasm, you see.) I mean, now I know how to encode anything to hex and back and do it sideways, too. But, this wasn’t working so well and it was bloating the nice binary format anyway. (No, I wasn’t really concerned about the size of the packets based on that, but if there’s a better way and it’s more space efficient–why not?)

Then I dug a bit deeper and realized that you can tell a ByteArray to use big endian like this:

var buffer:ByteArray = new ByteArray();
buffer.endian = Endian.BIG_ENDIAN;

Hard, huh? So then I didn’t need to encode multi-byte values into fun hex strings anymore (with one exception). So my PacketBuffer class got a bit more efficient in speed and size, and all is well now.

The one exception is for Java long values, which are 8 bytes. Flash (as far as I know) has no way to pull an 8-byte value from a ByteArray. And, no, I don’t want to do it by hand–which doesn’t mean I won’t! If encoding to hex string doesn’t work out, then I’ll write some code to stitch 8 bytes into a long value and stuff that into a Number (since it won’t fit into a 4-byte int). But, honestly, that kind of stuff is not my cup of tea because it’s not fun to me. But if it’s gotta be done, I’m a professional, so I’ll buckle down and do it. Clearly, I want to whine about it a lot just in case I do really need to do it.

For completeness, you tell a Java ByteBuffer to use big endian like this:

final ByteBuffer buffer = ByteBuffer.allocate( someSize );
buffer.order( ByteOrder.BIG_ENDIAN );

I think it’s ok to assume that Java (and Darkstar) will still default to big endian on whatever OS my future game server will be running (a flavor of Linux, no doubt). If I run into some bizarre bug where command ids are getting scrambled, I’ll know the first place to look.

You can’t really swing a dead cat without hitting somebody’s virtual goods payment platform anymore. I mean, there’s fatfoogoo, Gambit, TwoFish, TrialPay, Mochi Coins, PayByCash, LiveGamer, UKash, Kongregate (in November) and on and on and on. I just scratched the surface there.

It’s really getting crowded! With my new game project in production, I’m starting to wonder which one I can trust to still be around in a couple of years. There are so many, I can’t see the market supporting them all.

Some of them are “big accounts only” type companies, where you can’t find pricing or really any information on their websites without calling them. And they expect you to be a million-dollar funded company. Those types will be servicing EA and UbiSoft and other large companies. Whether they are around or not doesn’t matter to me because I won’t be their client anyway.

The others are scrappy and service small companies. These are the guys I’m likely to do business with, but also the ones most likely to bite the dust when the shakedown happens. They just won’t all have the customer base to make it through a financial storm on top of vicious competition due to overcrowding.

Anyone have experience with these companies? Which ones do you like, and what services make them stand out? Some offer great looking metrics and other perks. I’m in the market and looking right now.

I’m starting on a new game project! There’s a minimal site and blog for it. Please have a look.

Spirits of Gaia: an online multiplayer world.

I am building the server side code on Project Darkstar. I’ve already got a pretty nice hunk of code constructed, but there’s a long way to go still. I haven’t started on the client at all, but it will be built on the PushButton Engine.

Well, I’ve spent a lot of time with Project Darkstar. I put in tens of hours reading forum posts and anything else I could get my hands on. I built a very simple MUD with it, and I looked through a bunch of other people’s code. When Darkstar delivers, it will be really amazing, and what exists today is already very cool. It offers solutions to some monstrously difficult problems.

Probably the best thing I found was that you can treat your game logic like a single threaded application. You never have to touch locks or synchronization unless you go under the application layer (a place I feared to tread).

The data store is also really cool, because you can stop worrying about game crashes and if that will force you to roll back hours of gameplay–it won’t. At most, a few seconds are lost. That’s a huge worry out of the way. One problem here, though, is that there’s no easy way to upgrade or patch the data store unless you wipe it and restart from scratch. You’ll have to write a custom tool to update it without wiping it.

All that said, the real issue holding Darkstar back right now is that it simply isn’t finished. It’s almost finished (give it 6 more months), but there’s one key feature that is a show stopper for me: it doesn’t scale. It can’t do anything besides a single-node right now. If you run multi-node, each node will be isolated, which is the same end result.

This really disappoints me, because the technology is otherwise really powerful, and I like it a lot. Sometime near the end of 2009, the roadmap says the PDS team will have multinode completed. When that happens, Darkstar will finally be a very potent game server solution! And I’ll be going back to it.

Until then, what next? I’m going to look into the Neutron service from Exit Games. (Update: After some deeper digging, I don’t think this is what I’m looking for, although I will still give it an eyeball. It also feels like it’s going to be on the expensive side.)

(Update 2: After some pacing around the house and thinking, I have come up with a couple of options for how to continue to use Darkstar for my upcoming game. I haven’t decided exactly what path to take yet, but I think it will be worth it to try and make it work. I’m counting on you, Darkstar team!! )

I found this article very interesting and relevant to indie game developers, so I thought I would spread the love.

When an underdog fought like David, he usually won. But most of the time underdogs didn’t fight like David. Of the two hundred and two lopsided conflicts in Arreguín-Toft’s database, the underdog chose to go toe to toe with Goliath the conventional way a hundred and fifty-two times—and lost a hundred and nineteen times.

We tell ourselves that skill is the precious resource and effort is the commodity. It’s the other way around. Effort can trump ability—legs, in Saxe’s formulation, can overpower arms—because relentless effort is in fact something rarer than the ability to engage in some finely tuned act of motor coordination.

Insurgents work harder than Goliath. But their other advantage is that they will do what is “socially horrifying”—they will challenge the conventions about how battles are supposed to be fought. All the things that distinguish the ideal basketball player are acts of skill and coordination. When the game becomes about effort over ability, it becomes unrecognizable—a shocking mixture of broken plays and flailing limbs and usually competent players panicking and throwing the ball out of bounds. You have to be outside the establishment to have the audacity to play it that way.

Read more of How David Beats Goliath: When underdogs break the rules.