Topic: Introducing surgescript [released!]

EDIT: SurgeScript v0.5.0 is released! Get it at https://alemart.github.io/surgescript wink

https://github.com/alemart/surgescript/raw/master/docs/img/opensurge.png

First of all,

Happy New Year!

I'd like to introduce a new project I've been working on, SurgeScript.

The current scripting system allows modders to explore their creativity endlessly. It's really exciting to have your own ideas turned into reality with this engine. I envision a lot of work for this engine, especially mod-wise. Still, there are some things that can be improved with the current scripting system.

Global variables can make behaviors unpredictable. Changing states to make loops is a difficulty also. Object communication is not ideal, since it relies on changing states of other objects. The math is limited, and the syntax can get difficult to read. Given the current limitations of the language, and the immense potential the engine holds, I decided that it's time to improve all this, rather sooner than later.

The new language retains some of the easy-to-use features of the old one, while adding some powerful constructs of more traditional ones.

- Objects will have a clean interface
- Objects talk to each other using APIs
- Common programming structures such as if, while...
- Retains the object states feature (state machines)
- No more globals. No messy stuff.
- Great Math
- among other things

Very powerful stuff!

https://github.com/alemart/surgescript

It's still a work in progress.
More on it soon...

Last edited by Alexandre (2018-04-15 23:59:48)

Re: Introducing surgescript [released!]

Nice to hear that.

I'm now studying computer science and learned C and Java. Making a compiler is too far from my current learning stage, so I'm impressed with your work.

Keep going and please update the main page of the site, not with the one I did a lot of time ago, but at least change it to reflect the current state of the engine.

Edit: And now I see you're using GitHub, you plan to move the game into it?

Last edited by lainz (2017-01-05 21:03:08)

Re: Introducing surgescript [released!]

Hey lainz, welcome back!

lainz wrote:

Edit: And now I see you're using GitHub, you plan to move the game into it?

I do. smile

Re: Introducing surgescript [released!]

Ok, is a good place to share code. You can even create an organization and put a lot of repositories together.

Edit: I made the organization and sent you to join, I'm trying to import the source with all the commit history.
Edit2: The import is done with all commit history available now on GitHub.

Last edited by lainz (2017-01-14 13:17:32)

Re: Introducing surgescript [released!]

Moving the repos to GitHub is a good idea. Maybe it is possible to find more coders able to add features to the game there.

Also, the Surge Script thing looks very promising. I want to see more of it soon!
I love the state-machine way for the objects, in my opinion is very intuitive for non-programmers. I hope the new script will be able to get the best of the SM concept with more general programming tools.

Also, a way to inter-change communication between levels would be nice.

Piece of cake...!

Re: Introducing surgescript [released!]

SurgeScript looks like it has great potential.
I look forward to hearing about future developments.

-- svgmovement

Re: Introducing surgescript [released!]

Hey guys, here are some news:

Over the past month, I've been working on the SurgeScript Runtime Engine. It's what will give life to future scripts.

The Runtime Engine works purely based on objects. Imagine there is a collection of objects hanging around. These objects have their own inner state (memory, data, and so on) and they can handle themselves. Objects talk to each other using function calls.

Instead of having engine-provided API calls (like you have now, ie, add_to_score, set_player_xspeed, and so on), you'll talk to objects which will handle those things. Additionally, you'll be able to easily extend the built-in functionalities by creating your own objects.

The new system follows a Component-based approach. This means you'll build your objects like LEGO blocks. You start with a blank object that does nothing, and then you configure it. Eg, want to create a level enemy that walks around and attacks the player whenever it's touched? Simple! Add a LevelObject component to make it visible, with an animation, position, and everything. Then, add a Walk component to make it walk. Finally, add an Enemy component to make it dangerous. Open Surge will bring some built-in components. Still, you'll also be able to develop your own.

Components are just objects, and they know to which object they are attached to. In software engineering terms, we say that SurgeScript favors composition over inheritance.

I'm planning long ahead, so I'm building this powerful tool for modders. My long term vision is this: Open Surge is a reference for building 360 platformers. Moddable, open-source and a great game itself. Projects that share similar goals include: MUGEN for fighting games, OpenBOR for beat-n-ups. Taking a more philosophical stand, I say this: Open Surge empowers people to make their own dreams a reality.

