Examples of the interface for both the minimap and full map in Super Metroid:

<img src="https://dl.dropbox.com/u/919275/CivilWarProj/Placeholders/Super%20Metroid_1.png" border="0" />

<img src="https://dl.dropbox.com/u/919275/CivilWarProj/Placeholders/Super%20Metroid_2.png" border="0" />

I want to be able to create a similar map interface, where the player can see where they are in the level at any time, and dynamically fill in blanks and unexplored areas as they explore the map, as well as display a mini-map as well.

Now, for the map itself, I figured it would be a simple matter of having an array that records every 'square' on the map, which has, in order:

* X and Y values for grid position (needed for a 2D array to work)

* A value that determines whether it is 'hidden', shown but unexplored, or explored

* A value that determines what "type" of square it is (basically, a 0 would be completely blank, 1 would have a wall on the left, 2 would have a floor but no walls, etc).

* A value for if there is an icon to display on the square (such as a save point, an item, etc).

That's easy enough, but the main issue after that is showing and displaying both kinds of maps, as well as determining where the player is on the grid at any one time. I've been considering setting up a 'grid' of invisible objects that would work as 'grid spaces' with the values and can collide with the player to automatically determine where the player is on the grid (and would also be useful for level design, since I would have a reference on hand), but setting up an entire grid of those things would likely be rather tedious, I imagine, and I'd rather have a more automated method.

And then there's setting up the map grid itself, which is somewhat trickier, I think. Setting up a map manually is also quite possible... But it would be EXTREMELY TEDIOUS. If there was a tileset feature, doing it manually would actually be pretty easy. XD

I've been trying to completely re-do my Sonic engine step-by-step, starting with the stuff that works, reworking things to avoid using functions, and generally trying to make everything work, I've already run into issues.

I'm currently using a platform behaviour as a stand-in to test basic multiplayer movement, and while that works as intended, I found that implementing sensors on their own results in some nasty framerate drops. My computer is quite fast, and to see a bare framework of code cause the framerate to drop below 60 is disconcerting to me.

dl.dropbox.com/u/919275/SC2WOverhaul.capx (Need standard license, r108.2)

