Kain

Looks like one of them old timey maps.

From what I've heard of the industry, unless he's trying to get a complex programming job, then this is extremely good resume material. And if it's popular enough, he could just get bought by a company who wants to use the series, hiring him at a nice head position. Probably doesn't happen all too often, but great game is great game whether it's made in C++, MMF2, or brainfuck.

Also: Certainly no surprises that MMF(2) is capable of making a game like this.

Oh. I played the demo like a week ago and had no idea it was so close to release. Awesome game. Never played the first, it looked a bit rough around the edges, but this one seems well worth paying for.

The collision events may be centralized around a character and his variables. Just use collision_point, since the AI probably won't have to worry about layers. This is the code I use: { // Slope up repeat(10) { if( !instance_place_mask(x, y+15, oWall, m3x3)) break; y-=1; } // Slope Down for( i = 0; i < 10; i+= 1) { if( instance_place_mask(x, y+16, oWall, m3x3)) { i = 0; break; } y+=1; } } (I use a for loop for the second one because I want it to turn around if it hits an edge [that would be when i = 10 coming out of the loop], whereas turning around when hitting a wall is handled by checking left/right collisions) instance_place_mask is just a simple script to test collisions with a certain mask without permanently changing it, but you could just use collision_point or collision_circle if you prefer: /* instance_place_mask( x, y, object, mask); * * Returns the id of an instance of the given object that is collided * using the given mask * * Returns -4 = noone if there are none. */ { var tmask, cid; tmask = mask_index; mask_index = argument3; cid = instance_place( argument0, argument1, argument2); mask_index = tmask; return cid; } And of course, replace oWall with whatever the main wall parent is in your engine.

I'm getting a really strange error and I can't figure out why. After executing half a dozen mid-air backflips, doing one of them fancy twisty-turny moves, all while freezing the water so I could make a perfect dismount, too. It works 100% 50% of the time, and 50% the other 50% of the time. It has something to do with the order that the objects were created and which one is ramming into which. I'll work on it more tomorrow. (controls are the same, only instead of clicking and draging the mouse, you just click and then move the mouse out of the object) bounce2.mfa

Question: in MMF you have a collision event between two of the same active objects. How do you use the alterable variable of one of the active objects to determine the alterable variable of the other? Is there an easy way or am I gonna have to find a work-around? That's the only thing I need, then it'll be done.

I finally got around to programming this in GM and oh god, I can't believe I failed so hard at simple conversions. That's what I get for taking a break from fangaming. Anyway, before I try and convert this to MMF (by first downloading MMF), is this the kind of collisions you're looking for? http://kainsirusque.googlepages.com/bounce.exe Click on an object, drag the mouse, then let go to catapult the objects into each other.

Somethin' ain't quite right here. Do I need to add both of the cases together to get the answer? I guess I'm gonna have to try the code out myself. Anyway, you can just use 1 instead of mass and that'll probably simplify the equations a tiny bit. Anyway, what are the shape of the objects and give me a visual example of how they might run into each other. If they're moving on the same line, then the collisions are simple. If they aren't, you need to do all that conversion stuff. Edit: yea, that's what I was doing wrong. Basically if they're both the same speed, then all you're gonna do is swap their par_speed: angle_of_collision( whatever) = however you figure it out t_speed( object1) = sqrt( x_speed(object1) power 2 + y_speed( object1) power 2) t_speed( object2) = sqrt( x_speed(object2) power 2 + y_speed( object2) power 2) // Figure out the perpendicular and parallel components par_speed( object1) = cos( angle_of_collision( whatever)) * t_speed( object1) perp_speed( object1) = cos( angle_of_collision( whatever) + 90) * t_speed( object1) par_speed( object2) = cos( angle_of_collision( whatever)) * t_speed( object2) perp_speed( object2) = cos( angle_of_collision( whatever) + 90) * speed( object2) x_speed( object1) = cos( - angle_of_collision( whatever)) * par_speed( object2) + cos( -angle_of_collision( whatever - 90)) * perp_speed( object1) y_speed( object1) = -sin( - angle_of_collision( whatever)) * par_speed( object2) - sin( -angle_of_collision( whatever - 90)) * perp_speed( object1) x_speed( object2) = cos( - angle_of_collision( whatever)) * par_speed( object1) + cos( -angle_of_collision( whatever - 90)) * perp_speed( object2) y_speed( object2) = -sin( - angle_of_collision( whatever)) * par_speed( object1) - sin( -angle_of_collision( whatever - 90)) * perp_speed( object2)