Now I'll be working on a compiler. It will convert user-made scripts into things that can be executed by the Runtime Engine. Something like nanoparser, but way more powerful.

Re: Introducing surgescript [released!]

Like Unity does. Everything in Unity is a Game Object, then you can attach to it scripts, that can be as you said Walk, Enemy, and more, like the graphics (2d or 3d), Physics, and so on. Even the camera is a game object.

Re: Introducing surgescript [released!]

Hey Alexandre,

It would be wonderful if you keep us up-to-date with the news of Surge Script. Do you have any idea of when will be it ready and integrated into Open Surge?

Also, I wonder what happens then with the Allegro 5/mobile stuff you were working on a while ago.

Thanks for the info!

Piece of cake...!

Re: Introducing surgescript [released!]

Hi TheSeventhEmerald,

Thank you for your interest in the project. I don't have exact dates, though this year we'll see many further developments of the game.

Regarding SurgeScript, the project has 3 main parts: the Runtime Engine, the Compiler and their integration into the game.

The Runtime Engine is at the basis, responsible for making the whole thing work. It is almost finished by now, though some more testing is necessary. You can see the most recent commits on GitHub. You can already run code there, but for now it's machine code and not for end users.

The Compiler is responsible for translating user-made scripts into code that is run by the runtime engine. I'm beginning this step. The scripting language will follow a C-like syntax. It will be object-oriented and optimized for Open Surge. As I explained in the first post, things that are a pain in the old language will be much improved in the new one. SurgeScript has truly much potential.

The integration into the game comes later. Before all that, there had been a planning phase where I took some design decisions based on use-cases, previous knowledge and past experiences. The fact that the language is object-oriented is an example. The fact that objects communicate through user-defined APIs, is another.

By the way, if you guys have any feedback related to the old scripting system (the good and the bad), it would be great to hear it smile

11

Re: Introducing surgescript [released!]

Glad to see things moving smile

Regarding the old scripting system I have quite a few things to say. most are indeed related to scripting, others to some things I found in the engine that I believe could be changed for the best.

So, first off we have this: The scripting API is very simple to learn, and allows beginners to quickly implement behaviors into objects in the game. Though simple, it offers also more advanced features like fast loops (which NOTE: will most likely freeze your computer if you don't know what you're doing roll ), retrieving data through internal functions and allowing you to create your own functions with the execute command! It's marvelous, I mean it! Though if I am honest, the engine could be improved and offer users more real-time control of some things.

  • Allowing private variables to be set per instance, in the editor and through scripting

Using parent/child relations to take care of this is exhausting. Why not let the engine assign one ID to each object and display it in the editor? Maybe even showing a little info on mouse hover. maybe the mouse could behave a bit differently, as in today you have modes for group, brick, object and built in objects. how about an "info" mode where you can only click objects to edit their starting properties (variables)?

  • some nitpicks and annoyances

Collision rectangle for the player is hard coded, noticeable in interaction between player and bricks. no matter how big the sprite, the collider fits into a small gap. if the sprite is smaller than this collider, it causes the player sprite to apparently collide with something it is not touching, when in reality the physics collider is doing this.

Background visible in editor, if possible let us set its parameters and load/save BG and BRK from there smile

The possibility to build a brickset just by loading separate images for each brick. maybe a separate tool.

characters should be allowed to stop on slopes. depending on what the creator is trying to do, this might be blessing or damnation. in my case, since i'm not focusing on sonic fangames or games inspired by sonic, it's a damnation. if this could be defined through scripting it would be perfect. you could do anything from slippery ice to spider man cool

it would be nice to have the sonic physics affect every objects using the "gravity" command, because objects don't know how to go over a slope without some workarounds like a "while" loop in the object's script constantly pushing the object up when it overlaps a floor brick.

creating local multiplayer games shouldn't be so hard and require so much working around. I'm not sure how to tackle this, but something like "set_controller playerX" rather than the usual "observe player" and "set_inputmap" BUT don't remove the latter, as it allows for so much more, like objects that manage extra controls or hotkeys.

that's all i can report for now. if I find something new I'll keep you posted smile

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

Re: Introducing surgescript [released!]

hey KZR, thank you for the feedback smile

KZR wrote:

