(9 replies, posted in Off-topic)

Alexandre wrote:

This is a question for G.E.R, Race and anyone who might be interested: what is the best way to design levels?
Is it best to use an image editor to build the entire level and then import it into the engine? Or is it best to design clusters of reusable bricks and put them together in the level editor?

I personally prefer the image editor idea, precisely because it can bring more creativity freedom when designing a stage. The only problem I see with this method is to visualize a level and not conceive well with the game physics when testing it, but nothing that trial and error doesnt fix.


(9 replies, posted in Off-topic)

Thank you so much for explaining! I just need to get some extra things done first, then I can test it. I'll explain more about the idea that I'm trying to achieve later on this post too.

Alexandre wrote:

Cool!  What do you think such a tool looks like? What does it look like and how would you use it?

I think the ideal method would look similiar like the tech example shown above: start by importing a image into the tool, followed by drawing the lines and slopes, and finishing with the program converting the lines into a collision brickset, being possible to edit the conditions (passable, cloud, etc.) of the bricks too, while the angles would be calculated automatically. I don't know how possible a tool like this would be, but I believe it would make level creation much more versatile and fun.

G.E.R. wrote:

Here the illustration of "brick + collision" complex from Sonic Mania engine
White is obstacle floor zone, red is wall (for Knuckles), white rectangle is breakable.

The Retro engine also uses yellow to indicate platforms with the "cloud" behavior. This same method was used in the original trilogy.

I'm trying to achieve a perfect Green Hill Zone recreation from the first game, complete with each brick with its respective angle.I've already been able to export each individual brick (those with low opacity are the new ones from Sonic Mania). I am currently exporting the collision.

One obstacle I found is, in Sonic's original engine, it was possible to horizontally flip the bricks without having to create a new one. I believe the same is not possible in Open Surge, so I will have to reverse them manually.

Sadly enough, I had managed to achieve this all before with another method, but a glitch on my computer made me lose a few files, leaving some screenshots back:


In the pictures above, I converted every possible 16x16 collision into a brick, and threw an image object above the entire level. Which was not very smart, since certain bricks still appeared behind the layout sometimes.


(9 replies, posted in Off-topic)

Thanks for clarifying this technical part about the idea, the suggestion I gave was given more like a user/player than someone who is part of the programming team.

Alexandre wrote:

Bringing the polygons to the level designer makes things really easy it seems. Why don't we adopt a similar approach here? The good news is that we already have a system that is fully compatible with it - bricksets! A new tool for designing bricksets could do that. The starting point would not be the bricks, but rather the image you want to apply in your level. Then you could design your polygons in front of the image, and the tool generates the brickset for you.

What do you think?

Wow, that would be perfect! big_smile
That's because, my creative process to make a level starts with building it the layout through an image, and the frustration that comes with it is in how to transform thousands of different shapes into bricks and having to calculate the angle of each one totally by hand.
I believe an engine called "Sonic World" does the same method you described.

Alexandre wrote:

Our engine does support collision masks. It has been a underground feature, I guess?

Wait, it does? I had no idea! I read KZR mention it on the forum once, but I've never seen a stage make functionality of it, I can't find anything about it on the wiki either.
I would be more than grateful to know how to make use of this! It's the key I need to make progress on a MOD I'm working to bring attention to the engine! smile


(9 replies, posted in Off-topic)

Sonic Studio is a project with ambition to create an accessible slope-based level editor, being developed by Lapper.
Below includes a tech example and the latest video of his channel.


Copying directly from Sonic Retro, with some parts in bold that I think is important to highlight for the development of Open Surge Engine.

The challenge of making a 'slopeable' Sonic level editor (which is primarily fun!) has been on my mind since then. I definitely knew the answer was not tiles. Tiles are fast and simple but lack ease of creation and limits customisability, something the average user will want. Polygons were the obvious choice.
However the only reason I even began making a new version of this idea is because a 'Sonic Maker' in the same vein as Mario Maker is an extremely flawed idea. Because slopes. It's either to rigid and limited, or too customisable and unlimited. I wanted a challenge, and finish what I started nearly 10 years ago. That and... I had just made a nice Sonic engine and wanted to use it.

Insider info:
*Sonic Studio is made in GMS 2, and is fully developed by me (although there may be other credits for other parts when released)
*It's built to be as accurate as needed for an enjoyable experience. So, pretty darn accurate.
*The engine uses vectors and line intersections to perform its collision checks, and a Spatial Hash will load these near the player while playing. Any shape is possible. This essentially makes every level 100% customisable. Nothing to stop the player constructing a level that will break the engine - but I don't care. Go nuts I suppose.
*The art is all by me, going for a Mania/Tyson style. Though there's some place holder stuff you'll see, everything is subject to change.
*I'm currently just adding features and art. Lots of features and art.