EDIT: Big warning, a lot of what I say is wrong, but there's some rightness somewhere in here. http://hyperphysics.phy-astr.gsu.edu/Hbase/colsta.html The formula is pretty simple for 1-dimensional or head-on collisions. You just need to assign a mass to every object, and then use the formulas in that link, namely: new_speed (object1) = (mass( object1) - mass( object2)) / (mass( object1) + mass( object2)) * old_speed( object1) new_speed (object2) = 2*mass( object1) / (mass( object1) + mass( object2)) * old_speed( object1) If you want more dynamic pool-ball collisions in 2D. First you find the angle between the two centers. I forget exactly how you do that in MMF2. I'm pretty sure MMF needed an advanced math object, but I'm not sure with MMF2, but you should be able to figure it out by looking in the slope detection of any Sonic engine. Anyway, once you do that, you convert each speed vector of those two objects a vector with a component perpendicular to the angle of collision, and one parallel to the angle of collision. The perpendicular components will not be changed, but the parallel components will follow the formula above. angle_of_collision( whatever) = however you figure it out t_speed( object1) = sqrt( x_speed(object1) power 2 + y_speed( object1) power 2) t_speed( object2) = sqrt( x_speed(object2) power 2 + y_speed( object2) power 2) // Figure out the perpendicular and parallel components par_speed( object1) = cos( angle_of_collision( whatever)) * t_speed( object1) perp_speed( object1) = cos( angle_of_collision( whatever) + 90) * t_speed( object1) par_speed( object2) = cos( angle_of_collision( whatever)) * t_speed( object2) perp_speed( object2) = cos( angle_of_collision( whatever) + 90) * speed( object2) // Start some fastloop once In the fastloop, have too different actions based on these conditions: 1) If abs( par_speed1) >= abs( par_speed2) // Apply conservation of elastic collision formula to the parallel components t_speed (object1) = (mass( object1) - mass( object2)) / (mass( object1) + mass( object2)) * par_speed( object1) t_speed (object2) = 2*mass( object1) / (mass( object1) + mass( object2)) * par_speed( object1) // combine the new par speed and perp speeds to get normal x/y components x_speed( object1) = cos( - angle_of_collision( whatever)) * t_speed( object1) + cos( -angle_of_collision( whatever - 90)) * perp_speed( object1) y_speed( object1) = -sin( - angle_of_collision( whatever)) * t_speed( object1) - sin( -angle_of_collision( whatever - 90)) * perp_speed( object1) x_speed( object2) = cos( - angle_of_collision( whatever)) * t_speed( object2) + cos( -angle_of_collision( whatever - 90)) * perp_speed( object2) y_speed( object2) = -sin( - angle_of_collision( whatever)) * t_speed( object2) - sin( -angle_of_collision( whatever - 90)) * perp_speed( object2) 2) if abs( par_speed1) < abs( par_speed2): // Apply conservation of elastic collision formula to the parallel components t_speed (object1) = (mass( object1) - mass( object2)) / (mass( object1) + mass( object2)) * par_speed( object2) t_speed (object2) = 2*mass( object1) / (mass( object1) + mass( object2)) * par_speed( object2) // combine the new par speed and perp speeds to get normal x/y components x_speed( object1) = cos( - angle_of_collision( whatever)) * t_speed( object1) + cos( -angle_of_collision( whatever - 90)) * perp_speed( object1) y_speed( object1) = -sin( - angle_of_collision( whatever)) * t_speed( object1) - sin( -angle_of_collision( whatever - 90)) * perp_speed( object1) x_speed( object2) = cos( - angle_of_collision( whatever)) * t_speed( object2) + cos( -angle_of_collision( whatever - 90)) * perp_speed( object2) y_speed( object2) = -sin( - angle_of_collision( whatever)) * t_speed( object2) - sin( -angle_of_collision( whatever - 90)) * perp_speed( object2) I've probably made at least a dozen math errors or MMF syntax errors in the formulas of projecting one angle onto another and then projecting it back, though. I'll have to test it out and fix it later. Obviously x_speed and y_speed are the only variables that matter (also mass). The rest are just temporary variables. Edit: Forgot to mention the absolute value of the speed of object1 should be bigger than the speed of object2. It's hard to generalize it with MMF, so you'll probably need two different actions. Which means you have to calculate par_speed and then based on which one's faster, perform the correct code. I edited my code, but it may have some unneeded redundancy since I'm not sure how the flow of MMF works.

Not exclusive or, I hope.

What a sly way to get 1 million signatures worth of attention.