The scripting API is very simple to learn, and allows beginners to quickly implement behaviors into objects in the game. Though simple, it offers also more advanced features like fast loops (which NOTE: will most likely freeze your computer if you don't know what you're doing roll ), retrieving data through internal functions and allowing you to create your own functions with the execute command! It's marvelous, I mean it! Though if I am honest, the engine could be improved and offer users more real-time control of some things.

Great! I plan to maintain this simplicity, while at the same time adding more powerful constructions. I think the state machines really keep things simple when creating new objects. We'll keep the state machines, and we'll have a built-in method for creating functions. Like this:

// this is your object
object "NPC"
{
    ...

    fun talk(text)
    {
        ...
    }
}

// and then, somewhere else,
npc.talk("Hello, ma'am!");
KZR wrote:

how about an "info" mode where you can only click objects to edit their starting properties (variables)?

so, you mean that you can attribute some data to individual objects through the editor? That would be very useful indeed. smile

KZR wrote:

Collision rectangle for the player is hard coded, noticeable in interaction between player and bricks. no matter how big the sprite, the collider fits into a small gap. if the sprite is smaller than this collider, it causes the player sprite to apparently collide with something it is not touching, when in reality the physics collider is doing this.

yeah, when I was developing the physics engine, I remember setting up the collision box very carefully, so it wouldn't fuck up things. But this could be configurable, for sure.

KZR wrote:

characters should be allowed to stop on slopes. depending on what the creator is trying to do, this might be blessing or damnation. in my case, since i'm not focusing on sonic fangames or games inspired by sonic, it's a damnation. if this could be defined through scripting it would be perfect. you could do anything from slippery ice to spider man cool

I think if you mess with the slope coefficients in the character/.chr files, you can improve this. Try setting the coefficients to, say, zero.

KZR wrote:

it would be nice to have the sonic physics affect every objects using the "gravity" command, because objects don't know how to go over a slope without some workarounds like a "while" loop in the object's script constantly pushing the object up when it overlaps a floor brick.

'gravity' is a remanescent from 0.1.4. It's obsolete. There will be better ways to do it in SurgeScript. Imagine attaching an object called "Gravity" to your NPC, and then it falls down!

KZR wrote:

creating local multiplayer games shouldn't be so hard and require so much working around. I'm not sure how to tackle this, but something like "set_controller playerX" rather than the usual "observe player" and "set_inputmap" BUT don't remove the latter, as it allows for so much more, like objects that manage extra controls or hotkeys.

that's all i can report for now. if I find something new I'll keep you posted smile

yeah, and how about multiplayer games over the web? cool

thank you for the precious feedback!

Re: Introducing surgescript [released!]

I am going to give you also my feedback in the things.

-- One of the biggest problems with the old API was the scope of variables. For example, I thought once to make a game with different routes. Also I tried to implement special stages/emerald collection. Though the first two can be done workarounding a lot with the load_level thing, I found no solution for the emeralds. I think there is no way to say to game, "Hey, write this variable, and KEEP IT, even when I quit the game and enter again".
In my opinion this is one of the easiest things to fix with an object-oriented engine. There should be an object dedicated to save/load permanent data, in a fashion of Android or other game engines. I don't know the new syntax but I imagine something like this:

object "end_level_sign"
{ 
       fun apply_end()  //Called when the player touches the sign
       {
                  IOhelper ioh();
                  ioh.write_var(int, "Rings", get_current_amount_rings()) 
                  //Creates a var, with name "Rings", of tipe integer, and we assign the number of rings to it.

                  float space_walked = ioh.read_var("Km") //Reads the value of the existing variable "Km"
                  //Edit the variable Km:
                  ioh.edit_var("Km", space_walked + get_km_walked_in_this_level() ); 

                  ioh.flush() //Write all data to savefile and closes it
       }
 
}

In this code you can see how I save, for later use, the number of rings at the end of the level. Also, you can see how can I get again the value of stored variable and edit it in memory. This allow me to keep track, in this particular example, on the amount of space travelled by the player... in the whole game!
There is a lot of possibilities to a complete save/load engine to store custom variables. Want to include non-linear level routes? No problem! RPG equipment and statistics? Easy to do!

Finally it would be good to do this not from scratch, but using something like XML, so we could, for example, store information of an object as sub-items of a big item, to maintein all the info organized.

-- KZR suggestion about editing variables of objects is very good in my opinion. I think that he is pointing out something like this:


