WITH HIS HANDS COVERED IN BUTTEROriginally Posted by adaml
Is there going to be an ending? Don't want any spoilers, but was wondering if the ending was going to be like a 1985 type ending or an early 90s ending
OUR HERO WONDERS
WILL HE FIGHT AGAIN
YOU ARE WINNERER
THANKS FOR PLAYING
I have been thinking about this game and thread, I am glad someone bumped it up. Lets get a little bit of an update....please!
Yet another youtube channel:
https://www.youtube.com/channel/UCkT...tyNJnjPw-2co7g
I'm really excited about this game, give an update mang!
Progace has pretty much been AWOL for the past month and a half. He hasn't been in #vbender in 48 days! I don't think anyone knows where he is.
<Evan_G> i keep my games in an inaccessable crate where i can't play them
I think it's "wiener" for the proper transliteration of the announcer girl voice (Galaxy Fight maybe?)
Anyway, I fear that Proggy has eaten the big buttery stick in the sky.
He's been seen on XBL. He better get his ass back here. I paid him for something 2 months ago and he hasn't sent it.
Those who look into the buttery abyss sometimes have it look back at them. What's left of his dribbling consciousness is sandwiched somewhere on the 6502 stack, and there may not be enough bio-flatuence this time to pop him back where he belongs.
We can pray.
Hopefully, he'll pop on here in the next day or so. I'd hate to think that the butter was a lie... There will be butter, I'm confident in it.
That ProgscammingAce is such an acehole...
Alright! So today's a lesson on physics. Short version: physics in video games suck.
Ok, so they don't so much suck, but they definitely aren't realistic. The rather obvious explanation for this is because realistic physics aren't fun. Let's say we wanted to give Bio Force Ape realistic jumping physics. Even assuming Mr. Ape is twice as strong as a normal human, he could probably only jump up to half of his own body height. In the game, that would work out to about 16 pixels. That's not even enough to let him jump over the little yellow squid thing.
So we bring in game physics and make the ape jump around like a bouncy ball on crack. There is a right way, and several wrong ways to do this. Let's start with the fail.
The simplest way to have something jump is to subtract a value from the player's height (or x value in this case) for so many frames, then add it back in for the same number of frames. So for example, you subtract 5 pixels per frame for 10 frames, then add 5 pixels per frame for 10 frames. This looks like crap. The player goes straight up and back down at a 45 degree angle, there's no arc, acceleration, or any kind of real physics, but it's really easy to cod. I can't even really think of a game offhand that used this kind of jumping.
The second kind of jumping physics is also the wrong way of doing it, but it's what you see in the Bio Force Ape demo we released last year. The way this works is using somehing called a lookup table, which is just a fancy way of saying an array of numbers. The lookup table uses pre-calculated values based on actual acceleration to deturmine the number of pixels the player should move per frame. So what you'd see is a blob of data that looks like this: 4, 3, 4, 3, 3, 2, 2, 2, 1, 2, 1, 1, 0.
What you'd do is start at the beginning and subtract 4 pixels from the player's height, then 3, then 4, etc... until you get to 0, then add it back on in reverse order. Depending on how you set the numbers, this can give a pretty decent approximation of acceleration.
Unfortunately, i must have been drunk when i wrote the code for the demo, because it sucks. The lookup table for jumping is 32 numbers long, the player starts on number 26, subtracts to 30, adds back up to 22, then ends back at 27. I don't have a clue why either... The end result is that the jumping looks ok until you get to the top of the jump, then things get all shaky and you fall back down. It looks "alright" in the demo, but I since i can't figure out why I did it that way, i couldn't fix it and I just rewrote the jumping code the right way.
Which brings us to the *correct* way to implement jumping. This is about as easy to implement as the lookup table, but performs better. You take the player's height (x location) and subtract a certain number of pixels (let's say 10). Then in the next frame you subtract 9, then 8, then 7, then 6... etc. Then when the number hits 0, you just add them back on until you get back to 10. This doesn't tie exactly to actual physics, you'd really want to change the value by a multiple of about 1.33 per frame, but it's close enough for government work. For something like Bio Force Ape, the jumping physics don't really need to be all that precise. Now when I actually implemented this jumping routine, the ape was jumping and falling way too fast. It only took 21 frames to run through the entire animation, far less then a second. So in practice, i only changed the player's height every other frame. This worked out much better.
In the next episode i'll either talk about collision detection, or disappear for 6 months again... i haven't decided.
I should clarify when it comes to lookup tables, they're not all bad. Lookup tables are a great tool to use if you're going to do time intensive calculations, like multiplication. The NES's processor doesn't do multiplication, so if you want to multiply numbers, you have to add them together a bunch of times. Instead of wasting the CPU cycles, if you have a good idea of what numbers you're going to multiply, you can store them in a lookup table. Like if you want the multiples of 3, you can store them in a table with 3, 6, 9, 12, 15, 18... etc. So if your game needs to know what 3 times 9 is, it can just grab the 9th value in the lookup table.
When it comes to acceleration, the method i posted above really is close enough to real world physics that a lookup table doesn't make sense.
I'm going to try to combine a few things here...
The final piece of the Competition Cart came in last night, the music designed by our own DJBeatMongrel. I'm hoping to have a sample available this weekend. Without being a direct ripoff, it has a very cheetahmen II vibe. I just set it as my ringtone this morning.
Just to go over some of the details we've already posted, the competition cart will be available for ordering on April 1st. We're not doing a pre-order, that *is* the release date. Copies will be available at the Midwestern Gaming Classic a few days earlier for those attending the show.
Once the cart is released at the MGC, we'll have some screenshots and other media available before the internet sale starts up.
We have not settled on a final price, we're waiting for production to start up to see what the costs are going to end up being. We should have that information early next week.
We've locked down the details of the Bio Force Ape competition. You can come by and play at the Robot Panic booth (the guys who have the giant robot). The competition will be open from 10:00 AM to 6:00 PM. The winner will be announced at 6:00. Come by and sign up to play.
Price announced, $35 if you buy it at the show. Online orders will be $35 + shipping.
I can't believe it's not butter, but yet, IT IS!
This signature is dedicated to all those
cyberpunks who fight against injustice
and corruption every day of their lives
Ok, there seems to be some confusion as to what this competition cart really is:
Originally posted by: casperdj777
"show will include an extended demo of the full game". Im a little confused by this,so the carts coming out later july will be the same bio ape game but with less stuff right?or the game will have more levels but not the exstra demo game/other stuff?if the one in july has less stuff why would we want to wait untill then to snag the game.
The competition cart that's being released on Saturday only has part of the full game included, it's basically a demo. The comp cart has the first 2 levels of the game and one of the later boss fights (one out of the 5 bosses included in the final game). You also get a sample of what the mine cart level in the game is going to look like. The survival mode is based on, but not a copy of, the mine cart level in the final game.
The survival mode and the Volleyfish mini-game will not be included in the final game to be released in July. Volleyfish started as a prototype for what I'd like to do in our next game. If we do decide to expand on the idea, the game will be written from scratch and this volleyfish demo would never have been released. So instead of just throwing away the code, i thought it might be interesting enough to include it in the competition cart.
The survival mode was something I always had in the back of my mind as a bonus for the final game, but the logic for that mode turned out to be too different for me to shoehorn it in. I don't have the rom space to include a complete separate game mode in the final game, so it had to get cut early on, before any work was started on it. The Midwest Gaming Classic gave me an opportunity to code it up and test it out.
I tried to do a few interesting things with the demo that I wasn't able to do with the full game as well. The comp cart is the only place you'll see an animated cut scene, for instance. The comp cart has 10 different quotes from across the gaming universe that it'll spout out depending on your score in the survival mode.
Think of the competition cart as a "Disc 2" to a directors cut in a DVD release. If I had unlimited time, money, and rom space, these are some of the things i'd like to have included.
The competition cart is priced lower then what we expect a full CIB boxed release of the final game will go for. It is not a complete game, it is a special purpose cart that was created to run a competition. We added in some extra goodies in case people are interested in purchasing a copy for themselves.
Now that the competition cart is out, back to the developer's journal.
I'm going to start posting them on CinematicBazaar.com and cross linking them because it's just too much of a pain to try to reformat the articles across multiple forums.
So here's a lesson on data compression: http://cinematicbazaar.com/?p=80
Good read as usual. I was considereing using a similar RLE encoding technique in the gameboy game I'm (slowly) working on. I should probally go back and add it since after reading your post, it looks like it would cut down on a lot of level data.
"Game programmers are generally lazy individuals. That's right. It's true. Don't let anyone tell you otherwise. Since the dawn of computer games, game programmers have looked for shortcuts to coolness." Kurt Arnlund - Game programmer for Activision, Accolade...
It cuts down on a ton of data, and it's really simple to implement. If you have your data in an array, you look for the flag, read one byte ahead for the tile number, then read another byte ahead for the loop number. Then just write the tile and decrement the loop counter until you hit zero.
Posting Permissions
Reply With Quote
