|
Posted on 03.04.08 by Mike K @ 4:08 am
Ballistic Force wasn’t a long project, but development was dense. Early on, I attempted a poorly conceived idea of creating densely constructed particle landscape. I wanted a system sort of like molecular/planetary attraction to keep scenery together, and allow clumping like a cartoon snowball rolling down a hill. It might have worked on something highly parallel like a GPU or the PS3’s SPE’s, but my design really wasn’t well thought out. The prototype ran at less than 1 FPS, with a map that only covered a fraction of a screen. The attraction didn’t work as expected either. A rather simple castle tower had a hard time staying together, tearing due to numeric instability. Interesting, but no good.  Ballistic Force dense particle landscape, cracking Ballistic Force “take 2″ was the Freedom engine again, but the plan was to carve in to polygon scenery. I was already generating 2D collision from 3D geometry, so in theory it didn’t seem unreasonable. Having just come off the particle landscape stuff, I decided my time was better spent diving in to the mechanics without destructible scenery. To start, that meant building a vehicle. In the early experimentation, I built a tank-car using my equivalent of “Gishes” for tires.  Ballistic Force - Constructing the Tank-car But like other rolling things, it had a hard time sitting on a sloped surface. Not to mention, it wasn’t pretty.  Ballistic Force - Rule #1 of Tank Club is to not talk about Tank-Car. So attempt #2, the blue tank.  Ballistic Force - Constructing the better Tank Better, but it’s obvious I wasn’t too good at texturing. So I continued working on the mechanics. Making the tank aim and fire, adding a chase camera, and some mechanisms for righting yourself when you fall over.  Ballistic Force - Tank firing, muzzle flash  Ballistic Force - Genius shot himself There was a real urgency to get something together sooner than later. This was in May of 2006. Now is not a good time to get in to the details, but it was the first time things got serious. Art was a big concern. I wasn’t happy with my results, and we weren’t really confident enough in our tools to hire an external artist to work with them. 2D modeling, while similar to 3D modeling, is a niche if I’ve ever heard of one. My “bone like” system is tricky to work with as well, even we didn’t have it completely figured out. The other problem is we didn’t have a clear idea of what art we needed. The tank was only moderately playable, and the game concept was rather vague. Future work would easily break any art produced now. We can’t really afford to have an artist come in, hang out, and create assets that’ll just be thrown away. We wanted quick results, but it became clear with so many unknowns, this project wasn’t going to come together quickly. - - - - - Some technical notes on Freedom. Collision geometry in Freedom were either collections of circles/spheres connected by springs (”sphere clusters”), or nodes held together structurally by springs that enclosed a convex polygon collision volume. Verlet/relaxation solver. The polygons didn’t work right, since I hadn’t figured out how the general separating-axis test worked. I was aware of it and it’s power, but how it just hadn’t clicked yet. As a result, all moving objects were “sphere clusters”. Scenery collision was static triangles, axis aligned rectangles, and convex polygons. Eventually we added the ability to import a 3D model, and slice it with a plane to generate 2D collision polygons. There was a loose system kinda like bones. You could weigh vertices of the display mesh to any 2 nodes of the collision mesh. It proved great for making static squish-able things, but our tools weren’t well set up for anything beyond that. - - - - - So when the Ballistic Force debacle calmed down, it was clear we should be making a game with manageable and clear content goals. So PuffBOMB was back on the agenda. With PuffBOMB we had the prototypes, and years of my collected notes and sketches to pull from. However, Freedom wasn’t suitable for PuffBOMB. Not yet. To start, it didn’t support animation. In fact, we were motivated to try alternative projects other than PuffBOMB because Freedom lacked animation. While we were figuring out what else we needed, it sounded like a good idea to support collision animation. That’s not bones, that’s physically interpolated and re-orientable invisible collision geometry. Oh boy! In theory it could have made it possible to create motions and animations like bones would, but it wasn’t going to be as nice an IK system. Not to mention a whole slew of other issues brought on from dynamic collision, but that’s a topic all in itself. I also wanted the ability to build maps by stamping (tiling) 3D geometry in to a scene. This was related to a problem where I didn’t trust my convex polygon generation code. I always suspected my triangulator was fine, but some shapes just didn’t optimize and generate correctly. So this was a double excuse to dig further in to this code and solve it on a smaller scale. There were many more things the engine didn’t do, and things I wanted it to do differently. This was a serious overhaul. The foundation had to be rewritten, and significantly reorganized. It was time for a new engine, and a new name. Filed under: Technobabble and PuffBOMB and The Spider and Ballistic Force Comments: 5 Comments |
|
Posted on 03.04.08 by Mike K @ 3:55 am
This next engines name and story is a little complicated. Game development became a constant burn out for me. Since finishing Secret Agent Barbie (Gameboy Advance) and Polly Pocket (Gameboy Advance), it became clear to me the only thing keeping me going was my fascination with new platforms. Certainly not the subject matter. After we finished Polly Pocket, I asked for a month off to deal with my burn out. However, we quickly picked up a new game, Barbie: Gotta Have Games (Playstation). The game was incredibly late in the Playstation lifetime, but Barbie’s a hard brand to make fail. This was my last chance to do a Playstation 1 game, with the PS2 nearly 3 years old at the time. I had to take it. After that was finally done, I took my month off. I wouldn’t say I was recovered, but I was in heck of a lot better shape than I was before I left. That lead to Brown Box, leaving DICE, joining my friends company to “play” management, and eventually to Destructure. As Atomic Betty was going to be my last project at Big Blue, Destructure was retired as the Atomic Betty engine. Whenever I start an engine project, I always intend on making something reusable. But as usual, I end up with too many things I want to do differently the next time. So a burned out programmer, all of his last 5 notable projects girl games, anxiously anticipating his chance to finally do the games he wants to. What sort of iconic name has he brewed for his engine? He calls it Freedom. Now, I don’t want to give the wrong impression. Big Blue was and still is the best company I’ve worked for, and I’d gladly work with them again. The engine name is about philosophical freedom. I like to joke with friends about my girl game curse. In actuality, I’m just not happy working in the traditional business model of developing licensed games. Of course it’s possible I’ll do a project again to replenish my reserves, but I can still go a while longer. Outside of my early retirement, the Freedom engine was motivated by the console downloadable game revolution. It didn’t exist yet, but we all knew it was coming (fingers crossed). I was officially “retired” in August 2005, and that’s when my focus became Freedom. With the 360 only a few months away, I was going to be ready!! … Oh… that’s right! It seems I’d forgotten about the burn out. Truthfully, I don’t think I was ready for anything until at least a year later. That didn’t stop me from chaotically developing whatever seemed cool at the time. Going back again, Destructure was inspired by the potential of downloadable games of the time. This was mid 2004, where this was Casual games. Back then, I was an Indiegamer regular. I watched and discussed business theory with many who have gone on to become major players in casual games. I’d even gotten myself involved in GameTunnel, to do extra research. At Big Blue, we’d regularly geekishly discuss the casual and mobile games market, as we worked our asses off to recreate the glory days of DICE’s “Team Gameboy”. We came close enough, girl game and all. But with projects like Gastronaut’s Fuzzee Fever on the original XBLA, and The Behemoth’s Alien Hominid, the juices of inspiration and potential were not only flowing, but boiling and bubbling. Where Destructure started with the goal of breaking in to PC casual games, Freedom was nextgen. Freedom was designed to be an HD ready 2D game engine. As a result, one of the earliest purchases I made was one of those lovely 24″ Dell’s. Slightly higher resolution than a 1080p HDTV, and *much* cheaper. As before, the PuffBOMB remake was on the agenda, but structure doesn’t come easy to a burn out.  Early Freedom experiments So the Freedom engine was built, and it became a testbed for physics ideas. Eventually I’d start toying with Gish like squishy blobs, and ropes. This lead to The Spider, a double rope platformer experiment, again, spearheaded by the sound mind of a freshly “retired” burned out coder.  Freedom experiments that evolved in to The Spider I’ve already talked about The Spider a bunch already (with videos) in my previous attempts to get up to date. Check these out if you want to know more. Part 1, Part 2, Part 3, Part 4 During The Spider was also when I recruited my brother to help out. This was near the end of 2005. His main task was editor programming while I built the engine. We’d share the content building duties.  Freedom’s Object Editor  Freedom’s Map Editor He’d previously worked on some contract mobile games, as well as helping out on my earlier efforts. Of note, he did most of the map and world building on Murmur’s Dungeon (the 6-1997 game above), and helped a bunch with the character design on Islandgates (the 10-1997 game, lots of content we never got around to using). As expected, bringing on somebody new (especially someone as familiar and opinionated as a sibling) encouraged a bit of an identity crisis for The Spider project. Despite, as I’ve suggested before, the game wasn’t well developed either. Adding him probably helped more than hurt. During development of The Spider, it became clear that the goals of the project weren’t clear. More ambitious than anything. With tools, a working engine in hand, and some outside “encouragement”, we started discussing games of smaller scope we could pull off. The Spider was followed by the destructible scenery project, Ballistic Force. Filed under: Technobabble and PuffBOMB and The Spider Comments: None |
|
Posted on 03.01.08 by Mike K @ 4:51 pm
Over the years, I’ve given names to game engines I’ve worked on. Most of my professional experience has been working on platformers and mini-game collections. Mini-games rarely share much in common, so by engines I’m referring to platformers, or engines for games very much like platformers. I’d like to start talking about what I’ve been thinking about whilst designing my next engine. I need to set some context though, so I’ll be walking through some of more significant engines I’ve worked on. Going way back, I really didn’t start naming my engines until after Secret Agent Barbie (Gameboy Advance). I did name my GCC driven Gameboy Advance tool-chain “ATK” for Advance Toolkit, but my priorities eventually changed. As a team we used the interal code name of “Bond“, but I’m sure that was just us wishing we were doing a James Bond game instead. “Bond“, like each of my platformer engines before it, was a “Megaman Physics” engine. Megaman Physics are what I call platformers that solve moving characters against static scenery, but do something artificial to solve object vs. object collisions. Pretty much every 2D Megaman games sets you to an injured state and gives you a brief constant velocity opposite your facing direction, followed by temporary invincibility. That meant you could walk right through the enemies after that brief interruption. In retrospect, I’ve started to think Megaman Physics might be superior for playability, but that’s a topic in itself. Before I left DICE, I was working on a project with a coworker that we referred to as “Brown Box“. The name was a play on the idea of a black box, with a cynical inside joke a handful of us had. The essense of the joke was, if you came in one day and found a brown cardboard box on your desk, you were fired. Pleasant. Brown Box was a 3D R&D project. On my own time, I was working on some 2D physics experiments. My early efforts became the Zooble prototype (with it’s very wrong physics), a verlet testbed Phiz, and a series of further physics experiments adopting such strange names as Popcorn, Cactus, and Canadianese Simulator.  Phiz, where my verlet fascination began  Canadianese Simulator… isn’t it obvious… they’re red. Destructure was conceived as my “Post DICE” engine effort. The name was chosen ’cause it sounded cool. I left in June 2004, just over a year after making the original PuffBOMB prototype. I left with the intention of building an engine for the PuffBOMB remake (and other projects), and eventually to help out a friend at his new company. I left as quickly as was appropriate, hoping to get a couple months of work on Destructure in. Alas, all I had time for was a couple weeks of R&R, and to start a compo game before I was called upon. Destructure eventually became the engine for Atomic Betty (Gameboy Advance). I was well versed in classic and verlet physics at this point, and was using that experience to build a low spec cross platform game/physics engine. Beefy goals as usual. We landed the Atomic Betty project, so I re-purposed my design to suit the game. A fun aspect of Destructure is it, for a while at least, it compiled both on the PC (with Allegro) and for the Gameboy Advance. As the project kicked off, the GBA specific code grew so fast, it wasn’t practical (or necessary) to concurrently develop.  Early PC version of Destructure. Red boxes are the overlap. Some technical notes. Objects in Destructure used circles and axis aligned rectangles for collision, though Atomic Betty only used the rectangles. Objects were moved and solved with a bare bones verlet/relaxation solver. The rectangles were actually the 2 corner points, with a pair of verlet spring constraints (width and height) keeping it from collapsing in on itself. No square roots required The next engine’s name and story is a little complicated, so we’ll save that for next time. Filed under: Technobabble and PuffBOMB and Zooble Comments: 2 Comments |
|
Posted on 01.01.08 by Mike K @ 9:30 am
Start the year right ‘eh? I think each year I’ve had a blog, I’ve told myself “Yes sir! This year we’re going to blog more often… and it’s going to be great!”. I’m not crazy enough to think that’s going to happen, but there’s always the intent. - - - - Some fun code I toyed with over the past couple weeks, completely unrelated to each other. The VST SDK (audio instrument/effects) and the WinTab SDK (tablets). I know I’m an oddball programmer, as I prefer MinGW (GCC) to Visual Studio. That’s totally asking for headaches when it comes to non open source stuff, but I don’t care. As expected, neither of these SDK’s ship with a MinGW or Cygwin friendly build option (though VST SDK is portable). As far as the effort in getting them working, I gotta say, thumbs up to Steinberg, thumbs down to Wacom. VST wise, I got started on a VST port of sfxr. I have the sound engine working both as a sound effect generator, and a key’d instrument, but the real meat of sfxr is in the GUI. So if I manage to discover another day of VST inspiration by April, we could have some Instrument + Sound Effect integration for LD11. Tablet wise, I really just wanted to know exactly what was involved in adding tablet support to an app. Apparently Windows API coding, and lots of obscure searching. - - - - Ludum Dare #10 results went live Sunday night. 52 submissions. They can be found here, and the entries can be found here. Phil Hassey, you rock for hosting it. Ludum Dare #11 is scheduled for April this year. The exact weekend, we’ll figure out some time before then. If you want to chime in on weekend suggestions, leave us a comment. There’s mutterings of a 10.5 between then and now. If you’re interested, get on the mailing list, and we’ll let you know if it happens. Filed under: Stuffing and Technobabble and Ludumdare and VST Comments: 5 Comments |
|
Posted on 06.15.07 by Mike K @ 10:45 pm
Last post talked about the random thoughts I’ve had about how to pull off the rope dynamics in Umihara Kawase, this classic SNES game that drives us all mad. I made some bold suggestions, and decided to try them. After a couple hours of work, while not as complete as I want, it’s far enough along to be able to demonstrate to me if I have a right idea or not. Rather than let this fun experiment disappear in to obscurity through e-mail or forums, and since I never have enough blog content, I’ll post it here and try to explain more broadly what’s going on in my test. Though really, this is just Raigan and I talking back and forth.
ESC - Exit The point of this application is to simulate a stiff wrapping Umihara Kawase rope, not a nice bouncy spring built one. Actually at this point, it doesn’t attempt to wrap around scenery. The rope is capable of it, but I’m just manually hard coding a list of points in between the end points. I’m assuming there’s will be a system that looks at the collision, notes the edges I cross, and correctly pushes them on to the front or back of an STL deque. So … uh … for now, pretend they’re pulleys, or fitting through some really fine cracks. What you’re seeing on screen is 4 separate rope simulations. I’ve noted on the image in a 2×2 grid what is what. “Magnitude” means I use Magnitude (length = sqrt(x*x+y*y)) for all my length calculations, and “Manhattan” means I use Manhattan (length = abs(x)+abs(y)) for them. The “Free” row means both points move freely, and “locked” means one doesn’t. If you’re just tuning in, Manhattan is correct when axis aligned (i.e. [10,0], [0,-4], etc), but increasingly more wrong (too long) as it approaches a 45 degree angle. It doesn’t break, it’s just different, very diamond shaped instead of circular. Think of it as a worst case square root approximation for vectors that still works. To solve the rope, I need a few things. The sum of the length all rope segments, which is one place where I’m using a Magnitude/Manhattan, one for every segment. I take the difference between my set length and my calculated length to see how “broken” it is, much like a spring. I then pull or contract my end points to fix it. It’s a cheap verlet solver, so all I need to do is move the point and it will work out beautifully in a few frames. So I take the vector from end to point for each side, divide it by the length of that segment (My other Magnitude/Manhattan use, one per side), which gives me a normalized vector I can use to apply part of the rope length difference. And I subtract this from each side. So yeah, unfortunately, I did have to use two divides, one for each side. If your target never moves, you *could* get away with 1 divide (but what’s the fun in that?). But yeah this is a quick demonstration to see how each method works. Each test case is given the exact same data. So, my thoughts (UmiRope_Riggid.exe). Because the error in the Manhattan versus Magnitude, the rope is shorter. The rope being shorter to me isn’t that big of a deal, and this is why I initially didn’t see Manhattan being a problem. It’s a really cheap way to calculate an approximate total length of the rope, if it has many segments. However, Manhattan has it’s real notable flaw in calculating the new positions of the ends. In my opinion, it’s not terrible, it’s just not very natural looking. A cheaper than a “real” square root approximation would still be ideal here. Is this Umi-like though? Not quite yet. The Umihara Kawase rope is somehow very elastic, erratic, bouncy, where this is very rigid. Alright, more bouncy then. I included a variant that’s more bouncy, by using a 20% of the solve amount (UmiRope_Bouncy.exe). While reacting differently, I don’t think it’s an improvement. After it calms itself down, it looks more or less the same an the rigid example. Hmm… I am going to have to take a look at the game again. It might be possible to introduce another error that makes the Manhattan look more sproingy. But generally speaking, this approach to solving the rope is cheap. The only bottlenecks being a division per end, two multiplications per end to scale the vector in the normalization step, and two more to scale the normalized vector up by each side’s part of the difference, and everything else can boil down to adds, subtracts, and shifts. And if division is a problem, it can be replaced by indexing in to a table of reciprocals (1/1, 1/2, 1/3, 1/4, …), and multiplying by this reciprocal in the place of the division. So 5 multiplications plus a bunch of adds/subtracts/shifts, per side. At least, to solve the rope. Everything else I think is just some good “hopefully simple” logic to figure out what points to add to your list (deque). I’ll toy with that later. - - - Source is included. The notable functions are, all in main.cpp: cParticle::Step() - which is how we move each end of the rope. The multiply there is a friction hack, removing it makes coming to rest take more time. cManhattanRope::CalcRopeLength() and cManhattanRope::StepRope() are the variants needed to use Manhattan instead of Magnitude (i.e. Normalize). You can see the divide here, which is normally hidden in the normalize function. Steps are called in main, lower in the file. Filed under: Stuffing and Technobabble and The Spider Comments: 1 Comment |
| previous posts » |
