Kain

I always took Knuckles to be more of a Rook. Well certainly no bishop, in any event.

I don't think you can change a single instance's origin, since origin is stored per sprite (of which there is only one to span across all objects). View rotation is easier.

What I do is I have an object to mark the water level, but the actual water level is just stored as a variable in my oLevel object (at the beginning of a room, oLevel looks for a water object; if it exists, it grabs its y position and stores it as water_level, also destroys the object; if it doesn't exist, it defines water_level as room_height + 9999). I draw the water with simple code: y1 = max( water_level, view_yview[0]); y2 = max( water_level, view_yview[0] + view_hview[0]); draw_set_alpha( 0.5); draw_set_color( make_color_rgb(25,25,120) ); draw_rectangle( view_xview[0], y1, view_xview[0] + view_wview[0], y2, 0); draw_set_alpha(1); I find that dealing with a y variable instead of a big rectangle to test collision with is easier for Sonic interacting with the water. I also have an object which is a small platform which handles Sonic running on water. It has the wake animation and only follows Sonic when he's moving fast enough and is just above the water line (otherwise it stays out of view).

8bit music playing behind slow, deliberate, and uninteresting dialog. The only thing they seem to have going for them is expensive recording equipment (though I'm not loving the blur). I wouldn't mind watching if they made a fast-paced 15 minute short, even if it was fan-quality, but if they're planning on making a full-length film, I'm not quite nerd enough to watch.

Yea. IIRC, BugMeNot is a service which automatically (with a FireFox add-on) logs you into a website or forum (usually one that does not allow you to access much of the content without a [free] account) on a dummy account (usually one which another BugMeNot user sets up) so you can see the content without having to go through the bother of registering. No member-only content on SFGHQ other than posting, so no need for that to be allowed.

Ah. There it is. You're performing this code in the Sonic object, correct? Well, in any event you're perming this code in a single object, and you're probably performing the scrPlayerHandleObjectFallingCliffRight code in the same object. And since an object can only have one timeline, naturally they're going to conflict. What you should do is have an empty object (if you don't have one already; for the same empty object type can be used to different ends), named oEmpty or something. Anyway, what you do is create an empty object when Sonic lands on it and set all the variables and the timeline inside the empty object. That way not only will the left and right not interfere, but the lefts won't interfere with other lefts. Also you should add the code "instance_destroy()" at the end of your timelines so the emty objects don't stick around after they're necessary. // ==== FUNCTION ==================================================================== // scrPlayerHandleObjectFallingCliffLeft() // ================================================================================== // _ObjectHandle = instance_nearest(x, y, objFallingClifLeft); //if(_ObjectHandle != noone) //{ if (scrPlayerCollisionBottomObject(sprPlayerMask15, 1, _ObjectHandle)) { var t; t = instance_create( _ObjectHandle.x, _ObjectHandle.y, oEmpty); with( t) { xCliffDropL = _ObjectHandle.x yCliffDropL = _ObjectHandle.y cliffL1 = instance_create(xCliffDropL+256,yCliffDropL,objFallingCliffPiece); cliffL2 = instance_create(xCliffDropL+240,yCliffDropL,objFallingCliffPiece); cliffL3 = instance_create(xCliffDropL+224,yCliffDropL,objFallingCliffPiece); cliffL4 = instance_create(xCliffDropL+208,yCliffDropL,objFallingCliffPiece); cliffL5 = instance_create(xCliffDropL+192,yCliffDropL,objFallingCliffPiece); cliffL6 = instance_create(xCliffDropL+176,yCliffDropL,objFallingCliffPiece); cliffL7 = instance_create(xCliffDropL+160,yCliffDropL,objFallingCliffPiece); cliffL8 = instance_create(xCliffDropL+144,yCliffDropL,objFallingCliffPiece); cliffL9 = instance_create(xCliffDropL+128,yCliffDropL,objFallingCliffPiece); cliffL10 = instance_create(xCliffDropL+112,yCliffDropL,objFallingCliffPiece); cliffL11 = instance_create(xCliffDropL+96,yCliffDropL,objFallingCliffPiece); cliffL12 = instance_create(xCliffDropL+80,yCliffDropL,objFallingCliffPiece); cliffL13 = instance_create(xCliffDropL+64,yCliffDropL,objFallingCliffPiece); cliffL14 = instance_create(xCliffDropL+48,yCliffDropL,objFallingCliffPiece); cliffL15 = instance_create(xCliffDropL+32,yCliffDropL,objFallingCliffPiece); cliffL16 = instance_create(xCliffDropL+16,yCliffDropL,objFallingCliffPiece); timeline_index = tmlCliffDropL; with(_ObjectHandle)instance_destroy(); } } I believe that's what's going on, anyway. As troublesome as it is to do this in timelines, it's pretty much how it should be done. The only way you could really "improve" upon the code is to use for loops (and arrays) and that would really just cut down on the amount of code and coding time. It'd also make it a little more dynamic in that you could define the width and (if you had it) height. But other than that, it'd be pretty much the same timing concept. Another potential problem is that using "instance_nearest" to decide which object to choose might not be a pixel-perfect method, but since you have left and right falling cliffs separate objects, it's not likely to matter (so long as this is called from the Sonic object, of course). (also, with regards to your PM, I'll get back to you on that; but I have been and will be too busy to think about it 'til after the Nov 8th)

Unfortunately you don't got the ID to prove it. You were the post that was made so that our current active post count was 90000. The 90000th post by ID was DWs: http://www.sonicfangameshq.com/forum/showpost.php?p=90000

Here's a really old topic I made describing how angle detection is done, though not much attention is payed to the trigonometry; it's kinda taken for granted (I suggest learning the basic trig functions and how they are used in converting vectors to different forms as soon as possible): http://www.sonicfangameshq.com/forum/showthread.php?t=2243 arctan2(-(y2-y1),(x2-x1)) is the formula for determining the angle from point (x1,y1) to point (x2,y2) {note: the y-axis is flipped in most computer programs}. The problem with arctan is it only returns half of the possible range of answers and gives a divide-by-0 error when (x2-x1) = 0.

Probably because it's not too far-along yet. All you have at this point is a Sonic Advance sprite Sonic with a little afterimage trail, placeholder level and enemy graphics, and a HUD. Nothing that anyone hasn't seen before.

Tiny characters with huge game resolutions seem to be popular with amateur game makers. But the thing is it completely takes away the immersion whenever you're playing from a view-point which is some 1/4 of a mile away from the character.

No problem. Here are some essential trigonometric functions which come up very frequently in working with game physics. And they're pretty much verbatim the solutions to these problems, so I thought they were worth mentioning: arctan2( -(y2-y1), x2-x1) - will give you the angle of the vector going from (x1,y1) to (x2,y2). sqrt((x1-x2)*(x1-x2) + (y1-y2)*(y1-y2)) or sqrt(sqr(x1-x2) + sqr(y1-y2)) - will give you the distance from (x1,y1) to (x2,y2) cos( angle) * distance - will give you the x-component of a vector whose magnitude is distance and whose direction is angle -sin( angle) * distance - will give you the y-component of a vector whose magnitude is distance and whose direction is angle cos( angle2 - angle1) * distance2 - will give you the projection of This last one is used whenever your progress is impeded by an angle or something. This is the amount of your old vector gets transfered into your new speed.

== Slope Gravity Acceleration == Acceleration from slope gravity is a simple trigonometric formula based on projection: -sin( angle - gravity_direction) * gravity; angle is the angle of Sonic where 0 = flat floor, etc. gravity_direction is the angle of the vector that gravity is pulling in (in general, it's 270 or 3*PI/2 meaning straight down) gravity is the acceleration from gravity in pixels / second^2. Although I believe it's generally multiplied by 0.8 to work well with the other accelerations (i.e. so it's not too powerful to run in loop-de-loops). You simply add that to your horizontal speed once per step and you got slope acceleration. == Jumping and Landing == As for jumping, angle is generally kept at 0 while you're in the air. And the speed when jumping is converted into x/y form instead of magnitude/direction (i.e. the way you're doing it). The formula to convert magnitude/direction to x/y including the jumping off of the slope you're on is: Vx = jump_power * cos(angle + PI/2) + speed * cos( angle); Vy = jump_power * -sin(angle + PI/2) + speed * -sin(angle); And to convert them back (i.e. when landing), it's (make sure you change angle to the slope of the curve you're landing on): speed = cos( arctan2( -Vy, Vx) - angle) * sqrt(Vx*Vx + Vy*Vy);

Indeed. That speed boost is definitely there in Sonic 2 and Sonic 3&K. But the thing is it didn't do it for normal slopes (maybe it did on Sonic CD), it only did for the curves of quarter-pipes and such. As I remember it, anyway.

Alien is not a race. It's a disease. Anyway, nice... thing. It's got lots of... ridges.

No good. Sonic XG is already doing that.

keyboard_check_pressed checks only if you just pressed the button.If you are holding it down, it will not continue to return true. And keyboard_check_released checks only if you just released it. And so the only way to activate this code is to hold down enter, then release enter and press F1 at the EXACT same time. I believe the code you want is: if((keyboard_check(vk_f1)and keyboard_check_pressed(vk_enter))){ //Platform starts moving up vspeed = 3; }

You mean like the "cute little animals jumping out of the badnicks after they are destroyed." Not that you were actually nitpicking about that. Edit: fuck, I wasn't recording. Edit 2: But this time I was :3

Well, Sonic CD didn't have the angular spin dash, either. With angular spindash it's like it's digging into the ground, but with the other one it's hydroplaning. But obviously it's lower-priority, especially if you haven't decided what to do. Also, I'll just add that I personally love the sprited dust trail and not so much the particle dust trail that some fangames use.

That's a complete straw man argument. The issue in question is whether or not an MMF-developed game is good material for getting into a video game position (and, consequently, whether it is good experience for working in a video game position). Sereph and I and others are making the case that design- and to a lesser extent, logic- is independent of actual engine used. And thus that developers would look at experience related to MMF as relevant despite the fact that they themselves would never consider using that engine. For a technical position this might not hold too much weight (provided that it's your only experience in programming), but it's not like it's make-believe work which professionals will look down on as if the scribblings of children (lol, straw man for me this time).

Well, the only entries which are official are replies to Brad's original video. But some people are hiding away their entries so no one can copy them til the last minute. Brad says someone hit 48.87 on the first level. And I myself have a 49.81. I have no idea about the second level.

Well I'm pretty sure you were replying to someone who wasn't. The game designer, after all, is not the one to choose the language a game's being made in. And if he were, then he wouldn't choose something just because he used it, because he won't be involved in the implementation in that way. We had this discussion back when Noitu Love 2 came rolling in having been made in MMF2, I think. Despite being a game made in an engine which we associate as being a crap engine because we're amateurs and look around seeing a bunch of people far worse even than us using it, it's an amazing game and is able to be sold commercially. In addition to being wonderful for his design portfolio if he plans on proceeding in the game industry. Sure, it won't run on the kind of computers that a game of that technological sophistication (or lack thereof) should be able to run on, but that's about the extent to which the game being made in MMF limits it.

Pardon my word choice, I'm still reeling from the sheer ridiculousness of the whole 40-page self-promoting webcomic thing. Particularly the fact that it's the only way to get information on the browser from the download page and there was no way to navigate it besides "next and previous." Also some short video snippits, but they hardly give much information. I don't fault the actual browser for it, though I do feel like more intuitive documentation is needed for such a change. It's still a whole "bludgeoning you over the head with design" thing which has bugged me from the install procedure. I am, on the other hand, rather impressed with its interior workings, in so far as they surface in my everyday browsing.

I hate it when someone who posted a question replies simply to answer someone asking a tangential question or comment while ignoring a long, thought-out explanation of the solution to your problem. Besides, it confuses people who might want to help but don't know whether or not the problem has been solved when you reply after a potential solution but don't address it.

I can definitely see that. It's mighty arrogant the way they rearrange the entire user interface, adding and subtracting functionality without options to modify them and act like it's some amazingly intuitive design. I personally hate tabs being at the very top with tiny text above a bar with huge text and huge buttons which I never use. Nor do I like how they completely get rid of the options bar in favor of a single button which only houses about 1/10 of the features. Guh. And I loathe occluding rectangles which pop out of the woodwork when you hover over a link and use the search.

But certain concepts are code-independent. Take the little interview with Hirokazu Yasuhara where he mentioned something along the lines of "I pitch the programmers an idea for a certain gimmick and sometimes they tell me that it'd be too program." Obviously he had very limited involvement in the coding and implementation and there are obviously many other positions which are only concerned with the act of implementation in that they are working with people who will have to implement their ideas. If you demonstrate design experience on a platform, even if it's too amateur tech for serious commercial use, then it's still real design experience. Though I have heard of a slight difference in Japanese and American game development where in America, designers are more likely to be former programmer and/or have significant programming backgrounds. Depends on the project, really. If you're working in a position that's integrated with other people, and if you're working in a position which is likely to be transitioned from person to person over time, then they definitely want your code to be readable. Usually, though, they'll have certain guidelines which you have to follow in terms of commenting and organization of linebreaks, variable naming, tabbing, etc. For gaming, efficient code is important in that if it is made too inefficient then it will not run at adequate FPS, but above all companies want the code to get done and done per the specs. It's unrealistic to think that any company is going to give their employees a choice in what language they use in all but the most inconsequential and/or secondary of tasks. Like I said, being a good programmer is fairly language-independent and a company can teach a good programmer any programming language in a matter of days or weeks. Although, at the same time there is a hierarchy of languages. In that, for example, they will not be likely to hire someone with no experience with object-oriented language to code a project being made in Java no matter how well a you can program in BASIC. And more on the issue, if a person only has experience dealing in languages where little to no memory management and infrastructure control is necessary (such as Game Maker, and probably a lot of the others), then they probably won't hire you as a serious programmer.