I had some breakthrough moments. After many nights of staring at diagrams like this:

Right…but how much linear momentum is left over?

…I was finally able to create a realistic response to impulses at an arbitrary location.  I guess an engineering degree is useful for more than linear algebra.  Realizing that you are deriving the parallel axis theorem the hard way falls into that group.  Anyway!

SUCCESS!

Voilà!

As is obvious, I still have many missing features.  The collisions are not reliable or clean.  My collisions only respond to vertex collisions.  My edge-edge detection is terrible (faked by multiple vertex collisions).  It’s not apparent, but my collision detection is a spaghetti mess, and the collision resolution is shoehorned right into the same code.  My broadphase is nonexistent.

Bittersweet though it may be

Long story short…I need a big refactor.  I need to gut all my progress, and revise it to make it work properly.  I would love for it to smoothly handles collisions in more circumstances.  But I want to play around with what I’ve got! I want to see if I can get some fun gameplay going!  Quandry!

Truth be told, I’m already a little sick of implementing physics.  A. That’s not a good mental position for starting over.  B.  I want to implement more game, less engine.  C.  I have reconsidered using a physics library…and it might be appropriate.  D. I have enough of a working base to start doing things with it.

So I’m writing managed code, right?  C#, in all it’s OO-featureful glory?  I ought to be able to take my existing physics manager class, and use it for gameplay, and go back later and completely change it.  Right?  That’s how well-defined components and internal APIs work.

Terrifying.  But fuck it, let’s go for it.

So what else is going on

I have professional opportunity to hone my wordpress skills.  I believe I learn new skills best when I have a task to complete.  So I’ve come up with a few blog features that I hope to implement soon.  I added a new field to my posts to allow for longer titles, without screwing up the slugs or whatever.  It turns out that adding the field is trivial.  Popping it into the theme is useful, though.

My other idea is to create a place for me to park my non sequitur rants and stories within my posts.  I would like my posts to be on-topic, but I still want to write down random crap.  Hopefully I can work this out.

Like that title?  Google hits, here we come.  It’s not meant to be misleading, but it may not be what a person would want to find on www.google.com.  Nobody will learn how to program by reading this article.

No, I’m writing to help myself hash out the fundamental pieces of the physics I want to implement.  I’ve written before about the features I need.  It is my opinion that there is not a pre-made physics system which will provide those features.  Even if there was, I would miss out on that understanding that only comes from trying and failing.  For reference, here’s that short set of features:

Deformability

Not a soft-body physics system, but rather rigid bodies that may be modified by infrequent events.  Rigid body mechanics most of the time, but objects that react with more variety than the AngryBirds™ puff of smoke.

Platforming

Mario, Braid-guy, and (maybe most dramatically) Sonic do not feature simple 2D physics.  Rather, they have both less and more.  Their motions are custom, their environments mostly static.  They do this for good control feel, for character actions other than standing and bumping into walls.  I want to do all that AND have realistically moving environments.

Should be easy, right?  HAHAHAHAHAhahahell no.  But I’m going to do it anyway.

Object definition

All my physics objects will be instantiated with a simple list of vertices, with position relative to their object’s center of motion.  For soon-to-be-explained reasons, I’ll store those as a struct for both position and texture coordinate.  To use those structures for both physics and drawing, I’ll keep separate collections of indexes for drawing and for convex hulls.  This will avoid the need for data duplication, while still allowing efficient batching of draws and collision interactions.  Here’s a diagram:

Indexes into vertex buffer data, allowing both drawing and collision detection

Quads and Collisions, Merged Vertices

When my physics objects change their shapes, I obviously want that to reflect visually and in their physics.  To draw the deformation, I need the same motion of vertices as required in the colliding shapes.  If each texture coordinate was stored separately from the vertex, I would need to somehow align those data when I made any change.  Surely any system that did that would have a bigger memory and cycle consumption that simply storing the coordinates in the same struct as the vertex.

Also, storing multiple indices allows a couple storage optimizations.  All the data is in one place, but if either operation does not require a given set of data, it can simply be skipped in the index collection.  For example, although I will need 3 coordinates per triangle, I will not have to store any duplicates.  There will be multiple references to a vertex instead (standard indexing benefit there). But, the collisions also get the benefit.  They can index the vertices they need, arranged as the edges between them, and ignore internal vertices that don’t matter to collisions.  AND! I can store a convex hull and multiple concave areas, all using the same data.

Where in the world

Each object has these vertices that change, but they’re all in local space.  For converting to world coordinates, I’ll need a transformer.  I intend to define my own 3×3 Matrix (I can’t easily use XNA’s 4×4 system).  That gives rotation and translation in convenient operation, which can be updated independently of the vertex data itself.  Perfect.

It can be applied to each vertex prior to drawing, giving O(n) for that.  Worse for colliding, but I have a plan for dealing with that.

Half-space magic collisions