object simple_enemy
{
    speed = 2.0;
    able_to_jump = true;
    hp = 3;
}

So now imagine you go to editor and create three of this objects. They, of course, are going to have the same characteristics. But you now can enter into "Properties mode" and when you click a guy, you can see the properties and edit them individually.

Of course, with this concept also privacy should be implemented, so public variables can be seen and edited in Properties Mode, but not private ones. If you want to modify a private variable of certain object, then it should be done in-code using getters/setters for safety.

-- About the thing of collision boxes, now they would be a private variable of every object, so you can modify it changing the value in the player object source file.  In addition to that, player characteristics should be properties of the player object, so they can be modified by objects, accesing the values in-code as I suggested. That can give us new exciting objects, such as a shoe that modifies your speed to a... Oh wait tongue Talking seriously, imagine objects that change for a time your jump height, the slope, the gravity (do you want to make that cool effect of reversing gravity?), or even that change the action triggered by the double jump.  New universe of possibilities!

-- Finally, as KZR also pointed out and as I have said in many topics, after finishing this GREAT new code the effort should focus in applications to deal with the creation of bricksets and sprites, as well as a level editor with enhanced capabilities. Putting all the blocks one by one is painful xD  Group creation should be even easier with the object concept, but still it is important to make easier level creation. And also the time needed to get bricksets and backgrounds working is horrible. Making this easy we would attract more people who simply wants to create their levels, and do not care about scripting new objects or items.

PS. Thanks for your message Alexandre. I hope to see new developments in this soon! Keep us up to date smile

Last edited by TheSeventhEmerald (2017-02-22 10:58:03)

Piece of cake...!

Re: Introducing surgescript [released!]

I like the ideas that I have seen so far. I would like to offer some suggestions also.

KZR wrote:

Allowing private variables to be set per instance, in the editor and through scripting

Using parent/child relations to take care of this is exhausting. Why not let the engine assign one ID to each object and display it in the editor?

The object ID thing could help with synchronizing objects during networked games, if that ever
becomes a possibility.


TheSeventhEmerald wrote:

There is a lot of possibilities to a complete save/load engine to store custom variables. Want to include non-linear level routes? No problem! RPG equipment and statistics? Easy to do!

Finally it would be good to do this not from scratch, but using something like XML, so we could, for example, store information of an object as sub-items of a big item, to maintein all the info organized.

JSON is an option for variable persistence that may be easier to use and develop than XML. Depending
on the use cases, either one is workable.

I look forward to hearing more about the progress of SurgeScript.

-- svgmovement

Re: Introducing surgescript [released!]

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.

