SSX! It's pretty damn fun!

SSX: Deadly Descents is a really well-made game. It's just... fun. The gameplay is well-balanced, with a really nice slew of difficulty levels. There's an astonishing number of courses available to you, and every single one has a plethora of paths. On the other hand, some of them get kind of monotonous, and it's often difficult to tell which one to use in races where the course you pick is almost 100% of the battle.
The thing that really impresses me about SSX is the number of ways to get enjoyment out of the game. I count at least five fun ways to play it: there are race, trick, and survival events, which are all fun on their own. You can compete in global events, which are startlingly fun. Finally, you can go around collecting the geotags left all over the mountains by anyone else playing the game, and finding faraway corners to hide your own geotags in. Everything is uploaded to the network so you can compete against anyone you meet, anyone who picks up your geotags, anyone whose geotags you pick up, anyone who bests your record in a global event...

Global events are really fun - basically, you choose an event (survive, trick, or race on one of the mountains 150-some mountain slopes) and you're entered into a competition over the next few hours/days/week. As scores are collected by everyone playing in it, the total pot of credits available goes up, and everyone's sorted into fairly wide brackets. At the end, you get a payout according to how well you did. I regularly get gold and platinum brackets (second and third out of five), and it's really rewarding. Having constantly varying goals is a really nice change over single player. Also, they introduce restrictions of not using certain equipment. It's an interesting way to level the field a bit, I think. I was surprised by how fun the global events were - in a lot of these things, winning seems like an impossibly far-off goal, but the bracket system is really rewarding.

It's really god-damn fun to rocket off a mountain, do a 4000 degree rotation, break out your wingsuit, and land on a rail. Man. My hands are on fire.

Clustering and communities in multiplayer

So, playing SSX has been fun. It's nice to play with everyone, but the problem is that I don't actually have any friends who play sports games. Or racing games. Or hands-on-fire snowboarding games. So I friended some people on SSX  who picked up my geotags or whatever - but it felt kind of hollow. I've got numbers showing up on my global overview, which is nice, but I just don't care. There's nothing that actually links us.
Similarly, in Mass Effect 3, I play a game with people and then... never see them again. It's a problem in any game without persistent servers and communities and chats. I wonder if there might be a way to foster interpersonal interaction a little more.
The ME3 leaderboards will show you the performance of other people in your country, and in the world, and you can see the top of the rankings and you can see your vicinity in the rankings.
What if a game grouped you with a set of people, completely arbitrarily? Say that when you first log into the network, you get seeded with twenty other people, and it'll disproportionately choose those people when matchmaking. That way, you would consistently see the same people - you could get to know strangers by the way they play.
Better yet, it could be self-regulating, so that if you consistently lose with someone, they get filtered out - or do it by ranking and voting. The point is that it would essentially choose some set of people, arbitrarily at first, and give you those people as playmates.
Maybe it'd shift your 'location' in the space of players periodically - so you'd go a few weeks playing with some group of people, and get the chance to befriend them, and then you'd spend a while playing with other people.

I like Steam/browsable lobby multiplayer because I get consistent people to play with, and I like PSN/XBL multiplayer because I don't have to specifically find a group to play in. Why not get the best of both?

layers of code, and why you should have paid attention in cs 201

I've run into an issue a number of times now. In my mindjail engine, there're several levels of development - I think of there as being four levels, of which I'm concerned with two.

---

At the lowest level, there's window management. I've shoved this off onto pyglet, a lightweight (their website tells me) GL windowing library for python. Pyglet does some things that I know - in an abstract way - how to do: drawing basic shapes, interfacing with the operating system to draw windows, and keeping track of input.

---

At the next level up, most of the meat of my engine is present. The main game's state is in a mindjailengine class, with lists of entities, rules on how and when to update and draw, and a basic physics engine. This level is what I think of as low-level game programming, and I chose to develop in python largely 'cause I felt it'd be easiest to code this 'meat' in an easy language. I'm doing the hard thinking here, so I do it how I think best - in python.

---