I don’t want to do 6 multiplications and 4 additions for each reference to a vertex (not counting what I actually do with it), per collision test.  Instead, vertices will reside in their local coordinates, and the edges get the transform.  Specifically, I’ll keep a set of slabs (halfspace pairs) for an object being checked.  Each slab needs a single direction vector and two distances.  The directions are converted to the local vertex coordinates, then both object’s translations are added.  These values need only be calculated once per pair of objects, rather than once per vertex.

After that, It’s all dot products with early exit.  I believe this will provide enough efficiency for me use a very crude broad phase, such as bounding circles per object.

Then what?

Eventually, I’ll need to do something with those collision tests.  Impulse, or some sort of force collection…something.  I’ll have a simple, single location to apply those forces, at least.

I’m going to get to work on drawing the quads first.

Hey folks, very little game making progress this week.  But I made lots of progress on playing a game that was made out of a website!  You contribute to community of helpful information, and then you get points!  It’s like every other game where you shoot hordes of zombies in the head, except instead its hordes of people asking each other how to make games, and you shoot them full of answers.  Anyway, I managed to grind my way up to 4 digits worth of those points.  Voila!

Also, stack exchange is more gratifying than killing zombies, because people actually benefit from your posts.  And only helpful posts get points.  And helping others is fun.

I don’t want to imply that I have made no progress on my game. I have attempted to implement 2D physics in a quick and dirty way, and I’ve realized that I require a custom 2D system (XNA’s SpriteBatch won’t cut it). I also got into a good argument with a coworker about whether or not to roll my own 2D physics. I’m not sure I convinced him. But I have still convinced myself, reaffirming that I need non-convex and deform-able shapes. I’m not going to get that in a free library.

Except maybe Havok’s new free framework…

The latest thing that has kept me from the game dev is this gem:  http://nodewar.com/.  It’s a programming game in which you design the AI for a small swarm of melee spaceship triangles.  The game features realistic-ish physics and n-body gravitation.  There are three moons ready to kill you on contact, and the legal field of play is a constantly shrinking circle.

Nodewar exists entirely within the browser, including a pretty good javascript editor.  You can also write in coffeescript, if you are one of those Ruby weirdos.  You can submit your AI to a public ladder.  Whoever is at the top of that ladder at the end of month wins 10 bitcoins.  (Or they might give you $2000 instead, because bitcoins are so ridiculously unstable.)

Programming games have a special place in my heart, because my only juvenile programming experience was playing Robot Battle.  This one grabbed me too, but I’m not sure I’ll stick with it.  Still, I’m having fun with this alpha/contest.  My AI based on simple orbit-keeping looks somewhat impressive, although it has no mode where it actually attempts to kill anything.

But tonight, I’m working on my own physics engine.  Here’s what it needs:

1. Concave shapes
2. Platformer physics compatibility
3. Destroyable objects

If you have some familiarity with physics libraries, you may note that these features are present neither in Box2D nor any of its myriad ports.  Hence the decision to make my own physics system.  Sure, creating a physics library is a giant undertaking, but I’ve got a few thing going for me in my attempt to create it.  The first is a reasonably good physics education, having gradated from this school (it helps with the “space” battle programming games, too).  The 2nd is that I don’t have to design some massive physics simulation, but merely a small feature set.  I get the features I want the way that I want, without having to learn a foreign API.  Good all-around.

Too much writing; must make progress!

Today’s post has nothing to do with Easter or Mel Gibson.  That may have been obvious from the prototype alliteration.  No, no, this post is about conflicting advice from noted independent game developers.  Looking at these adages now, it seems obvious to me that they oppose each other.  But I only recently had this notion, after absorbing a large quantity of video interviews.  So I’d like to express my…revelation?  Inspiration?  Stupid opinion; that’s what I was going for.

Three pieces of advice:

1. Make lots of games.
2. Make lots of prototypes instead of making games.
3. Love your games; imbue them with quality using that love.

Numbers one and two directly oppose each other.  And number three seems to oppose both of the other two.  Let’s get on with a little more detail.

If you want to become an indie game developer, make lots of games.

Everyone who has ever spoken publicly about indie development has said this.  It’s plainly true.  The barriers to learning to create games are virtually nonexistent, except in the minds of people who don’t do it.  Anyone who owns a computer can find a free, inexhaustible quantity of starter resources and mixed-quality advice.  So the only reason that a person can’t make games is that they prefer to assume they will fail at something, rather than actually try and have a hope of not failing.

BUT! I don’t want to say that “just not getting started” is an unfathomable failure.  I suffer from it.  I can think of all kinds of terrible excuses for not making games, such as “I need to sleep to not get fired from my job”, or “I want my children to recognize me and not shy away from the minuscule gestures of affection I give them”.  People who have already overcome the problem and actively make their living as developers understand it.  Anyone who “just doesn’t get around to” anything understands it.  Sometimes, humans are lazy and don’t accomplish things, in spite of having all required opportunity and skill.

