Archive for June, 2007

AO got you down? Bring down Unrated.

Thursday, June 21st, 2007

The AO games rating seem to be the hot topic as of late, thanks to Rockstar’s Manhunt 2 initially netting the rating. The AO rating is terrible for game, because it excludes you from key retail outlets like Walmart.

But I want to bring your attention to something that’s generally being overlooked by these articles. Films in the same genre as the Manhunt game. Hostel and Saw. Torture films basically. Hey look! They’re sold at Walmart. What the hell’s going on?

“Unrated”

Hey! Hold on! They cheated!

Gamers know that the “R” rating is the game equivalent of the “M” rating. So sure, we need to educate parents and politicians. But movie producers sneak in some “bad ass” cred by flagging it “Unrated”, i.e. too “bad ass” for the censors.

So here’s my question. How the heck do they get away with that?

The film industry is much much older than the games industry, and thusly they get away with such legislation as the DMCA. Games can’t get away with the Unrated BS having grown up in a world of established censorship, short of the PC via the internet. Follow each storytelling media through the years, the age dictates the censorship. Books have very little, film some, games significant. Yet, they’re all media. So here’s my pain in the ass proposal.

Call Warmart on their bluff. By not accepting AO games, they’re playing hypocrite by accepting “Unrated” movies. Sit the people down in the product approval department with a controller in one hand, and said DVD playing on a side monitor to compare. The movie will look more real, and gruesome. Nice job with the “family friendly” image hypocrite-mart.

Thusly, this should get the MPAA involved. If anyone has the influence to “solve business problems”, it’s them. If the resolution is both don’t get allowed in Walmart, that’s fine. By taking the “extreme” content out, it’ll have to find it’s home in specialty shops Blockbuster, EB, Amazon, and whatnot. They’re business does potentially better because of less content restriction mindset.

Our industry doesn’t have as much to lose by this, it’s really just Rockstar and their 2 titles (GTA:SA, MH2). Film has a lot to lose. So if there’s anyone that can affect change, it’s them. It’s Media’s issue, despite it being currently gaming’s problem.

‘cmon, all or nothing.

Oh hey look, it’s IGF time

Saturday, June 16th, 2007

Wow, and yikes. Time flies. IGF Submission time again. October 1st ‘eh? I should probably enter. *shrug*

Here’s something interesting.

The 2008 IGF Main Competition will again be open to all independent developers to submit their games – whether it be on PC, console digital download, Web browser, or other more exotic formats.

Cool, but doesn’t that have to mean your game is already available/to be available by October? Or are the big 3 giving kits to judges now? *shrug*

The 10th IGF too. Wow. My game isn’t that cool. *shrug*

Thanks for the heads up Tim and his mighty Blog.

Exploring the “Umi-Rope”

Friday, June 15th, 2007

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. :)

Ugly App

Download it here

ESC – Exit
TAB – Reset
SPACE – Pause

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.
cRope::CalcRopeLength() – which based on it’s contents, steps through every notable point to calculate the sum of all line segments.
cRope::StepRope() – which solves the rope. The first multiply on each line is the important one, which is a vector by a scalar. The 2nd or 3rd on those lines were just to make it more flexible. They could be replaced by a shift.

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.

The secrets of the “Umihara Kawase” rope

Thursday, June 14th, 2007

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.

The “Indie Office”, Part 1

Wednesday, June 13th, 2007

Hypothetical situation.

Note: Try to refrain from bombard me with requests yet, ’cause I know a lot of people already like this idea.

*cough*, I’m in London, Ontario, Canada. ;)

A typical game company places 10 or more people under the same roof. Office space rented out at the expense of the company. There’s a management hierarchy, one or more people responsible for business and infrastructure aspects of the company, and an arrangement of programmers, artists, designers, possibly testers and a sound guy. Not a bad way to run a game company. In fact, a very good way that has worked for a very long time, and still does.

