51

(1 replies, posted in MODs)

it's nice man, but you could design your own levels.

KZR wrote:

Meanwhile, how do I get started with replacing the routines?

Well, that's the challenge.

You'd need to know C and the graphical API of your preference. I don't know which graphical API you would use, so you'd need to study that. If you decide to do it, I can guide you through the specific routines of Open Surge (what they do, and so on). Then you could replace the graphics module and let Allegro do the rest (input, and so on).

man, that's really cool.

One of the things you could try, if it suits you, is to replace the rendering routines by accelerated ones on core/video.c and core/image.c. While accelerated routines don't get implemented officially, perhaps you could maintain your own parallel build of the engine, thus benefiting everybody. We could give you support.

hey, let us see some screenshots!

55

(61 replies, posted in General)

Race the Hedgehog wrote:

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.

Well, you could use the old API and it will still work. The thing is, the new API won't interact with the old one.

56

(6 replies, posted in MODs)

ah, I see it. Can you reproduce the issue on a clean version of the engine and send me the files?

57

(61 replies, posted in General)

Race the Hedgehog wrote:

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.

Are you changing the animation via scripting?

KZR wrote:

maybe those could work as separate objects?

Good idea.

58

(6 replies, posted in MODs)

Great! I don't really understand what you mean regarding the animation. What is it about?

59

(61 replies, posted in General)

KZR wrote:

but what if multiple instances exist on screen? they would all want to access the same globals I think

they could access the same globals, but at different moments in time.

everything you need will be stored locally.

60

(61 replies, posted in General)

KZR wrote:

In the old one, you have to change states and pass the position of the parent back and forth.

exactly. the problem with that approach is that the object can not have more than one instance per level, or they will overwrite each other's position globals.

second option is to copy some behaviors from the collider to the actor and sync states, but it appears there is a small delay when passing state changes over the hierarchy. one frame maybe more

Use change_child_state combined with return_to_previous_state. In the child, copy the globals passed as parameters to local variables. The of passage of variables happen instantly with this method. The globals are just temporary holders; they do not store anything you absolutely need for an object.

No need to copy behaviors.

61

(61 replies, posted in General)

KZR wrote:

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

You can. In the new engine, that will be fairly simple to do. In the old one, you have to change states and pass the position of the parent back and forth.

You could make your rat be a ball or a box. That will be your collider. Then, on top of your collider, you place a rat skin. That skin can take any shape whatsover, and it does not affect collisions in any way. This is somewhat like the component approach mentioned earlier on this thread.

It's good that you mentioned this. It will help us address this challenge on the new engine. In fact, this is one of the strengths of the new engine. It's a new way of thinking, compared to the old API.

62

(61 replies, posted in General)

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.

63

(6 replies, posted in MODs)

hey KZR,

First of all, welcome back wink

It's clear how much you have evolved since you started.

We never meant to be a competitor for Construct. Our engine was originally built for Open Surge. Still, given that our engine (intentionally) provides so much space for creative expression, it's natural that it shows itself as a powerful tool for 2D game making - an excellent one, shall I say, especially for platformers.

The first evidence that you will see of the enhanced power of the Open Surge Engine is our new scripting system. After we develop SurgeScript, there will be a refactoring of the level editor. Namely, we want to bring new features and improved usability. A major engine update is also expected.

The approach you're taking on your game - develop something simple (yet not so simple) within a well-defined scope - is a wise one. I hope we can see new updates periodically.

great pics! wink

Hey EnderPreston, welcome smile

I almost couldn't load your website (took me awhile). You could try using opensurge for your next game; it's far more powerful.

Based on was shown in the video, how about designing your own levels from scratch? Modifying the graphics from the levels that come with 0.1.4 is a nice place to begin to learn how to mod the game. However, given that everyone here has already played 0.1.4, creating your own levels would be far more interesting.

That said, how did you find us?

65

(61 replies, posted in General)

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

Mouse support is feasible, though.

66

(61 replies, posted in General)

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.

67

(61 replies, posted in General)

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.

68

(61 replies, posted in General)

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!

69

(61 replies, posted in General)

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

70

(53 replies, posted in MODs)

hey, what a bunch of loops! loved it wink

are these sprites from sonic advance?

71

(2 replies, posted in General)

Hello kusanagi12, welcome!

We ask you to please use the English language.
See: Board Rules

Thank you smile

72

(53 replies, posted in MODs)

Hey creatorsonic, happy new year

I loved the parts where the characters run and roll really fast cool The foreground seems a bit off, though.

Given what you have made so far, can you tell us a little bit about your experience with the engine?

Keep up the good work wink

73

(12 replies, posted in Game assets)

I think more industrial works best, because we explore grass and similar elements in Sunshine Paradise.

A few years ago I visited Itaipu, a massive dam between Brazil and Paraguay.

https://c1.staticflickr.com/9/8818/17174796329_7e1320bd3d_c.jpg
Usina Hidroelétrica Itaipu Binacional / Itaipu Dam by Deni Williams, no Flickr

I visited the outside, and it looks like this:

https://upload.wikimedia.org/wikipedia/commons/thumb/3/3a/Itaipu_3285.jpg/768px-Itaipu_3285.jpg

Now, check the internals:

https://upload.wikimedia.org/wikipedia/commons/4/49/Itaipu_D%C3%A9cembre_2007_-_Int%C3%A9rieur_du_barrage.jpg

There are rocks and stuff, but they are more on the outside. Since Waterworks features all those sophisticated industrial gimmicks, I believe the focus of the level could be more on the inner part of the dam.

74

(12 replies, posted in Game assets)

Hey, that's really good.

Let me ask you a question: you imagined a rock in the backdrop. I initially had though Waterworks Zone would be a more "industrial" thing. What do you have in mind?

75

(61 replies, posted in General)

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.