Twigbits

I enjoy a good platformer. I especially enjoy a good platformer with a unique gimmick that doesn’t feel like a gimmick! I think I have an idea. It probably feels like a gimmick, though.

All right, so the AMAZING FEATURE here is that instead of relying on jumping or wall jumping or double jumping or – heaven forbid! – triple jumping to get around, I’ve got a different sort of mechanic for extreme air movement. There’s an object that you can knock around via the equivalent of punches or kicks, and at the press of a button, you can propel yourself in that object’s direction. So, for example,  to get over a large pit of spikes, you might knock the object (which I’ll call a magnet henceforth) across the pit, and then activate the magnet to pull yourself over the gap too large to jump with your weak legs. If you fail to knock the object far enough on the first try, you could theoretically propel yourself in its direction and knock it around in midair, allowing you to adjust your air movement on the fly. It sounds sort of complicated, but is pretty simple in practice!

Well, anyway, here’s what I’ve got so far! The controls pretty straightforward. Arrow Keys to walk around. Z to jump. X+Arrow Keys to “punch”, knocking the object in any of eight directions. Z while in air to activate the magnet. What I have here is just a little playground to show off the idea. I think it works pretty well if you allow some wiggle room for lack of polish!

HEY WHAT’S UP. BEEN A WHILE, EH?

That whole “can’t think of how to make this fun” thing sort of ruined my motivation for a while. I had made some changes back then that I never actually talked about or posted anywhere, but that’s being resolved AT THIS VERY MOMENT. Well, the changes aren’t huge. The explosion animation is finally done – looks great! – and there are some tweaks in how the ships interact and bounce around. Most notably, the smaller ships bounce off of walls, instead of exploding on contact. I think this does a lot to make things feel more… chain-reactiony, so any theoretical chain won’t end on first contact with an obstacle.

There are still a few obvious interaction issues that I’d like to resolve, but those solutions are sort of inhibited by some characteristics of Box2D. Said issues are still the same as before: kinematic triggers don’t interact as I’d like them to. I want big ships to break on first contact with each other and with small ships. Right now they phase through each other and just kind of bounce off of small ships. This is the best I can do under the circumstances. It’s enough for experimenting, but not what I wanted when I first envisioned this aspect of the greater idea at hand, here. Were I to return to using 3D physics, I could make it work as I desired, but I’d rather not! Fortunately, I spotted a comment on one of the Unity feature requests that implied this may be fixed in a future release. Excellent!

But there’s one other big issue that makes itself painfully evident fairly frequently in my little prototype… Bounciness. Or a lack thereof. If objects approach a wall at too small a velocity, they stick. This is bad! We want full bounciness at all times! There are obviously workarounds for this, but none of them ideal. Apparently, this is again an issue inherent to Box2D; there is a bounciness threshold that can only be modified at build time. The Unity devs seem a bit uncertain as to whether they can gracefully expose the variable to us without repercussions. It’s a fair enough concern, but very annoying. Anyone who wants to make a game with a bouncing object is going to experience this problem inevitably. Even a simple Breakout clone is impossible without hacking around the threshold.

Anyway, I’m not sure if I’ll continue working on this idea or not. I guess we’ll see. I’ve been playing around with another idea, too, recently…

Well, I found a way around my kinematic trigger problem for the time being. Turns out that unlike with the 3D physics engine, the 2D physics engine allows changing the transform of an object directly in the script (without going through the physics engine) and still updates the position, etc. on time to detect collisions. I think I’m just lucky, as that’s not guaranteed, so once this Unity bug is fixed, I’ll be checking all the kinematic and trigger boxes appropriately. But, whatever, it works for now. No complaints here!

So, basically, this build is mostly nothing new, and in some ways not as up-to-date as the previous build. I need to remake the rudimentary main menu from before. But now we have a ball to knock around with explosions! And the resolution has been doubled – or, more accurately, the pixel-size has been halved. Those barrels are so tiny, now…

Nothing much else to say. Hurray for progress! However very minute that progress might be.