There’s another facet to this advice, though.  Edmund McMillen always notes that before making very high quality games, he made a plethora of awful, awful games.  He refers to it as a learning exercise.  Making games is the kind of skill you can only gain by doing it.  Coding works the same way, although the ability to code does not constitute the ability to make a good game.  It’s more similar to writing.  Read lots of books, practice writing (get an editor, because their job is to make you write better), show your writing to lots of people and get lots of feedback so that you can improve.  In exactly the same way, making lots of games is a must for an indie developer wannabe.

Who disagrees?  Oh, nobody you know, just some guy called Jonathan Blow.  He doesn’t really disagree that people learning to make games need to make a lot of games.  As a matter of fact, he is on record as being in the group of “Everybody” who believes in the first piece of advice.  But Mr. Blow is no game development learner.  An industry veteran, columnist, consultant and lecturer, he doesn’t need to figure out how to break into game development.  Instead, he has advice for how to make games that don’t suck: don’t make them.

Instead of making game, make prototypes.

Prototypes show you how a game works without the time investment of a full game.  In his paraphrased words, “you only have a limited amount of time on the Earth, so you want to choose carefully which projects you devote years to.”  Sure.  Make game-ish things, don’t worry about creating a complete package, wait for a great idea to fall out of your experiments.

But how many years should be devoted to learning to make games?  How much time should you “waste” in transitioning from a person who never makes a whole game, to a person who actually completes a game?  There must be some transition from making lots of crappy games to making only excellent games that you choose.  Maybe that transition is completely smooth, like any artist growing into their prime.  Either way, both tactics are at odds with the third piece of advice.

Pour your whole soul into your game.

Jonathan Blow certainly believes this.  He takes “games-as-art” to an almost elitist level.  His idea of a good game is something that portrays an abstract emotion and forces a player to feel something while playing.  He’s not wrong, but he exists somewhat outside the common purview of game players.  That’s his prerogative, as he certainly is a connoisseur of game development.

But he’s also not alone.  McMillen, that outspoken advocate of making a big stinking pile of games, also discusses an obsession with making his game perfect.  Designing with the videogame version of literary symbolism in mind.  Making a character that is based on his childhood.  Everyday shooter’s Jonathan Mak thinks that every facet of indie development is secondary to making something that is meaningful to its creator.  Originality, good features, artistic quality can all slide, as long as you love your game.  If it is well received, fine.  But the ART is what matters.

To summarize this 3-way tug of war:

1. Make a whole lot of crappy games as fast as you can.  
2. Only make the really good games, so that you don’t waste time making crappy games.  Throw away the crappy ones.
3. Invest your very soul into every game you make, even if they are crappy.

STFU, you know-nothing hack!

Indeed!  I have no authority to criticize any of these folks or their methodologies or advice.  But I have a strong interest in overcoming my lack of experience and making a great game.  So what can this set of advice do for me?

I’ve been experimenting with various projects on this blog.  That javascript maze, the text adventure, some XNA bits and pieces…but I haven’t really thought of those as prototypes.  I’ve thought of them as reasonably scoped projects, so that I could build up my pile of crappy games.  But in retrospect, making a pile of games purely for the sake of making a pile defeats the purpose.  I’m not learning to make games, I’m learning to make throwaway items.

So if I called my work thusfar prototypes, would that make it better?  Kind of!  I realized my maze idea was not fun before I invested a lot of heartbreak into difficult ancillary features, so that was good.  I realized that making a text adventure game in pure C with no global variables or memory allocation is euthanasibly stupid.  I realized that Unity’s physics is no magic bullet.

But am I any closer to having a real game out there?  No.

So here’s what I intend to do about that.  I think that what my games have been lacking is not initiative or technical chops or willingness to experiment.  I’ve been missing the love.  I want to work on a game that I love.  I want to pull a Phil Fish and bite off waaaay more game than I can chew.  On the one hand, this will limit my options, and I certainly love changing projects. But I want more than anything to finish a formal project.  If I’m going to get there, I need to love my idea.

I haven’t loved anything that I’ve worked on lately.  I will endeavor to fix that.

I’ve spent the last three nights not doing any development.  There have been about 12 hours (thanks for the tally, Steam) dedicated to playing and completing Antichamber. It’s a great game, I strongly recommend.  I still can’t decide whether I actually enjoyed it.  It seemed to me that too many of the puzzles weren’t based on reasoning, but instead required trial and error, or continual restarts to check the map to see what random teleport actually happened.  It reminded me of a summer camp card game where only the dealer knew the rules and talking wasn’t allowed.

Again, great game, a very good buy and highly enjoyable.  A lot of the puzzles were based on reasoning, and even though I just called those teleports random, they were actually completely reliable and predictable (and bizarre and infuriating).  I may yet attempt the speed run which is implied by the 90 minute countdown timer.  Of course, that would mean playing through it 8 times faster.

And no matter what, I am overdue for game making.  Today I got to see a friend’s project videos, and I hope their project goes to completion and a warm reception by the public.  Seeing other folk’s progress always inspires me to make some of my own.