I fully agree with the quote, because at least for me, the least user-friendly part of Open Surge is in creating the bricksets. Even a simple task like recreating Green Hill Zone from the first game (which also uses bricks as a method by the way) becomes highly complicated because the lack of collision masks that the engine does not support at the moment.
I don't know much about programming in general to suggest using polygons, but I thought it was a good idea to highlight his design ideas.


(9 replies, posted in General)

KZR wrote:

Long legged Sonic would be a disaster, but short Sonic (classic) would have no trouble.

funnily enough, I've made a quick sketch of a smaller surge a few months ago:


(88 replies, posted in General)

KZR wrote:

you don't need to sacrifice those elements. you just have to build the system differently.

maybe those could work as separate objects?

Yeah, maybe it can. Still would have to figured out a way to attach the lock on sprite on the enemy however.

Alexandre wrote:

Are you changing the animation via scripting?

Yup, I was trying to give the player more running animations based on their speed.

But thinking about it, the new engine will have a new scripiting system, so programming anything in the old one won't have much use later.
For now, I prefer to wait for the new one to come. smile


(88 replies, posted in General)

KZR wrote:

the trick here is not attaching, but creating it and destroying it in very little time.

for example, you have an object called ".homing_target"  which can be created by every enemy at every 0.1 seconds and destroys itself after another 0.1. then you add a state to it where its XY position is written into two globals.

now, every time you need to home in the attack, you use change_closest_object_state ".homing_target" "position" to actually write the variables.

then all the homing attack needs is to check the distance, if it is within the allowed range, and if it is proceed with moving the player to the recorded XY position.

Did some quick tests about it, and it works! But the thing is, I had to sacrifice some effects in the process (the "beep" that plays everytime the player finds a target, and the target lock sprite who also needs to be attached to the enemy)

I think is a better idea to just wait for the new engine
with the new API, what I have programmed won't have too much use


(88 replies, posted in General)

I'm having the same problem

I've programmed a functional homing attack and I can't figure out how to attach a sensor to the enemy, since there's always more than one on the screen and they're constantly moving.

Another thing that is bugging me out, if I want the player to do a diferent animation everytime he's in the air, there will be a slight delay and the first frame won't be from the desired animation.

As seen here:



(88 replies, posted in General)

Last month, an incovenience made my internet stop working for a week. And without much to do, I decided to come back to the Open Surge engine, and while doing so, write down the difficulties, suggestions and bugs that I found through my run. And to ask feedback right now is such a great coincidence! big_smile

Separating by categories, I have a lot to say:

Level Editor:
> Switch bricks to "Cloud Mode" and "Ghost Mode" with just one click on the Level Editor.
Not so much of a problem but it would save a lot of time. It could work the same way as the layers by pressing a key.
> A way to create multiple entities at the same time. (Or just keep then appearing by holding the button)
> The ability to copy groups as the same way that you can copy bricks.
> Some way to have more mouse precision when placing the entities.
Maybe even a programmed in-game cursor that can move from pixel to pixel would help. This problem I often had with objects and bricks that did not follow the 16x16 pattern.

