Gradient

Ain't nothing wrong with that. But is there anything else, a space station, an airship, an underground base? A cannon, a satellite, any other object that's the focus of his plans? Do these things have a name? Stuff like that.

Dunno how Mugen works, but if objects can be rotated around each other, then ultimately you can create the Sonic 2 final boss, even if it is via a complicated rotation system.

That's better; the characters seem much more appropriately sized now, and they aren't dwarfed by the screen.

Yep, you use the sound as you normally would, but you would write global.level_music instead of just level_music.

Say you have a variable, called 'sound' for the sake of argument. If it is prefixed with 'global.', that means it's a variable that any object in the game can read. Usually variables are restricted to the object they're created in; global variables aren't restricted to one object and are persistant even if you destroy objects, change rooms etc. They are perfect for letting the game know what level or character it should load up, for example. To use that code, do the following: 1) Open My Computer, find the folder with the game in. If there isn't one, make a folder and drop the GML file in. 2) Create a new folder, call it soundfiles, or whatever you want it to be. 3) Place all your music files in there, preferably using some sort of abbreviated system to name them, for ease (ghz_act1 for Green Hill Zone act 1, say). 4) To load that sound into the game, you would write: global.level_music=sound_add(working_directory+"\soundfiles\ghz_act1.mp3",3,0);[/CODE] You need the speech marks in there, so the game knows it is looking at a string of text, and 'working_directory' means it will look in the folder the game is stored in. The last few numbers simply relate to what type of sound it is. When you load the music for the level, remember that most of the time it'll slow the game down badly for a moment; you may want to consider having a loading screen that stays up for a few seconds, in which you use that code to load the right music for the upcoming level; that'll give it time to get the inevitable slowdown out of the way.

As long as the difficulty doesn't get in the way of our enjoyment. A challenge is all well and good, but throwing your laptop out the window simply does no good to anyone. Looking forward to it though.

The problem with that second one is that while you're telling Sonic to move in roughly the right direction, it doesn't take into account his velocity (I assume, since I don't use that engine), and it only really moves him at either 45 degrees or 90 degrees. So, if Sonic is 200 pixels below the enemy and 50 to the left of it, he'll fly up and right, but only at 45 degrees, since he's moving one up and one right each step. But he'll soon be on the right of the enemy, and when the game tries to adjust his position by one pixel to the left each step, Sonic himself will still be moving more than one pixel to the right because he's already being hurled through the air. So he would curve round, but always be travelling so fast that he overshoots and misses the enemy. The code you want would be something like this: if (instance_number(objEnemy)>0 && action_jumping) { homing_target=instance_nearest(x,y,objEnemy); dist=distance_to_object(homing_target); if (homing=0 && dist<100) homing=1; } if (homing=1) { dir=point_direction(x,y,homing_target.x,homing_target.y); x_speed=lengthdir_x(thespeedyouwant,dir); y_speed=lengthdir_y(thespeedyouwant,dir); }[/CODE]

Go over your code again. If it's poorly done, chances are you may not realise it until you look at it in that light. Try simplifying things, using fewer variables, getting it to check and set variables less often, etc. It had a fairly marked effect for me, but then my code was hideously inefficient to begin with. Couldn't say for you.

That would be good. I can see myself having problems with memory usage, but we'll see. Good find.

I wouldn't object to destructive Metal Slug-type gameplay, if it's got lots of nice explosions and a few set pieces and stuff.

1) Put the files in the folders you want. At the start of the game (or whenever you want to load the sound file into the game's memory), write this: global.sound_file=sound_add(working_directory+"\whatever_folders_it_is_stored_in\name_of_file.mp3",3,0); [/CODE] Then simply call global.sound_file whenever you want to use it. 2) Chaos has loads of techniques in Sonic Battle - I'd use them instead. 3) Big bosses always kick ass.

Very, very simple, but loads of fun. I love the character sprites, and the music is just awesome. It's a miniature masterpiece of design.

Redesign. I won't tell you how you should go about it; I don't work well with meticulous planning, I just have a good sense of scale and tend to build up on whatever seems to fit next in the level, and so far it works magically. Whatever works best for you. If you have one straight path, like you do now, people will probably tend to use it rather than explore other paths.

I wouldn't pimp up the game so unashamedly until people have left their comments... Better to just let people praise you for it, if they choose to. It seems to have the speed, and the engine looks pretty decent, but the level looked incredibly linear. Jamming a spring right in the path of the player to stop them dead ain't a good thing. Add more pathways and remember the virtue of the left button. Though for a beta build, it has potential. I'm looking forward to playing a demo.

Aaaaaaah, it all makes a lot more sense now. Thanks guys; I wasn't aware that I wasn't zooming in per say. It's all fixed now. Help was much appreciated from all of you.

