Sonic Scripting Language?

Hmm, while I suck with scripting, this may come in handy for man other people. Good work. I highly suggest you keep working at it.

 

While it seems a pretty interesting idea, there's something that bugs me. Why not instead of putting the effort on creating a script language for the objects, do an actual engine in C++ and then embed a script language there?

I'm pretty sure you know so well the structure of the Sonic engine so it would be possible to rewrite it in near no time, using a cross platform library as SDL. This way, shouldn't it be easier to overcome the limitations of the genesis, the hardness of learning assembly, and take further the possibilities for people to do "hacks"?

Something along the lines of what Saxman wanted to do at first, but real...

 

I don't think it is a good idea. First, I think ASM (unstructured language) is easier than a structured language (like yours looks to be). ASM is just bad explained for people. It isn't something hard to understand. Take the code below as an example:

Code (Text):

1.  move.l #1,d0   ; d0.l = 1
2.  move.l #3,d1   ; d1.l = 3
3.  add.l d1,d0     ; d0.l = d0.l + d1.l
4. Loop:
5.  bra.s Loop               ; Goto loop

That was hard to understand?

If you ask me, ASM is just like BASIC. The only difference is that you don't say "goto label" but "bra.s label".
Isn't BASIC easy?

Another thing is that people wouldn't be able to program stuff in MegaDrive except in Sonic Games. Learning ASM, you can edit ANYTHING in ANY MegaDrive ROM.

[EDIT]

I'm very thankful that your (drx) ASM guide exists.

 

I'm with Weird Person on this one - ASM was always an easier concept for me to grasp than other languages, and I'm sure a lot more people might be better off with ASM, should it be taught to them correctly. To be honest, that script confused me a bit more than the object itself. :P

I mean, I can make out what it does, yeah, but the syntax of scripting in general seems overcomplicated for such a simple thing... 23987432904723 tabs and needing your semicolon or whatnot in the exact place... ASM is much simpler, and it much more direct; "in your face." It makes it a lot easier to work with in the long run, IMO.

You do have an interesting concept, though... if you can find out some sort of way to make it simpler, and then make some sort of script -> ASM compiler, this may have a promising future. Still, this isn't ProSonic, nor is it Mettrix, or any other "fangame" engine... So I'd expect that ultimately, each is left best to their native coding environments. I do think you should try making it more user friendly in the future, though... I.E: Make custom scripting commands that compile into more complicated ASM routines, so stuff like bosses could be easier. That sorta thing. You know what I mean?

 

Awesome idea man. Like I said, I've been wanting to do this for ages, so if I can help too, it would be much appreciated.

I was thinking more of something like the language had it's own set of librarys, like for example, the object library:

Code (Text):

1. //===============================
2. //= sonic 1/2/3/k object script =
3. //===============================
4.  
5. object
6. {
7.     byte initialized;
8.     byte palLine;
9.     byte patterns[];
10.     byte mappings[];
11.     byte priority;
12.     word x, y, w, h;
13.    
14.     Init(coords, priority)
15.     {
16.         self.initialized = 1;
17.         self.x = coords.x;
18.         self.y = coords.y;
19.         self.w = coords.w;
20.         self.h = coords.h;
21.         self.priority = priority;
22.     }  
23.  
24.     Display()
25.     {
26.         //write code for display object in priority plane
27.         //at self.x & self.y with patterns, palette, and mappings
28.     }
29.  
30.     Behave()    //default behavior code
31.     {
32.     if (initialized = 1)
33.         self.display();
34.     }
35.  
36.     Delete()
37.     {
38.         //object deletion code
39.     }
40.    
41. }

You would program the objects by including the 'objects' library in your code:

Code (Text):

1. use objects                                //kind of like a library include
2.  
3. object rock
4. {
5.         patterns = 0x7A00;
6.         mappings = Map_ObjectRock;
7.         palLine = 2;
8.  
9.         Behave()    //rewrites default behavior code
10.         {
11.             self.Display();
12.        
13.             Register(self.x, 0);           //c++ equivilent to #define self.x d0
14.             self.x &= 0xFF80;
15.        
16.             word *foo = 0xF700;
17.             Register(foo, 1)               //c++ equivilent to #define foo d1
18.    
19.             foo -= 0x80;
20.             foo &= 0xFF80;     
21.             self.x -= foo;
22.  
23.             if (self.x > 0x280)
24.                 self.delete()          
25.  
26.             Deregister(self.x);         //c++ equivilent to #undef self.x
27.             Deregister(foo);               //c++ equivilent to #undef foo
28.         }
29. }
30.  
31. objects
32. {
33.     ghzRock1 = CreateObject(rock);
34.     ghzRock1.Init(10,10, 4, 3);
35.     //etc...
36. }

You would then run the script and get an asm output =P

The second file uses something like the equivilent of class inheritance in C++. This way when you program an object, it would already have some predefined functions such as 'Display' and 'Init'.

Another neat thing would be the 'Register' and 'Deregister' functions. Since math and other stuff is faster when using the registers, you would call 'Register' on your variable and one of the registers, do some math with your variable, then call 'Deregister' on your variable. It would work like the C++ preprocessor's #define statement, by replacing each instance of your variable with the register you pass to the 'Register' function, but only within registration and deregistration of your variable.

I still need to learn how objects are programmed, because I'm still not really sure how you would go about converting this to asm. I was just basing this off how drx coded his.

Now, asm in your guys' opinion may be easier, but its harder to keep track of things. With variables and classes and everything that a scripting language has, it's a lot easier to actually visualize what is going to happen with your code.

So yeah, again, I'd love to help make this happen.

 

Why only extend this to objects? Heck, we knoww enough of the ASM to basically convert the entire engine into a scriptable interface. I mean, this isn't far off from the C compilers that developers used to write code and then compile it to ASM. Actually, thinking about it, it isn't really off at all with this concept.

Of course, extending this to the entire engine would be more difficult, but I think if done properly it can allow forsome very interesting hackng opportunities. Especially since I can conceptualize better in a C-like language than in ASM.

 

What I think would be a good starter is a user friendly program to make simple objects, specify their solidity, graphics and height/width and tie them with some of the existant routines within the game's code, taking samples from the other objects. That way you might be able to make mixed objects such as a block that can be broken from the top (HTZ rocks) and can be hit from below to make it fall (like happens with the monitors). Stuff like that.

Then, it would be possible to add more stuff in one of the ways you guys are discussing.