It's hardly complex, it's mainly a bunch of sensors being stuck in certain spots (with an algorithm in place for them to move according to any player rotations). "Collision Old" is the original set of sensor events, while "Collision" is me trying to mess around and try and find an alternative method (which isn't going particularly well).

I'm gonna keep this thread as an on-going series of incremental implementations, trying to figure out what works and what doesn't, and what to do differently.

So, first question: How can I optimize the sensors while keeping their ability to position themselves properly as the player rotates?

So... Your complaints boil down to "a lot of games use Steam"? And WHY is that a bad thing? Also, your use of the term 'monopoly' is not particularly solid - it tends to be thrown around a lot at anything that happens to be really big, but Steam is not even trying to be a monopoly, there's nothing stopping other services from trying to be big, but the big difference between them and Steam, is features.

A lot of games use Steam, as do a lot of people, because it's a great service. That's it. Nothing else can remotely compare. In a single client, you have an in-client store (including wonderful deals that you'll rarely find elsewhere, even in retail), a single convenient game library that can also include non-Steam games, automatic updating, cloud saves, chatting, friend and group lists, and other community features, Steam Workshop lets you check out new content for certain games that other people have made (levels, mods, etc), and Greenlight makes it easier for Indies to get into the service, now that the community can give their say. Its offline mode is a tad stuffy, but that's a relatively minor issue.

Honestly, the only reason I can think of for anyone to really hate it is if they loathe any kind of DRM on principle, despite the fact that Steam is pretty much the only form of 'DRM' out there that actually provides a good deal of benefit and value to the consumer.

It's been a few months, so... Hoo, boy. I haven't been working on this all that much ever since r100 came out, because of another disheartening setback (which I'll get to in a moment).

Web playable link, and now an EXE download.

Construct 2 .capx, C2 Release 106, requires Standard license (also requires the Function Plugin)

Aside from a few additional releases I've made on other forums, not that much has really been done, aside from moving platforms (surprisingly simple) and more a proper level framework.

Now, this project has been fraught with problems, but now that there's actually a level framework, it also came with a horrible realization that even in WebGL, the framerate drops dramatically even with that bare bones of a level. Good grief, there should be no way that the engine should be THAT SLOW. It shouldn't even be a FACTOR in any kind of FPS drop.

I'm at my wit's end, here, honestly. I don't know what to do, it makes me want to scrap the entire thing and start over, but with two of the people who be most likely to be able to help with that either won't reply to my PMs or is inundated with work, I'm pretty much lost. Considering the sheer instability of the project, a total restart is probably for the best, but I wouldn't know where to START, nor how to do things better than the framework I'm already using.

Good grief.

Considering Game Maker already advertises itself as 'free' with "priced add-ons", I imagine using Construct's licenses in a similar manner would easily beat them at their own game. Even with the recent price increase for C2's licenses, it still trumps Game Maker's entire package by a mile.

On one hand, the WHATWG now has the freedom to advance the HTML5 standard as much as they want, while the W3C is left behind. On the other hand, MS will generally stick with features for IE that suit it most.

Though, really, it's not gonna make much difference, I plan on adding an advisory notice in my games telling IE users to switch to Firefox or Chrome for better performance. It's not that much of a hassle to switch, and I don't see the point in accommodating a browser that doesn't keep up in terms of performance and features.

Awesome! Runs beautifully on my laptop, though it still has the bizarre transparency issue from the previous test demonstration.

Thanks. It has its issues, but I hope I can iron those out eventually.

Update!

Additions:

• Z+Down allows you to fall through platforms.
• Springs
• Sonic can now be hurt (With S3 animations rather than Advance, yes, I'm a bit lazy with that, but I'd rather be coding than doing animations)
• Spikes
• Rings and ring loss
• A few sound effects
• A "Inner_SubStepLimit" fix where the Player would stop moving at speeds higher than that value (seems to cause a couple of minor issues of its own, though, oddly enough)
• Monitors, some of them working fully (the icon doesn't float up and disappear yet, and monitors aren't solid, see issues list)
• Shields with special abilities (Bubble shield ability doesn't work yet for reasons listed below)
• Bumpers, both from Spring Yard and Carnival Night Zones, working more or less perfectly
• Balloons from Carnival Night Zone
• Shoved all the Sonic-specific stuff into its own event sheet, for the sake of organization

New issues:

• I need to figure out how to make solid monitors and the Bubble Shield bounce work without making Sonic automatically go into 'idle' mode upon landing.
• Sonic's sprite lags behind the player object a tad now in some circumstances, for some reason.

Ah, it's alright, it worked out in the end anyway. Thanks, mate!

Whoa, whoa, back up, Ash, I think you accidentally misinterpreted what I actually want, because, well, the bug fix you've made is exactly what I want.

hat you want is for the rotate behavior to set the angle of motion, but not the object angle.

Actually, the opposite is what I want - for the rotate behaviour to only affect the object angle, not the angle of motion. <img src="smileys/smiley36.gif" border="0" align="middle" />

hat really is the bug report is setting the object angle shouldn't affect the angle of motion when bullet's 'Set angle' is set to 'No'. In this case the object angle and angle of motion should work independently. Previously, if you ever set the object angle, C2 would also update the angle of motion. This has been fixed for the next build so setting the bullet's angle only affects the object angle and not the angle of motion. However, the result is still not what you wanted: the object moves continually to the right, since the angle of motion is always 0, while the object appears to rotate.

You're mistaken, actually. I WANT the object to keep moving to the right (or up, or down, or wherever) in a straight line. (And then flip around and come back like a boomerang, but that's a different story.)

here is also one exception: the angle of motion is still set to the object angle on the first tick of the behavior. This is to preserve compatibility with existing projects like Space Blaster, where many objects are spawned then 'set angle' used to modify the bullet angle. The bullets would fly off at the wrong angle unless they initially take the object angle as their first angle of motion.

Eh, not a problem, I usually define the angle of projectiles on creation anyway.

opefully that's clear... however, even with the fix, you'll still need to use a second hidden object or manually set the angle of motion with events to get the effect you want.

Also not an issue, since I plan to do the latter anyway.

I still think the opposite should be true as well, that rotation should not affect angle of motion if the developer wants it that way.

Kyatric: I'd use that, but it's rather difficult without Containers, unfortunately.

My point still stands regardless - "Set Angle" is supposed to allow the object to rotate WITHOUT affecting the Bullet behaviour's angle of motion. In this case, the Rotate behaviour should make the cross spin while the cross moves in a straight line. It's not that complex.

It's a bug, plain and simple.