A typical indie or casual developer is a team of 2 or more people. The work is either handled entirely by the pairing/group, or some of it is contracted out. Even though it’s a team, that doesn’t mean they work under the same roof. Thanks to the internetz, you can work with anyone anywhere.

If the Indie developer is successful, it’s not uncommon to see it evolve towards the typical game company structure. Programmer/Biz guy moves up to Biz guy only, Lead programmer becomes Technical Director, new recruits are hired, and so on. They also move out of their respected basements and home offices, in to office space.

This is how things typically work.

Now, lets say you don’t want to grow your company, or you haven’t been successful enough to afford to. Or maybe you just have really hard time justifying office space for 2 guys. And even though you’re doing awesome work, things like the Wii Developer Qualifications loom over your head.

What to do?

Option #1, get some smaller developers together and start a new company together.

So great! Lets start a company! Wait, what about my individuality? I don’t want to have to deal with more ownership rights! Or wait, how do I know I can trust partnering with you? Issues for sure, but lets look at it a different way.

Option #2, share some office space. Lets follow this idea.

Office space is acquired, and cut up. 2×4 reasonably large areas for a desk and side table, and everyone shares the conference room and kitchen. Your people include two teams of 2, a team of 3, and an individual. The rent and other facility costs (fax line, water cooler) are added up, and generally speaking that total is split 8 way to reflect the 8 spots available (or 7 ways if one’s left unused). Each of the two teams of 2 pays 25%, the 3 pay 37.5%, and the individual pays 12.5%. Easy.

But this brings up a number of questions.

Who owns the office?

What sort of business is this then?

Should a new business be formed to encapsulate the smaller developers?

If that’s the case, we’re back to Option #1. However, we might not want a straight up partnership. We don’t necessarily want stakes in each other’s games, or any outside financial pressures for that matter. Still, who owns the company? That’s up to the group.

Another perspective, the “plug and play” office. In other words, capable of adding, removing, or expanding to support more teams. This idea of the Indie Office is a serious business venture, where everyone involved must be able to cover the basic expenses.

What if somebody leaves?

He runs out of money, gives up on the idea, or the group “votes him out”. The remaining people in the group need to be prepared to make up the rent difference, or to seek a replacement. The nature of this arrangement is potentially “plug and play-able”, since you can’t be sure about everyone a year from now.

If “plug and play” is encouraged, then the business can also reflect a “College Alternative”.

Most of us know smart kids. Developed games on the own, lots of potential. Why waste their time in a school? So long as the group is for it, a student can come in, be generally self sufficient doing and learning what they can, working on their projects, with the resources of the group available to them. Self sufficient being the important part, but most “experts” are happy to share and give advice. They or their parents pay their cut of the rent for as long as they’re around.

Alternatively, an internship. We bring in the student, and whatever teams want to share him, they cover his costs.

Or along the same lines, a tester or a general “go-to” extra shared by the group. He keeps his hours, and we split the costs in some respectable way.

This is the concept of the “Indie Office”.

– –

Is any of this even meaningful?

Game development, like any part of the media industry, is a creative business. Creativity comes from a number of places, one of the most basic being conversation. The model of the Indie or Casual game developer promotes low budget small team development. Unlike film, a video game can be developed by very few people, even an individual. Going from hobby to full time, or retail to indie creates an unfortunate isolation. Not the most ideal or creative situation to be in.

The “Indie Office” is a concept to bring together the freedom of being able to choose and do your own projects, and combining it with the potential found by bringing creative people together. It’s applicable to creative industries involving individuals or small teams.

– –

Do comment and/or cross blog post if you have thoughts on this.

In subsequent posts, I’ll try to go in to further detail on needs, location, office size, arrangements, etc.

Today’s Threat

Monday, June 11th, 2007

Oh boy!

Nothing significant, I just forgot how amusing some of this stuff can be. Taken from 1950’s PSA called “Duck and Cover“, via Archive.org.

Then I started playing with clips from the PSA.

Have a good day.