That applies to Metroid Prime 3? (Nintendo and wiki calls it a first person adventure game, but that's really not a great distinction, so I won't argue that it's not an FPS). As a fellow hater of FPSes, the Metroid Prime series really is quite different with its auto-aiming and exploration. Of course, MP3 is a pretty good bit more FPSy than the previous two, so if you've already tried them and thought they were too FPSy, then you probably won't like MP3.

Games I own for Wii: Twilight Princess: Recommended. It's LoZ. Enough said. The day Nintendo screws up LoZ is the day SEGA gets Sonic right. (don't kill me) Rayman : It was fine to keep "there's no games for Wii" at bay, but now that that's over, it's not really worth it. It fails as a party game and that's all it is. Gotta love the Rabbids, though. Resident Evil 4 Wii Edition : Everyone besides me had already played it, and the only thing different from the next newest version is the controls. The controls do feel very natural, though. Recommended if you haven't already had enough of RE4. Metroid Prime 3: Corruption : Recommended. It has some faults especially for hardcore Metroid fans (too linear, tries to do some things that have become standard in FPSes, but have no business in Metroid, etc), but the controls are really amazing, the environments are immersive, and the bosses are very enjoyable. Just start on the harder difficulty if you hate non-challenges. Super Paper Mario : Another one that was made better because there weren't enough Wii games at the time. The platforming feels very watered-down and the original elements weren't really used to great effect. There's a lot of repetitiveness and the RPG elements only serve to make the game easier, but the style's amazing, the story's pretty interesting, and the dialog (though often tl;dr) is, as usual, wonderful. SSBB : no comment needed. (by which I mean who hasn't already formed their opinion of this by now?)

Saying people shouldn't be so serious about a game like SSBB simply isn't enough. It's not unreasonable for people to be disappointed that SSBB isn't suitable for being used as a serious, popular competition game (though I'm far from convinced that it isn't suitable) when SSBM so enjoyed that status. Sufficed to say, anyone who's so stuck-up on competitive gaming that they can't at least enjoy a great game for what it's worth because it isn't viable as a huge competitive meta-game game can go fuck themselves.

ANATOMY! Yes, Sonic has a leg growing out of his tail. Didn't you ever look close at the Heroes model?

When do you change dir? How does the enemy work? For example, in the Rhino enemy, I flip dir either if you hit a wall, went off an edge, or an alarm reached 0. Right now you're inside the enemy object (I assume), so it's his dir you're dealing with, and... well, that doesn't tell me much. The code itself looks fine. Edit: actually, you have a single & and that would mean bitwise and instead of boolean and, but I don't think that should matter cause "can_shoot == 1" and "dir == 1"/"dir == -1" will give you boolean values. Still, might as well fix that: .... if (distance_to_object(nearestPlayer) &lt; 100 &amp;&amp; can_shoot == 1 &amp;&amp; dir == 1) { ... if (distance_to_object(nearestPlayer) &lt; 100 &amp;&amp; can_shoot == 1 &amp;&amp; dir == 1) { ...

This... this isn't random!

Sure with infinite resolution, but. Eh, the gain would probably be completely insignificant and non-existent in practice, even with ideal positioning and the assumption that you could combine and process three images at speeds equal to combining and processing two images.

I guess that makes our brains better than frogs', cause I'm pretty sure I remember a study where they flipped a frog's vision and it eventually died of starvation. I could see some potential advantages in determining depth if the brain was dynamic enough to incorporate three slightly different PoVs instead of the normal 2. But I guess her eyes aren't positioned for that.

Focus is as much a mental ability as a visual ability. Each eye can have two different focal points, however, we are unable to focus on two separate objects because our brain doesn't work that way. I don't see how she could possible focus on two different objects even with 4 eyes. It's possible that her vision works fairly fine, only with a wider field of vision and some blind spots in the middle. It's also possible that the duplicate eyes would send signals in such a way that they interfere with each other. Don't really know, I'm not a neurologist, I'm just guessing and going by a Psych 101 book and a few documentaries. Like a documentary on people who have had the corpus callosum split so that the left brain and right brain cannot interact with each other. That shit's crazy.

THERE'S NOTHING WRONG WITH ANYTHING! Pretty crazy that they denied they were using it as an adverb, though.

Everyone knows that the REAL WoW killer will be whatever MMO Blizzard makes next. That'll probably be a while, though, for obvious reasons.

Yeah, but you only would have gotten a C- if you got it wrong in 4th grade. A C- is still passing. Also, mad as an adverb is a colloquial. Why you arguin' 'bout a colloquial, man? That's mad whack.

This is a fan-made trailer, isn't it? Anyway, since the topic's a bit too much to read, I'll probably just be reiterating, but too much freedom doesn't necessarily make the best competitive multiplayer game. Player X wants to be a god-king, building cities and citadels, whereas Player Y is out to make the best, most balanced character he can. What happens when those two meet? It wouldn't be an impossible game to make it if it were just those two cases, but you have dozens of potentially intersecting ways of playing. I, too, gotta be inclined to compare this to a fighting-oriented second life whether or not that was the intended effect.