|
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 |
|
Posted on 06.14.07 by Mike K @ 11:22 pm
Raigan and I have had an extremely brief dialog on in game ropes. It makes sense, for a while we were both doing rope driven games. Well, due to my failings as a communicator, I sort of just never got back to him. Yet, I absolutely love the topic, and certainly spent much time puzzled by it. Apparently I’ve also made the conscious effort to push my way in to obscurity. My apologies, everybody who’s mailed me. We virtually “ran in to each other” again a few weeks back, in a discussion on 2D game water physics, and so the need to share my thought looms over me again. Now that he’s in blog town, I knew I had no choice, and went ahead with zee said “scooping of theories” out of zee brain, and defaced his blog with it. I hope you don’t mind. The question. How the heck do you pull of physics like that on the SNES!?! As I saw, the discussion is less of a question of how to do a rope, but how do you make a rope work so beautifully on such *nothing* gaming hardware? The following is the slightly edited “shotgun blast to the face” I dumped in his comments. Learn more about the game here. - - - Here we go. My thoughts on how they pulled that off on the SNES, AKA 2-3 MHZ tiled beast. To put things in more perspective, a CPU with 8bit registers, and no internal multiplication or division. However, I think I read somewhere that there was either a hardware multiplier or divider, essentially some hardware address you plug some numbers in to, and several cycles later you can read back a result. This compared to the GBA with it’s 32bit registers, and it’s “so very nice” multiplication opcode. No big deal, it’s only 1 rope. First off, I think the biggest thing they had to their advantage was the tile graphics hardware. All Nintendo hardware except the N64, GameCube, and Wii have tile map 2D graphics hardware. Memory for 8×8 tile graphics, and memory for a map to build from those tiles. So really, you’re either making a tiled game, or your not making a game on those systems. So that means, as far as testing against collision, you’re only testing against easy aligned tiles (surfaces with normals (1,0), (0,1), and the negatives). Our rope, technically only needs to be concerned with things in units of tiles. A 64 pixel tall wall is merely 8 tiles, and only 8 “unit tests” as we interpolate across the line. Also, a locked framerate. So long as we don’t travel more than 8 pixels in 1 frame, we should be able to stay completely stable. Lets also say each tile only finds nearest edges on it’s exposed sides (i.e. no tile adjacent to me, then it’s an exposed side). And an optimization for rope segments, every 2 bends we can put the previous part to sleep. We just need enough memory set aside to support a dozen or so bends. The final big thing is something I ran in to durring my adventures deeper in to physics and maths. Something in math nerd speak called the Manhattan Length or Distance (I forget it’s proper name, I just call it the Manhattan). The Manhattan is a length formula for a line, in much the same way as magnitude (or magnitude squared, how I love thee). The formula is the sum of all the absolute value parts of a vector. I.e. Manhattan = abs(x) + abs(y). No doubt you’ve played with this yourself, and scoffed it off because it’s not an accurate length. That is, except in one key case… When it’s axis aligned! No square root required! (1,0) or (0,1) respectfully, the Manhattan or length is 1, and so would the magnitude. Why is this important? Tile hardware is axis aligned! So as long as we wrap around axis aligned things, our rope segments are accurate. Even if not, so what? Worst case, our rope shrinks a bit going over a slope. You’ve probably noticed how extra bouncy/elastic the rope in Umihara is. My best guess, is it’s because they live with the horrible innacuracies of the Manhattan Length. And truth be told, asuming that’s what it is, it still looks great. Eventually you’ll pendulum your self to a stop whilst hanging vertically. So there you go, Mike’s “how they did Umihara Kawase“. - - - Disclaimer: This is all theory. I’m too lazy to disassemble the ROM. It’s enough for me so that I can sleep at night. Filed under: Stuffing and Technobabble and Opinion and The Spider Comments: 2 Comments |
| « newer posts | previous posts » |
