Mockingbird on Kongregate
Posted
December 10, 2008 
Comments(3)
Comments(3)
We’ve posted our first build of Mockingbird on Kongregate. It’s a platformer kit… start runnin’ and jumpin’!
Over the next week, we’re going to rework this version of Mockingbird and re-integrate it into our site. New things on the way…
Hey Troy,
Congratulation for getting Mockingbird on Kongregate. Let us know how it goes!
Also I’ve fooled around with it a bit and my main suggestion is that you get better (as in more coherent) artwork. For example, you don’t really want to have puffs of smoke or bananas presented as “player”. I understand that you can’t account for the player’s creativity and what he’ll want to do but this is just confusing… Let him upload a banana if he really needs to but give him default avatars that look like avatars.
Also a question regarding the flow: why did you place the goals at the bottom of the tab menu?
Again, great job!
O.
Thanks, Olivier. Appreciate the comments…
Re: artwork — do you really think it’s that confusing? My wife was a bit confused, but not so much by their inclusion but more about the labeling of what she was doing (a definite problem in the Kongregate build as it is somewhat minimalist in labeling). At one time we sorted the artwork so that “avatars” came first, then vehicles, then inanimate objects, then scenery, then effects and bullets. Currently, the art list is shuffled each play (the intent being to inspire/encourage variety in the games made as folks tended to choose from the first page instead of exploring).
I’d love to have a catalog of artwork 2x or 3x (hell, 10x!) in size with some organization. As I’ve advocated in other blog posts, I think a lot of fun can be had in game making solely through personalizing the aesthetics and doing the level building (as opposed to having to create at the game mechanic level).
Re: goals and flow — we’ve constantly gone back and forth on this one. For a lot of folks, the immediate gratification is in choosing their players and props artwork, followed by the game’s background. They then have fun choosing sound effects and filling in the text/speech bubbles. Choosing the goals always seems to fall as either a secondary/unimportant aspect of the “kit” (the defaults are fine if we assume we’re already making a platformer) *or* they’re a guiding decision for building the level (my goal is to reach the end before time runs out, so I’ll build the level around that).
Like many things, the feedback from users seems to fall into two typical camps: form and function. The form folks (or aesthetics, or narrativists, pick your poison) are principally focused on building a game about the specific artwork they choose in the specific setting they choose (a robot in space fighting aliens). The function folks (or mechanics, or ludics) mainly use the artwork as symbols for the underlying mechanics (a stick figure implies running and jumping, a spaceship implies Asteroids-style flying and shooting) and think of their game in terms of an end goal with challenges to get to that goal.
For us game geeks (game designers, programmers, academics) we most often fall into the function category. But for the larger population of casual game players (or primary target audience), they’re more into the narrative. Ask your average Joe the Gamer (or a ten year old) to pitch a game and it’ll have the most interesting detail in the aesthetics (”It’s ninjas vs. pirates in space!”) and the most broad, vague details in the mechanics (”It’s a 3rd person shooter.”).
When we had this realization, we shifted the workflow focus toward the aesthetics: we introduced an emphasis on the game’s “story”, we introduced the speech bubbles, and we made personalizing the artwork the initial activity. With kits — which have been 5x more popular than non-kits (and have been what all of our licensing partners have wanted so far) — the user doesn’t even get to craft the mechanics but rather just do “level editing” with known, familiar mechanics.
All that said, I think there’s room for both styles. I’m constantly trying to find a workflow that seamlessly accommodates both. The worry is that the mechanics can be the “hard” part — or, at least, the part where folks are most likely to get in over their head or create broken games without knowing why. Kits, unfortunately, remove the fun experience of exploring interesting and new mechanics, which is a unique offering of our platform compared with the others out there.
Where I’d like to go with the next iteration of our app (the “sandbox” version) is to have the notion of kits, but to do it at the object level instead of the game level. This will require a smooth integration of our advanced “designer” toolset with our new Kongregate-only (for now) level stamper toolset. I’m exploring that over Christmas… and depending on scheduling with our partners, may actually end up with something to show in January!
Hey again,
Yes, I do find it confusing. I’d agree that the problem stems form a disconnect between the labeling and the arworks but I don’t think you can fix it simply by tweaking the labels. IMO the fact that it’s a single set of artwork randomly displayed clearly doesn’t help.
For what it’s worth, I think Jason’s email on the PH list is spot on.
If you really don’t want to go the full tool route, you have to clarify segmentation and increase contrast : I was suggesting to do that inside the current app by having more specialized artwork sets and keeping them separated but I suspect he’s completely right so that would probably not be enough. It might be time for a radical change…
Thanks for the explanation regarding goals & flow: I knew there was a reason why you put it there and I’m glad I heard it.