Problems really start in the next level - where entities in the game world have behaviors defined. Suppose a missile hits a robot. The previous level of abstraction determined if the missile was currently striking the robot - physics is a universal thing and so it shouldn't happen here*. But missiles explode when they hit things, so the missile should explode - definitely missile-specific behavior.

Our issue is how to separate our code. Presently, it's all close together - all of the missile's behavior is encapsulated in the Missile class in missile.py. But why is this? If we truly think of the behavior of entities in the world as being a totally separate thing then my instincts say they should be in different places in the code.
I did a bit of Lua scripting way back when to make tools in Garry's Mod, and it seems like a scripting language might be the answer. Object management and physics would be handled in python, and then at some point the game would instantiate a Missile object, and in the process would hook in the Missile.lua file to manage how the missile behaves.

But here's my biggest problem: I don't know how to interpret lua, and my game is still under a hundred kilobytes. I don't know how to include a Lua interpreter, which is a stickier subject still - how would I have the Lua scripts adjust things like position and velocity, which are hard-coded into the physics engine? The script/engine interface is more complex than the engine/windowing interface.

This level of abstraction is easy to brush aside when I'm dealing with simple objects, with behaviors as simple as "when I hit something, remove it", but it's going to balloon out horrendously when we get to, say, enemy AI. 

---

A similar problem is presented at the next level, which is the broad-scale game design - the things that make a game Fun. It's not the physics engine, I'll tell you that.
By analogy to object behavior, this would involve having a separate language or interpreter for levels. I was toying with the idea of having levels stored as vector graphics files, with lists of circles drawn at specific locations. I've since thrown that idea mostly out, but the problems remain - if I have a format for my files, I can either have

• a hand-grown format (where my level editor will be notepad and my parser will be a loop with a case-switch statement) or
•  I can use someone else's format (where I might be able to have a graphical editor and parse by means of a call to FormatParser.ParseFile("level1.lvl")).

The second is much nicer - but then I need to include a parser, figure out how formats work, and... it's generally very confusing if I don't know what scale the game's going to have.

---

In the mean time? I'm blocking the game out as best I can all in python. My level format is a text file that gets parsed with a case-switch loop, and my object behaviors are defined in distinct classes. Basically, I'm trying to keep everything separated by sheer force of will, which is okay because I know how everything works.

I've seen this become a major problem, and a major reason for code becoming confusing, in just about every team project I've worked on, and it's a serious argument for having paid attention in software engineering class. This kind of architecture is something to pay attention to, because it means the difference between

• a game with two enemy types because they're such a pain to code that only one person can make them work and
• a game where it's easy to add new enemies and levels and weapons, because it just means adding a few lines to a clean file called 'enemies.py' or 'weapons.py'

I'd like all my game design to happen like the latter. I've made it happen once, but it was right at the end of a project riddled with other holes.

flOw is a really good game and you should check it out.

It's been a while since I last posted. I've got two posts bouncing around in my head, as yet unfinished - one about the excellent SSX, and one about an issue I've encountered in a number of game programming experiences.

Right now what I want to talk about is an older game called flOw, which is really pretty. Really pretty. This is the part where I want to go on and on using phrases like "exquisitely beautiful" and "rapturously gorgeous", but instead of boring you with purple prose I'm just going to post some screenshots.

flOw, annoying as its capitalization may be, is a perfectly calming game with a surprising depth of gameplay. Your objective is to grow your avatar larger and larger and progress to the end of a set of levels. You have a choice of unlockable creature types to play with, each of which has their own peculiarities. The controls are incredibly simple and, basically, the game gets an amazing depth of experience out of not much that you need to do. Really good.

It's available on PSN (about $10 and very worth it) and in a free version as a flash game (not nearly as good, if you ask me)..

flOw is a production of the notable thatgamecompany, responsible most recently for Journey but also for the art game Flower (in which one controls a gust of flower petals blown on a breeze) and Cloud, an incredibly poorly publicized art game which was, I'm pretty sure, the first exposure I had to games as an art form. I remember playing Cloud in my room in middle school, having downloaded it when it was just a project by a group of friends, and being awestruck by how somber it was. It moved me to tears.

I highly recommend checking out their entire catalog of games.