Construct Port

[Candescence]

Yes, laugh at my 5-minute Paint.Net edit.

Anyway, while waiting for Dami to finish porting the Construct version of the base Sonic 360 engine, I decided to do it myself, using Worlds as a reference. Then, realising that porting from a program I have absolutely no experience with to Construct is gonna be hell. So I also asked the guys over at the Construct forums for help, though I haven't really gotten any yet (besides trying to solve a below problem), and I also decided to not just port over the base engine, but Sonic Worlds in full - and add new things to it, as seen below, and hopefully simplify it as much as possible.

So, to differentiate, I decided to coin the port "Sonic Construct Worlds", not really original or amazing, but it works.

Why? Not everyone uses MMF2 or its sibling programs, you know, and I honestly prefer Construct (especially the event system). It'll give Sonic fan-game makers an option other than MMF2 or Game Maker. As well, it provides a platform engine more advanced than the regular platforming behavior.

So, all Construct users here (probably few as there may be), I ask for assistance! Especially with deciphering MMF2's events. That's awfully troublesome for me.

And to Dami: It's not like you don't have to stop working on the engine (Sorry for pestering you so much about it). I'm just trying to help get the workload off your shoulders, dude.

CURRENT GOALS:

- Fixing directions - DONE

- Basic/Common Actions - DONE

- Sonic Actions

- Tails Actions

- A lot more documentation. Seriously.

After we've gotten all that stuff out of the way, we'll focus on the rest of what Worlds has.

ORIGINAL ADDITONS:

- Two "movement modes" - "Sonic mode", and "normal mode", the latter of which adjusts movement for characters who are incapable of reaching the speed of Sonic and co. while also making regular slopes (not loops) traversable, and slopes for the most part doesn't affect jumping. So, it's a good idea to separate actions such as spin-dashing from the "common" actions once we get around to those.

CAPS:

Original unfinished base engine .cap by Dami

Current .cap of Sonic Construct Worlds (guest-starring Julius Belmont and Ashe! Yeah, they're there because I'm using the engine for Aria of Destiny and I was using the cap for animation testing, but they work as suitable "non-Sonic" testing skins.) NOTE: Only works with Construct version 0.99.7! Yes, it's been marked as 'unstable', but I have yet to find problems with it anyway.

OTHER LINKS:

Construct

[Death_Daniel]

Hmm, looks rather interesting. I'll download contruct play it and have a mess with it and give me comments afterwards but finaly someone ported it :3

[Candescence]

Okay, looks like the direction-change problem is solved, thanks to the guys over at the Construct forums. Deadeye and QuaziGNRLnose offered two surprisingly simple solutions.

You just gotta get your angles right

Anyway, with a player sprite that can turn 360 degrees, perhaps a different approach is needed?

Some of you may remember Vert, the game I was working on where you could turn the screen and the player any which way. Here's how I did the player sprite so as to make things a LOT easier when it comes to calculating angles: linky

Instead of making both 0 and 180 degree animations under a "Run" animation, I made ALL of the sprite frames face 0 degrees and split animations up based on Left or Right. Here you can see I just flipped it for the runLeft animation: linky

He can face Left or Right at any angle, not just 0 and 180. Having only one angle in your animation means that you can spin it freely rather easily. And to change "directions" from left to right, you gather input in a pv and do like so:

+ Control "Move Right" is down
    -> Set Player.Value('facing') to "Right"

+ Control "Move Left" is down
    -> Set Player.Value('facing') to "Left"

+ Player is moving
    -> Player.Sprite: Set animation to "run" & Player.Value('facing')

It was also a lot easier calculating angles in my events because I could do it all from 0, I didn't have to add or subtract 90 degrees to compensate for the player sprite's default angle. Something to think about, anyway.

And yeah I do plan on finishing this game some day, but it broke like crazy a few builds ago and I pretty much have to redo the whole thing from scratch so I might as well just wait for 1.0.

i just set width to a negative or positive to mirror my sprite., something like when its facing left set width to abs(.width)*-1 and when its facing right to abs(.width). you dont have to waste any extra memory either!!!

I chose the latter, which is basically changing the width to positive and negative, and doesn't waste extra memory, though it's better to go with Deadeye's solution if your sprite has unique animations depending on if it's flipped right or left. I'll post the .cap as soon as I've finished with it.