Hi all. I have a view related query for GM6.1. I can zoom in or out of the view using view_wport and view_hport, no problem. If I increase the xport and yport (regardless of whether I've zoomed or not), the view moves down and right within the window, leaving a patch of blank background from the top left corner. However, if I attempt to decrease the xport and yport (to less than zero), once the view hits the left or top edge of the window, the view simply will not move. The xport and yport continue to decrease past zero, however. And, if I've zoomed in or out with the wport and hport, the view will snap back to its original scale, until I increase the xport and yport past zero again. It's as though I had never made any alterations to the view at all. Where am I going wrong? I need to zoom in on a particular part of the view, but currently I can only focus it on the top left corner of the view, otherwise I get the problems I described. If my explanation was a bit convoluted, I can probably make a short video file (rather not, mind ). Thanks, Grad.

I saw quite a lot of ingame footage of both XI and XII before their release. It still looks like buttery sex, whatever the outcome of the game. And besides, how can the Kingdom Hearts team go wrong? I'm more interested as to how it's going to tie into the main game than anything else.

There are some differences. The springs have an awesome whoosy sound added to the end, for example.

'Fraid I have the BGMs already. Thanks, though.

Hi all. Quick question; are there any Sonic Rush SFX kicking about on the net? I can't find them anywhere, and some of them would be extremely useful (the jingle when you hit the end of act ring especially). Thanks, Grad.

No, it works fine. Like I said, the player character slows too quickly underwater (or in low gravity situations I suppose; I've yet to code them . I realise I made it sound as though you fall more quickly due to this code, but that isn't the case; my mistake, but no worries there), but repeating the code when underwater with a different rate of gain for the y-velocity solves it. Note that I added an extra bit to the code: if (action [B]&& vsp<0[/B] && !KEY_C) vsp+=0.25;[/CODE] This checks whether the player character is still moving upwards; if not, then the normal gravity rules that are specified within your code still apply. So, the player character slows rapidly if the jump button is released, creating the impression that you have only made a small jump, and once the vspeed has become equal to or greater than zero, the physics you specify apply as normal. It needs tweaking to suit your engine, as with any piece of code, but it works beautifully.

I have had the exact same problem, and a few months ago I was afraid that Sonic Xcel was lost. Game Maker is not exactly renowned for being able to handle MP3 files particularly well, due to the MP3 format being compressed by definition, and a large MP3 can corrupt the game file (this was my final motivation for externally storing my sound files; check the 'Chaos!' thread in General Fangame Discussion for my solution). However, all is not lost; there was a thread on the Game Maker forums in which corrupted files could be recovered. If only the sound file had corrupted the game, then the rest of the file (ie. everything except the sound files) can quite possibly be recovered. The creator of the program seemed open to taking individual game files and recovering them (he did it for me, with perfect results), so you could ask him if he would be kind enough to do the same for you (assuming the program can't help you; it can struggle, given that it's not a professional piece of programming. I'll still find the download link for you). http://forums.gamemaker.nl/index.php?showtopic=200148 There's the topic. I'm Phil_T on the thread, if you were wondering.

I work in GM6, but I'm sure some of my experiences can help in MMF. Until recently, I had huge slowdown problems. By revising the code, streamlining it and altering it to rely on other objects a lot less, etc etc. I have made my game run a hell of a lot more smoothly. My code was convoluted and inefficient; I was unable to see what was wrong until I came to code the game's other characters, and the faults became apparent. It was down to so many factors; switching Sonic to another object (Sonic dying, starting the act, etc. are all handled by a single object now), my water and drowning code, my pseudo-Tension gauge and boost code - everything worked better when I improved many aspects of my code. Look at your code. What could be done better? What could be incorporated into a single variable or object? I'm still not entirely sure what caused certain instances of slowdown to vanish, but I knew my coding was improving dramatically, and vanish the slowdown did. The feeling of improvement is palpable, and perhaps if you take a fresh look at your work, you can make similar improvements. I liked the demo; you got the animals right after destroying enemies, and the act end visuals were very well done. Frame rate aside, this has potential to be a highly satisfying fan game. Keep going, rework your code, and learn what makes a video game work well in terms of code. I know you can do this.

Sorry to hear that, AeroGP. Is there anything you can do? Blaze, it's good to hear the good news about SoC - give us some updates on what you've lost and what you've recovered. It'd be shame to lose it.

If you put in an easy-to-use cheat system, I will use it. In another fan game (can't remember off the top of my head), the level skip remained in the final game, so any reminder to remove it shouldn't be ignored! The main problem is that you need to add in a lot more attack and movement techniques. Chaos has loads in the Sonic Battle system - play around, get used to GM6's code system, and put in a load of attack patterns, flips and evasion techniques. He doesn't jump in the same style as the main Sonic characters, so I recommend not using it at all - make Chaos a unique character, and you could have a great fan game.