(61 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


(61 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


(61 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:



(61 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.

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)




(83 replies, posted in Game assets)

I finished the waterfall:

I suggest we use a more blurred background to highlight Surge.Example:

Waterfall blurred:


(83 replies, posted in Game assets)

Ok,I'll make a biggest waterfall next time.

EDIT:I completely agree with the KZR's idea. big_smile


(83 replies, posted in Game assets)

Second background:



(83 replies, posted in Game assets)

Alexandre wrote:

I was wondering the same thing. The result will be very pixelated. Before we make a decision, what do you think of this: I could make a small experiment (ASAP) and script a quick test of the camera getting close to Surge using set_scale. By looking at the result, I think we'll be able to decide better, and then proceed with the art. What do you think?

I'll try my best to script this quick experiment today or tomorrow.

Ok. Now I'll start making the second scenario.


(83 replies, posted in Game assets)

Frame 8:


Sorry for double post, but I have a question:

For the next Surge's sprite will use the script "set_scale" or is for me do he big?