Been a while since my last update. Also been a while since I really spent a lot of time with my little project. Number one reason? I’m pretty sure Unity’s 2D physics are a little buggy at the moment. It’s a bit discouraging, because I don’t want to go back to using the 3D physics (in part because it’s more costly for no benefit and in part because it has its own problems, as detailed previously). The bug? Basically, Kinematic Rigidbody Trigger Colliders are not sending the trigger message! What’s that mean? A collider is what the physics engine uses to detect collisions between two objects. If it’s marked as a trigger, it will fire a trigger message onto any object with which it collides. Rigidbodies are how the physics engine knows to treat the object like an actual physical object. It’ll react to other collisions, gravity, etc. If it’s marked as kinematic, it no longer moves according to the physics engine – the game logic must handle all movement. Sometimes things like the player avatar are kinematic until physics should take over – such as when the Mario falls off a platform, for example. Naturally, that all worked perfectly with the 3D physics engine, so I’m fairly certain it’s a bug in Unity. There’s also the collision action matrix at the bottom of this page that very clearly shows that Kinematic Rigidbody Trigger Colliders should send a trigger message. Yeah, yeah, that’s the matrix for 3D colliders, but I can’t find one for 2D colliders. And there’s no reason they shouldn’t act the same! Anyway, it’s a problem. It’s annoying. I should probably just get over it and work on something else in the meantime, like the HUD, the score system, ponder some design, I dunno. But! I really wanted to bring the native 2D version up to parity with the previous RagePixel version before moving on to anything new. It’s annoying! Heh.

I mentioned in my previous post that I was struggling to think of how to make a game about chaining explosions fun, when all the player really does is just click and watch things play out. There’s not enough… interaction. Well, I decided to add a ball that the player can knock around! (I sorta stole this idea from a friend, but whatever, that’s fine, right?) The ball itself doesn’t really serve a purpose, yet. I’m either going to allow the ball to trigger explosions on its own, or I’m going to add some sort of Goal for the ball to reach, or both. I’m also considering turning the game into a Rube-Goldberg Machine solver, like The Incredible Machine (one of my favorite classic PC game series!), only with a focus on explosions.

At any rate, on first attempt, the ball seemed to feel pretty good. I think I’m onto something there. But! – and it’s a pretty big “but” – the ball tunnels right through any walls I set up, once it reaches a high enough velocity. This is a common problem in physics programming when using discrete collision detection. That is, physics advances at a fixed time step, and at each step, we check if any given object is colliding with another object. If the object is moving fast enough and/or the fixed time step is too far apart, an object A could potentially cross from one side of an object B to the other side, without ever actually colliding. I was aware of this going in.

So, I grabbed the handy-dandy drop-down menu in Unity’s Rigidbody component editor and selected continuous collision detection! Except… the problem persists. Continuous collision detection works a bit differently than discrete, in that it determines the collisions before actually moving the objects by using the known position/velocity/etc. of said objects and calculating the first point of contact. Basically, anyway. So, it should work, but doesn’t. Unity (or, I guess, PhysX) also has a continuous dynamic option, which is supposed to work even better, though I’m not as informed on the Why. Except… the problem persists. So, I’m a bit distraught. In a game featuring explosions, I sort of need fast moving objects.

In other news, Unity 4.3 is out! So I’m taking a break from trying to fix the physics, and am instead focusing on updating the project to use the new native 2D stuff. Hopefully Box2D’s continuous collision detection works better than PhysX’s. I guess we’ll see, huh?

(If it’s not obvious, there’s no new version to try out today. I’m hoping to fully integrate the new native 2D stuff tomorrow!)

It is probably pretty obvious why I chose to make a game about chaining explosions as my first game.  It’s simple! I have dozens upon dozens of documented game ideas (not to mention those unfortunately undocumented ideas), but most of them are complicated. Some very complicated. This one that I’ve chosen might, in fact, be the simplest idea I have, and as a bonus, it’s a pretty recent addition to the ol’ Idea Log, which means I’ve still got a decent amount of motivation and inspiration sitting around.