[Candescence]

GENTLEMEN.

The cap has been updated.

- Turning bug fixed

- Basic, common actions implemented (Idle, Walking, Running, jumping, Standing Up, Crouching)

Click the link in the original post for the updated cap.

[Asuma]

Might want to repupload. I'm getting a invaild error whne opening it. I have the latest version of Construct.

[Candescence]

Yeah, the stable version. But this .cap only works with the 0.99.7 version, which is currently marked 'unstable', but I find it's pretty stable and runs faster, anyway.

[Candescence]

New .cap uploaded. Click the link in the original post for the updated cap.

- Skidding implemented, as well as a turning animation function for "normal mode". Not quite perfect, but it's getting there.

- Spin-dash and rolling implemented. Also imperfect, for example, spin-dash release is too slow at the moment. Might consider using TimeDelta as part of the functionality.

- Separated code for the skins into their own specific Event Sheets. I also might consider doing the same for actions. It would probably be better that way.

[LarkSS]

Bit of a bump, but it's related to the topic.

A few days ago I finally decided to try Construct. Opening your engine ( after I finally found the beta version you forced me to use ), I experienced terrible lag by simply walking across the ground, though it would disappear when jumping strangely enough. The actions felt kinda iffy too, and rather than attempt to see if I could fix issues in a program I wasn't yet comfortable with, I opened up Damizean's original and decided to tinker from there.

After spending hours just to add in very basic features, I soon found that Sonic was lagging while walking across the ground in this build too! I honestly don't think Construct is ready for a Sonic engine until they fix it up with some major optimizations, and make the event editor more intuitive.

Edit:

Meh, when I looked into the events again wondering why the sudden slowdown occurred, it seems that Construct, during its fit of letting me click the plus box to open a group, DUPLICATED one of them. Removing the duplicate brings the speed back to normal, but the group it copied really shouldn't have slowed things down as much as it did, so it just lets me know that it's just barely managing 60fps; not good.

[Asuma]

That might be programmer's error. I never had slow on the old one dami post sometime ago on Construct forums.

[LarkSS]

Remember Azu your computer is much better than mine, so my laptop is much more capable of testing speed.

Edit:

After tinkering around for awhile, I decide that I no longer wanted to work with Construct anymore, for various reasons that I will not flood this forum space with.

In any case, I will share the modifications I made, as many of them are unique to Candescence's build and may be useful to him or anyone else who work with Construct. Also, it still runs at 60fps for me ( after I made that correction I mentioned in the post above Azu's ), so it is still efficient like Damizean's original.

.zip"]SonicConstruct[edit].cap

[Candescence]

Really? It all works fine on my laptop, which isn't exactly that good in terms of hardware, and it runs at a smooth 60 FPS. Note that the V-Synced framerate mode in Construct generally limits itself to 60 FPS, so if you want to test FPS properly, change it to unlimited.

But, the code from your cap might come in handy (including the animation speed thing), thanks. Though, I do things kinda differently with actions for multiple reasons. But the code for the parallax is kinda unnecessary - you don't need any events whatsoever to do parallax scrolling in Construct.

[LarkSS]

I labeled it as efficient parallax for a reason. Just like in MMF2, Construct does not let me properly set up parallax unless I make it HUGE, which is very inefficient and will just kill the CPU in no time. My method sizes and positions the BG in such a way that it's barely big enough for the window, yet looks visually the same.

You may want to make sure to get the Animation Reset thing I implemented copied over to your build as well; for whatever reason, Construct does not return to an animation at frame 1, and it can make animations like the idle animation look bad when you stop moving and Sonic is already tapping his foot. I think Damizean foresaw this and provided the Animation_Previous value for when he might have corrected it; I used the same value in fact to detect when the animation was changed.

[Candescence]

I labeled it as efficient parallax for a reason. Just like in MMF2, Construct does not let me properly set up parallax unless I make it HUGE, which is very inefficient and will just kill the CPU in no time. My method sizes and positions the BG in such a way that it's barely big enough for the window, yet looks visually the same.

That's what the tiled background object is for. The tiled background object can allow you to make it huge with very little CPU use at all, no more than your method by any means. If anything, your method is LESS efficient than simply using the tiled background object and changing the layer's scroll rate. Nobody use events for parallax scrolling in Construct, ever. There is absolutely no need to.