Gameplay:
> When a player is moving up and he's pixels close to a platform, it kind of teleports him directly to the platform.
http://i67.tinypic.com/30cvzud.gif
(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.

Difficulties:
> 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.
Example:
http://i65.tinypic.com/ifwqon.gif
> 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.
http://image.prntscr.com/image/e2e7a9dfbfd347e7b4c3059a073af3d0.png
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!

Last edited by Race the Hedgehog (2017-02-23 04:56:24)

PunBB bbcode test
Creating and Editing Sprites.

Re: Introducing surgescript [released!]

Thank you TheSeventhEmerald, svgmovement and Race for the rich feedback. smile

Race the Hedgehog wrote:

I also recommend using (424x240) as the default resolution for a more "modern" touch.

Good idea, so we'd have a 16:9 aspect ratio.

Race the Hedgehog wrote:

>Recriating a bitmap font.
Couldn't find a way to make the "I" closer to the other letters.

You need .ttf for that.

--

More news coming soon. If you guys have more feedback, I'd be glad to hear them.

ps: it'd be great to hear your thoughts about brick development. What's the ideal way of creating bricks? creatorsonic83 uses 1 brick per image file (as far as I know). Can you guys tackle this problem and implement a solution? It's a question for me too.

17

Re: Introducing surgescript [released!]

so many great ideas big_smile

here's some more

picking entities from a bar or floating window

a menu, bar or window tracking variables for easy access and debugging

object families sharing  variables  across objects, and allowing  things like on_ collision "family"

in properties mode, show a family tree for objects with parents or children and let them be selected from there for debugging purposes

make functions that  for example check for bricks at an offset take  object angle into account or not, through an optional switch in the functions.

along with the upcoming load/save system and corresponding commands, a built-in save point like the checkpoints would be nice for those not wanting to manage their own systems.

again, per player variables defined in their .chr scripts . for open surge would mean things like individual ring counters, scope and duration of player abilities and so on. for mods the possibilities are endless.

that's all for now. I'll find some more wink

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

18

Re: Introducing surgescript [released!]

I also ran into a couple issues

depending on local definitions, the decimal separator is either a comma or a dot. in some systems,where the comma is the default decimal separator, variables with decimal values are taken as integer rather than float. this is especially noticeable with values defined in chr files.

another thing is, after updating the exe on a project built under an older revision, some scripts cause a crash to desktop. I was able to isolate the offenders, but not to figure out what's wrong with them. and I'm not talking about migrating from open sonic to open surge, but rather between different revisions of open surge.

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

Re: Introducing surgescript [released!]

KZR wrote:

depending on local definitions, the decimal separator is either a comma or a dot. in some systems,where the comma is the default decimal separator, variables with decimal values are taken as integer rather than float. this is especially noticeable with values defined in chr files.

Very nicely thought of, thanks for reporting. smile

Thank you for your suggestions.

20

Re: Introducing surgescript [released!]

in the past I suggested mouse input in-game

one thing that strikes me , is that the current input system only supports legacy usb gamepads and up to 8 buttons per pad.
I think it would make sense to support Xbox360 and ps3 controllers, or at the very least, support legacy analog 12 button controllers, the ones similar to a PlayStation or Xbox controllers.

to open surge this means a fine control over the player's speed. to modders maybe a whole lot more.

is this feasible?

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

Re: Introducing surgescript [released!]

With the current engine (A4), I don't know.

Mouse support is feasible, though.

22

Re: Introducing surgescript [released!]

analog controls are not a must but I suppose that could be done in the migration to A5

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

23

Re: Introducing surgescript [released!]

another thing that strikes  me over and over is the way collisions are handled on sprites. while it works good with small and simple sprites, bigger and more complex sprites register collisions at points that even though they are opaque pixels, they are not the core.
just imagine that your sprite has an item  in their hands and an enemy can hurt him by touching only the item. makes no sense .

if we could load a collision mask, I mean an image of the same size as the original sprite sheet but it would have only the parts of the sprite that accept collisions, that would let us have fine control over collisions, without the need to change how collisions work.

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png

Re: Introducing surgescript [released!]

KZR wrote:

another thing that strikes  me over and over is the way collisions are handled on sprites. while it works good with small and simple sprites, bigger and more complex sprites register collisions at points that even though they are opaque pixels, they are not the core.
just imagine that your sprite has an item  in their hands and an enemy can hurt him by touching only the item. makes no sense .

if we could load a collision mask, I mean an image of the same size as the original sprite sheet but it would have only the parts of the sprite that accept collisions, that would let us have fine control over collisions, without the need to change how collisions work.

Have you ever tried using collision boxes? 2D fighting games do that.

By using boxes, you can define which points are vulnerable and which points aren't.

25

Re: Introducing surgescript [released!]

I use collision boxes and masks extensively. problem is,  you can't attach an object to another object, only to the player.

do you remember the last screenshots I posted? one of them had this big rat with a club. we will use it to explain my point, as it is the best example I have.

because I can not make its weapon an attachment, it has to be a part of the sprite. if I attack and hit the weapon it gets hurt. if the weapon touches a wall, platform physics trigger a wall collision and stop movement in that direction.

still on platform physics, if any sprite which is meant to move on the floor gets a strange shape computed from its opaque pixels, weirdness ensues. from the shaky walking to clipping through solids.

automatic collision management is a great thing, don't get me wrong! however there are moments where a simple shape is enough to handle physics and interactions and that's where it's useful being able to assign a graphic to it, or maybe in the spr file have an option to apply a simple collision shape and set its size.

something like

rectangle_collision 0 0 32 32
ellipse_collision. -16 -8 16 8

or

mask_collision images/collision.png

Last edited by KZR (2017-04-04 05:45:12)

https://image.ibb.co/kuSYrm/SD_sml.pnghttps://image.ibb.co/kHq8P6/SeD_sml.pnghttps://image.ibb.co/cJf8P6/LTot_W_sml.png