> When a player is moving up and he's pixels close to a platform, it kind of teleports him directly to the platform.
(It's more notable playing by yourself)
It's an very nitpicky complaint, but it would help polishing the engine to feel more fluid as it is.
> The player "shakes" very subtly while moving.
This is also more repairable playing by itself, if you look closely you will notice that the player gives a very subtle shake especially when moving at high speed.
It's very difficult to explain, couldn't record anything about it too. And it's not because of the sprites, My guess is something to do with the camera script and the fps of each computer.
> Optional ledge animations.
I made a post a while back to why this is a problem.
> Custom screen resolution.
It is already editable with the source code but it would be great to be more accessible to the general public. I also recommend using (424x240) as the default resolution for a more "modern" touch. (It's the same resolution used in Sonic Mania)
> Tap Jump.
In Open Surge, if you hold the jump button Surge will continue jumping to when hitting the ground, it seems a little awkward. In the original Sonic games it was necessary to press the button again to jump.

> Move an object to one that is in "detach_from_camera" state.
Think about when you collect a Wumpa Fruit in Crash Bandicoot.
I achieved this by creating a guide object that uses the same positions of the camera object itself instead of "detach_from_camera".
But the object doesn't work perfectly when the camera goes out of sight, making the object not go to the desired place.
> Make the character "blink".
Do you know when you are hit by an enemy and the player sprite starts blinking? I could not find an easy way to replicate that.
>Recriating a bitmap font.
Couldn't find a way to make the "I" closer to the other letters.
> More easy acess to do physics similar to other types of platform.
This is a little harder to explain, but as you can see from the gif above, I tried to recreate a faithful version of Crash Bandicoot in 2D.
I had to create a new script for walking commands, but as a consequence, springs and slopes have lost their actions.
It would be super cool to have some moviment templates based on other games in the engine. I believe that Open Surge could be the main source in creating any kind of platform, without limiting itselft to Sonic's physics. smile

With all that said, I thank you very much for the simplicity that this engine has.
It was super easy to learn how to use it and that's what introduced me to programming, I'm looking forward to SurgeScript! big_smile

EDIT: Forgot to mention, but alpha channels and overlay effects would be very welcome too! This combined with the custom resolution creates an option to make a totally hand-drawn game!


(10 replies, posted in General)

aronthehedgehog wrote:

So how many characters in one scene? 4?

The original plan was to put every possible character combination in the same scene, and "activate" them depending on the selection.
In this case, 6 characters were planned, this would give a total of 24 characters out of scene, and you could select 4 of them.
But it was only a concept.

KZR wrote:

Ah the multiplayer hack, man it's been a while... I just followed Alexandre's instructions, all I really did was compiling the executable

That should be made official, by the way.

Indeed, it's handy and fun to use. Multiplayer platform games are kinda rare, imagine the possibilities that this hability will bring in the future. smile

Ah, thanks to everyone who sent me suggestions.
The Wild Card method was the most effective, and is less complicated than it sounds.
For those who want to see, I quickly did a short demonstration video. You also can see a temporary camera script I'm using.


(Not shown in the video, but if you progress the level without selecting a character, he doesnt appear on the scene, leaving the second player neon alone)


(10 replies, posted in General)

So, for those who want to achieve a similar result, I bring an update for you.
Luckily, I programmed a functional character selection screen.

However, my first hypothesis failed.

Me wrote:

What I had in mind at the beginning, would put all the characters at the same stage out of camera range, making a script to activate them in battle.
But taking into account the amount of characters, this won’t cause a slowdown?

(Yes, I'm using an KZR's older build. Thank you for making this possible smile )

I will try the "Wild card" method that you all suggested, it seems difficult, but it seems to be the only functional at the time.
It might help if the "lvl" files could read variables, but it's not like I can change the build now.


(10 replies, posted in General)

Alexandre wrote:

A famous computer scientist once said that "premature optimization is the root of all evil".

So I'd suggest that, at least for now, skip the optimization phase, prototype the fighting mechanism with all the characters on the stage and see if it works out for you.

A possible optimization consists in loading, say, 4 wildcard characters in the level. Each wildcard becomes an actual character due to a script that controls the animations (for inspiration, see: Follow the leader). In this way, you only have 4 characters, even though you provide the illusion of more. Got it? wink

That's a great tip! big_smile
Thanks, I'll focus more on the fighting mechanism for now. smile

Alexandre wrote:

by the way, race, is your e-mail address larryotexugo still active today?

Yeah, it's the one that's linked to my phone also.


(10 replies, posted in General)

Hello everybody. I'm starting to work on a little experimental project using Open Surge Engine.
I want to create a fighting mechanism based on Super Smash Bros. as a game with easy access to movesets and stage editor.
However, there is a huge problem on my way.
What would be the most effective way to "load" different characters in the same stage?

What I had in mind at the beginning, would put all the characters at the same stage out of camera range, making a script to activate them in battle.
But taking into account the amount of characters, this won’t cause a slowdown?

If anyone has a more affordable method, I would be grateful to hear. smile


(32 replies, posted in General)

Alexandre wrote:

Your skills have certainly improved.

As you're excited about the art, what do you thinking about working both on the sprites and on the level art? I can even pay you a little bit. smile

Sure thing! smile
I'm actually working on a mockup of what could be a possible new direction in the artstyle, trying to keep the same feel of the original.


(32 replies, posted in General)

I have to say, I'm very excited to get back to work on this project!
A lot has happened to me in those three years, my art has grown so much. Looking back there is so much that I want to remake it, but first comes the priority! big_smile
I can't wait for everyone to get in their places and come back to produce as if it were 2012.



(83 replies, posted in Game assets)



(83 replies, posted in Game assets)

Last frame:



Now,it's just need a background for the big pixel arts smile


(83 replies, posted in Game assets)



(83 replies, posted in Game assets)


I didn't realize it.
I'll fix it.





(83 replies, posted in Game assets)

Surge is Finished! lol



Now is need a new background...


(83 replies, posted in Game assets)


Except that the sprites are moving left and right... neutral


(83 replies, posted in Game assets)

*sonicvoiceon* Hey guys!Long time no see! *sonicvoiceoff*
Sorry, I was making a trip, so I could not finish the animation.

So,here's another preview:



(83 replies, posted in Game assets)

I made this little animation (unfinished) for the "... Fine,let's meet up at the waterfall [...]"



(10 replies, posted in Off-topic)

It looks better,KZR.
But, still has some problems ...




(10 replies, posted in Off-topic)