You may want to make sure to get the Animation Reset thing I implemented copied over to your build as well; for whatever reason, Construct does not return to an animation at frame 1, and it can make animations like the idle animation look bad when you stop moving and Sonic is already tapping his foot. I think Damizean foresaw this and provided the Animation_Previous value for when he might have corrected it; I used the same value in fact to detect when the animation was changed.

Well, that little thing is incredibly easy to fix if you don't want it, not really a hassle at all. Heck, longtime Construct users have gotten used to it (some think of it as more of an accidental feature).

[Zenor]

That's what the tiled background object is for. The tiled background object can allow you to make it huge with very little CPU use at all, no more than your method by any means. If anything, your method is LESS efficient than simply using the tiled background object and changing the layer's scroll rate. Nobody use events for parallax scrolling in Construct, ever. There is absolutely no need to.

Wait, what? Simply having the background slightly bigger than the screen, without having to stretch it all the way through the field seems much better to me. If anything, this method saves me from going through that, and the layout doesn't get filled with it.

Well, that little thing is incredibly easy to fix if you don't want it, not really a hassle at all. Heck, longtime Construct users have gotten used to it (some think of it as more of an accidental feature).

I'd consider it just an "accident", not a feature by any means. I'm not trying to do a shooter here - I'm trying to do a Sonic game, and in this case, that "feature" is just trouble.

[LarkSS]

That "feature" caused me to spend an hour changing the animation system just to be able to handle the "feature" in a simple set up in which it could correct it in a way that works for a Sonic engine without any user interaction.

That's what the tiled background object is for. The tiled background object can allow you to make it huge with very little CPU use at all, no more than your method by any means. If anything, your method is LESS efficient than simply using the tiled background object and changing the layer's scroll rate. Nobody use events for parallax scrolling in Construct, ever. There is absolutely no need to.

MMF2 can do the exact same thing. In fact, MMF2 can do practically 80% of what Construct can do. I already know about different ways of doing things, and I have experience in what methods are more efficient than others, especially since I've been making programs that work at a constant 60FPS on an old 384MB laptop using unoptimized software.

Keeping the object at a constant small size without modifying the entire layer's scrolling properties means not only less to handle in-game, but it allows you to contain all BG parts in a single layer rather than creating an entire mess of layers when creating parallax. Also, because I programmed its method of scrolling with the camera, it can freely be modified to continuously scroll on its own, or even at random/changing speeds.

I don't know about you either, but I prefer to keep the layout clean rather than having BGs stretching nastily across when level designing.

Also this:

Nobody use events for parallax scrolling in Construct, ever. There is absolutely no need to.

Construct sounds like it has a lazy user base who have never considered using the program for anything outside of shooters on fast machines.

[Candescence]

Construct sounds like it has a lazy user base who have never considered using the program for anything outside of shooters on fast machines.

Bzzt. Wrong. And said user-base is not amused, either.

But, really, this isn't the place for such an argument, and I am really not in the mood. If you want to continue it, take it to the Construct forums, the guys there are reasonable and would be more than happy to discuss it.

I'm not including those events in SCW because I honestly see no point to it. If you don't like it, do it yourself, it's just a couple of events and a family, for pete's sake. No point crying over spilt milk, after all.

[Asuma]

He's right though. Construct still have issues. I tired creating a rapid explosion and the application crashed.

[Candescence]

He's right though. Construct still have issues. I tired creating a rapid explosion and the application crashed.

Well, I'd be a complete idiot to deny THAT, though it is to be expected, I mean, Construct is still practically in beta, being worked on by three people for no profit whatsoever, but it is improving a lot over time, the devs are trying to iron out as many of the bugs as possible before version 1. After they finish that, Construct 2 will practically be a complete overhaul. It does help that quite a few pretty awesome plugins are also made by the community to improve its functionality.

[ssbfalcon]

Hmm... I may check this out as I don't have my old MMF copy anymore, and I'm not too keen in acquiring MMF2...

Is this project going anywhere anymore? Eh... maybe I could pick it up, now that I actually have time to do stuff...

*Edit* Oh... It's pretty uh... Broken...