You are not logged in.
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.
Offline
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
https://discord.gg/w8JqM7m ---> Open Surge's Discord server
Offline
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.
Offline
but what if multiple instances exist on screen? they would all want to access the same globals I think
https://discord.gg/w8JqM7m ---> Open Surge's Discord server
Offline
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.
Offline
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:
Creating and Editing Sprites.
Offline
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.
https://discord.gg/w8JqM7m ---> Open Surge's Discord server
Offline
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
Creating and Editing Sprites.
Offline
you don't need to sacrifice those elements. you just have to build the system differently.
maybe those could work as separate objects?
https://discord.gg/w8JqM7m ---> Open Surge's Discord server
Offline
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?
maybe those could work as separate objects?
Good idea.
Offline
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.
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.
Creating and Editing Sprites.
Offline
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.
Offline
Making a programming language is no easy task. The progress on the project is not graphical and, sometimes, not easily conveyed (although you can follow the project on github). That said, I decided to communicate more often about our latest developments, so you can see how we're moving and provide feedback that may influence further developments.
This is what you can expect:
Language design
SurgeScript is a programming language designed to address specific needs of game development and interactive apps creation. It is lightweight and has a C-like syntax. Originally built for the Open Surge Engine, it is easy and fun to use, yet powerful enough for experts. It may be embedded into any C project.
Main features:
- Object oriented programming language: SurgeScript allows users to write code for discrete entities called "objects". Unlike other languages on the market, SurgeScript embeds a state machine within the objects. This is very helpful for game development, making things really easy for developers.
- Component-based approach: users can create complex objects and behaviors by means of composition. While one object may describe a physical entity on your game, another may describe a behavior that can be attached to game objects. Users may compose those. Unlike other languages on the market, there is no inheritance. SurgeScript favors composition over inheritance.
- Object design: objects define a set of variables, states and functions. Variables may be modified from within the objects themselves. Only one state may be active at any given time. Functions are exposed to the outer world, and any object may call exposed functions.
- Objects do not mess with each others' internals: this is a golden rule. In order to promote low coupling and high cohesion, SurgeScript asks users to define an API for each object. The internals of an object may only be modified through API calls, or from the objects themselves.
- Built-in hierarchy: unlike other languages on the market, SurgeScript features a built-in parent-child hierarchy for the objects. Objects may be created at anytime (during runtime) and are subject to this hierarchy. This is a know pattern on the computer graphics world and it is very useful for developing games and creating interactive apps.
- Type system: SurgeScript is a dynamically typed language. Five basic types are available: string, number, boolean, object and null.
- C-like syntax: constructions like if, while, variable assignments, function calls and so on are all available.
- Automatic garbage collection: unneeded (unreachable) objects are automatically discarded from memory.
More news coming soon.
Offline
While SurgeScript is not yet integrated into the engine, you can test features of the language with this alpha build (May, 2017).
In order to test it, please go to:
https://github.com/alemart/surgescript
and follow the instructions.
Four examples are available:
examples/hello.ss
A simple Hello World application.
examples/type_a_number.ss
A simple script that asks the user to type a number.
examples/alfred_the_npc.ss (check this out)
Talk to Alfred, the NPC. This script shows lots of features of the language.
examples/unit_testing.ss
Tests features of the language.
All examples work in text mode (for now). Soon the language will be integrated into the engine.
Enjoy!
Offline
this looks awesome! I'm anxious for the integration
https://discord.gg/w8JqM7m ---> Open Surge's Discord server
Offline
You can now tag your objects to facilitate development. For example,
object "Banana"
{
tag "Pickup";
tag "Fruit";
state "main"
{
}
}
This means that "Banana" is both a Pickup and a Fruit. You can check if an object has a certain tag like:
obj = spawn("Banana");
if(obj.hasTag("Pickup"))
Console.print("The object is a pickup.");
else
Console.print("The object is not a pickup.");
See the complete example here:
examples/tags.ss
Tagging is exceedingly useful in game development and it has now been natively incorporated into the language.
Offline
SurgeScript has built-in support for arrays. They are easy to use and can hold anything you like: numbers, strings, or even arbitrary objects! (among other things)
Here's an example for your delight:
// will display all elements of the array
object "Application"
{
arr = [0, 1, 1, 2, 3, 5, 8, 13, 21, 34];
state "main"
{
Console.print("The array has " + arr.length() + " elements.");
// i is an index
for(i in arr) {
Console.print(arr[i]);
}
Application.exit();
}
}
Additionally, SurgeScript also has support for what is known as "fast-loops" on the old engine. You can use while and for loops within a state. Unlike the old engine, SurgeScript has a much cleaner syntax:
// the following will count from 1 to 10
object "Application"
{
state "main"
{
// x will go from 1 to 10
for(x = 1; x <= 10; x++) {
Console.print(x);
}
// done!
Application.exit();
}
}
See all examples on:
https://github.com/alemart/surgescript/ … /examples/
Offline
Alexandre, I have been checking SurgeScript and it looks AWESOME.
It really combines the power of a real programming language with the easy things of the state machine. In my opinion, it is a very good add-on for allowing the user to create content and scripting in a easy-yet-powerful way.
Cannot wait to see it working in Open Surge I only have one question. For now, if I want to use the language I have to compile it from the sources in GitHub. Is it going to be this way also for Open Surge? Windows users could have a hard-time compiling it. I think the best thing would be to have everything compiled and ready for Windows users. I'm currently one of them, but not for a long time
Piece of cake...!
Offline
Alexandre, I have been checking SurgeScript and it looks AWESOME.
Thank you It is awesome!
I only have one question. For now, if I want to use the language I have to compile it from the sources in GitHub. Is it going to be this way also for Open Surge?
SurgeScript will work out-of-the-box. Simplicity for everyone!
Offline
SurgeScript will work out-of-the-box. Simplicity for everyone!
That is music to my ears. Please keep us updated!
Piece of cake...!
Offline
Alexandre wrote:SurgeScript will work out-of-the-box. Simplicity for everyone!
That is music to my ears. Please keep us updated!
LOL... me too
Offline
SurgeScript now features a Tag System
so this is the much requested object categorization/object families?
please tell me that after this we get hardware acceleration
https://discord.gg/w8JqM7m ---> Open Surge's Discord server
Offline
I said earlier that SurgeScript would enable a very easy way to make objects attached to each other (so that they follow each other). Let's see how it works.
One can spawn a child on any object. You can change the position of any object by changing its Transform2D component. All children will move accordingly. This means: the children are already attached!
The Transform2D component can be made available on any object; all you have to do is spawn it on the object of your choosing. A component is just another object.
On the demo below, we have two bees: the parent bee and the child bee. Each bee has its own Transform2D component, so we can move them individually. Wherever the parent moves, the child follows. However, the child may move without affecting the parent.
# ATTACHED OBJECTS
# Wherever the parent goes, the child follows.
step 1: both bees start at the origin (0,0)
The parent bee is at (0,0)
The child bee is at (0,0)
step 2: move the parent bee by (2,0) relative to its parent (the Application)
The parent bee is at (2,0)
The child bee is at (2,0)
step 3: move the parent bee by (0,1)
The parent bee is at (2,1)
The child bee is at (2,1)
step 4: set the child bee to be at (5,6) relative to its parent (the parent bee)
The parent bee is at (2,1)
The child bee is at (7,7)
step 5: move the parent bee by (-2,-1)
The parent bee is at (0,0)
The child bee is at (5,6)
step 6: rotate the parent bee by 90 degrees
The parent bee is at (0,0)
The child bee is at (-6,5.000000)
step 7: scale the transform of the parent bee by 10
The parent bee is at (0,0)
The child bee is at (-60.000004,49.999996)
step 8: move the child bee by (2,0)
The parent bee is at (0,0)
The child bee is at (-60.000004,70)
step 9: scale the transform of the parent bee by 0.1 (thus reverting the previous scale)
The parent bee is at (0,0)
The child bee is at (-6.000000,7.000000)
step 10: move the child bee by (-2,0)
The parent bee is at (0,0)
The child bee is at (-6,5.000000)
step 11: reset the rotation of the parent bee
The parent bee is at (0,0)
The child bee is at (5,6)
step 12: set the child bee to be at position (50,50) in the world
The parent bee is at (0,0)
The child bee is at (50,50)
How does it work?
Offline
SurgeScript is truly awesome. It can now handle more complex data structures such as Dictionaries. You can store arbitrary data in a Dictionary. As usual, you'll find fresh code on GitHub.
object "Application"
{
// a Dictionary is a set of (key, value) elements
weight = spawn("Dictionary");
// main state
state "main"
{
// set up some weights ("weight" as in everyday use, that is)
weight["Surge"] = 35.0;
weight["Neon"] = 25.0;
weight["Charge"] = 37.5;
// print the weights
Console.print("Surge weighs " + weight["Surge"] + " kg.");
Console.print("Neon weighs " + weight["Neon"] + " kg.");
Console.print("Charge weighs " + weight["Charge"] + " kg.");
// sum up
totalWeight = computeTotalWeight();
Console.print("Together, they set up a total of " + totalWeight + " kg.");
// done!
Application.exit();
}
// this function will add all weights stored in the Dictionary.
fun computeTotalWeight()
{
sum = 0.0;
it = weight.iterator();
while(it.hasNext()) {
sum += weight[it.item];
it.next();
}
return sum;
}
}
The result is:
Surge weighs 35 kg.
Neon weighs 25 kg.
Charge weighs 37.500000 kg.
Together, they set up a total of 97.500000 kg.
ps: for those who had never heard the term "iterator", check out https://en.wikipedia.org/wiki/Iterator
Offline
One of the most useful commands of the old API was on_timeout. Basically, it allowed to change the state of an object after a number of seconds passed. The same functionality can be achieved today in SurgeScript using timeout():
object "Application"
{
state "main"
{
Console.print("Now on the main state. Please wait 4 seconds...");
state = "wait1";
}
state "wait1"
{
if(timeout(4.0)) // will wait 4 seconds to change the state
state = "cool";
}
state "cool"
{
Console.print("Cool! Now wait for more 8 seconds...");
state = "wait2";
}
state "wait2"
{
if(timeout(8.0))
state = "done";
}
state "done"
{
Console.print("You're done!");
Application.exit();
}
}
Offline