I don’t have to worry too much about physics, beyond basic collision detection. For the time being, the most complicated movement I have planned is a continuous circular movement – something easily scriptable. The art is easy to make, because I chose low-resolution pixel art. (I have enlisted a friend to assist in that regard, but he’s fairly busy himself.) I mean, hell, in just three or four solid days of work, I’ve already got most of the mechanics working as intended. The only thing left is deciding on the timing of explosions (and decay of explosions and splitting of objects and… okay there’s a lot of specifics to work on, still). Beyond that, there’s adding some sound effects, maybe some music, and finishing up the art. Then I can start making levels, seeing what works and doesn’t.

It’s important that everything be as simple as possible, because I’m using this project to learn Unity. There’s still plenty of work, but because it’s so simple, I spend less time worrying about the whats, and more time worrying about the hows. It’s pretty neat!

So, this latest version comes with objects that continue moving even after getting hit by an explosion (!), some new explosion art (unfinished, but functional), a main menu (unfinished, but functional), and a debug controller that spawns any prefab I want it to. Middle-click spawns the object displayed in the top-right corner. Mouse-wheel scrolls through all the available objects. It basically turns the sandbox level into a toy/mini-level-editor. I’m a little curious about trying to make it a real level editor, with which to quickly edit and test things without even having to move stuff around in Unity. Mostly just curious, though.

At any rate, immediate future plans include: getting my friend to hurry up on that art, experimenting more with the timing of explosions, and crafting a few levels. The deeper I get into this, the more worried I am it won’t actually work as a puzzle game – not enough player interaction. It’s just kind of click-and-watch right now. Maybe sound effects, or an actual constructed level will make it all feel better.

Some ideas I’ve had proposed to me and/or am considering to solve this problem are:

• Making it a multiplayer competitive game, sorta like pool (the details are still up in the air as to how THAT would work).
• Giving the player an avatar to walk around and drop bombs (kinda like Bomberman, I suppose, but with more focus on destroying the level than killing enemies).
• Giving the player the ability to drop a limited number of items (or perhaps rewarding the player items for good chaining of explosions).
• Including a rudimentary high score even in the proposed puzzle mode – using things like looping explosions, such as a single ship splitting and creating two chains that meet in the middle to reward extra points.

Beyond that, I’m very strongly considering increasing the map size (or reducing sprite size)! It feels pretty cramped right now.

Eh, we’ll see! We out.

A couple months after getting laid off my first job, where I worked for almost a year, and liked it quite a bit… I’m finally delving into game development in my own free time! So I figure I might as well talk about it somewhere. This first post won’t be much. (In fact, I just wrote it up for my “Current Projects” page, before realizing it made more sense as a blog post.) But future posts may be more meaningful. Maybe.

…

I’ve been messing with Unity of late, after learning that the next big version (4.3) is going to have native 2D support. As a non-artist, while I could technically program a 3D game from start to finish, I’m totally screwed on the art side. I can at least make functional art in 2D. Pixels are easy. At any rate, I decided to jump in now, to become familiar with Unity before 4.3 hits. I’m using an open-source 2D plugin called RagePixel. It’s fairly limited, but it’s serving me well in implementing one of the simpler ideas I’ve been thinking about lately, which is in turn serving me well in familiarizing myself with Unity. And that idea is… Chaining explosions!

Clicking on the screen spawns an explosion. That explosion causes other pieces on the level to either explode or split apart into smaller pieces with different properties. As of right now, it’s fairly basic, but that’s okay!

I’m thinking that this idea maybe works best as a sort of puzzle game, where the goal is to clear a map in as few clicks as possible. The only real problem I can see going down that angle is that I’m no expert in level design, and I can easily see myself making the game too easy or too difficult as a result.

The other path down which I could take this idea is more of an action high-score based game, where objects spawn at semi-random (or maybe even predetermined) intervals/points, and the goal is to chain together as many explosions as possible for higher combos. But don’t wait too long, or they’ll explode on their own, and any chains caused by self-explosions don’t count!

Obviously, it’s still super early, so who knows where it’ll go from here.

Click here to play the current working version! Warning (in case it wasn’t obvious): very early prototype.