Scripting implementation progress

Source Code and development in general from a technical point of view. Post Patches here.

Moderator: SMC Team

Re: An easier way to implement scripting

Postby Luiji » 29 Aug 2012 23:12

I haven't programmed in Java in over a year, and then it was an attempt at getting a few buttons up on an Android App. That turned out terribly, because the compiler and emulator were so slow that I gave up on the Android platform as a whole. I have some faster machines now that might make development for Android more bearable again.
Custom Built IBM-Compatible (Arch Linux w/ KDE)
Dell Vostro (Windows 7)
Dell Inspiron 1440 (Windows Server 2003, Debian w/ KDE)
Dell Inspiron 11z (Linux Mint)
Luiji
MVP
MVP
 
Posts: 2703
Joined: 14 Jan 2010 23:20
Location: The Mushroom Kyngdom

Re: An easier way to implement scripting

Postby BowserJr » 30 Aug 2012 00:17

No, the emulator's still pretty slow. They've made it a lot better, but it's still basically emulating a full ARM CPU. There is an x86 emulator now, which is faster than most phones, but a bit of a pain to set up properly and doesn't support maps or other Google APIs, so can't be used for everything.

It's fine, we all know you don't like Java. That's why my joke works. :wink:
"Plants need to have water poured on them because they have no hands to hold glasses of water."
User avatar
BowserJr
SMC Team
SMC Team
 
Posts: 1543
Joined: 05 Feb 2007 14:07
Location: London, UK

Re: An easier way to implement scripting

Postby Luiji » 30 Aug 2012 01:12

Speaking of Java, the only game on my computer that crashes all the time is the only game on my computer written in Java. Spiral Knights by SEGA and Three Rings. :D

I don't get why destructors aren't automatically virtual. In fact, I don't get why anything isn't automatically virtual. Is it a speed thing?
Custom Built IBM-Compatible (Arch Linux w/ KDE)
Dell Vostro (Windows 7)
Dell Inspiron 1440 (Windows Server 2003, Debian w/ KDE)
Dell Inspiron 11z (Linux Mint)
Luiji
MVP
MVP
 
Posts: 2703
Joined: 14 Jan 2010 23:20
Location: The Mushroom Kyngdom

Re: An easier way to implement scripting

Postby BowserJr » 30 Aug 2012 09:10

My understanding is virtual methods will always have some overhead vs normal methods because they can't be inlined, and so always need a lookup at runtime. These lookups shouldn't be noticeably slower for most applications, but C/C++ were built around the idea that you shouldn't pay for what you don't use, so every possible performance hit is disabled unless told otherwise.

More reading: http://stackoverflow.com/questions/4498 ... formance-c
And this one, specifically for virtual destructors: http://stackoverflow.com/questions/3009 ... estructors
"Plants need to have water poured on them because they have no hands to hold glasses of water."
User avatar
BowserJr
SMC Team
SMC Team
 
Posts: 1543
Joined: 05 Feb 2007 14:07
Location: London, UK

Re: An easier way to implement scripting

Postby Luiji » 30 Aug 2012 18:01

O_o that one guy's statistics looks scary. I like the concept of "it's not a performance problem unless you can prove it," though. Thanks for the links!
Custom Built IBM-Compatible (Arch Linux w/ KDE)
Dell Vostro (Windows 7)
Dell Inspiron 1440 (Windows Server 2003, Debian w/ KDE)
Dell Inspiron 11z (Linux Mint)
Luiji
MVP
MVP
 
Posts: 2703
Joined: 14 Jan 2010 23:20
Location: The Mushroom Kyngdom

Re: An easier way to implement scripting

Postby BowserJr » 30 Aug 2012 18:36

Where would programmers be without StackOverflow? <333
"Plants need to have water poured on them because they have no hands to hold glasses of water."
User avatar
BowserJr
SMC Team
SMC Team
 
Posts: 1543
Joined: 05 Feb 2007 14:07
Location: London, UK

Re: An easier way to implement scripting

Postby Luiji » 30 Aug 2012 19:03

Largely dead, because we'd all commit suicide. :P
Custom Built IBM-Compatible (Arch Linux w/ KDE)
Dell Vostro (Windows 7)
Dell Inspiron 1440 (Windows Server 2003, Debian w/ KDE)
Dell Inspiron 11z (Linux Mint)
Luiji
MVP
MVP
 
Posts: 2703
Joined: 14 Jan 2010 23:20
Location: The Mushroom Kyngdom

Re: An easier way to implement scripting

Postby DevEd2 » 05 Sep 2012 12:22

I thought this was a discussion on scripting?
User avatar
DevEd2
Turtle boss
Turtle boss
 
Posts: 791
Joined: 30 Nov 2010 22:44
Location: Earth :P

Re: An easier way to implement scripting

Postby Luiji » 05 Sep 2012 20:31

I think it's diverged into a bit of a general SMC development topic, focusing primarily on scripting.
Custom Built IBM-Compatible (Arch Linux w/ KDE)
Dell Vostro (Windows 7)
Dell Inspiron 1440 (Windows Server 2003, Debian w/ KDE)
Dell Inspiron 11z (Linux Mint)
Luiji
MVP
MVP
 
Posts: 2703
Joined: 14 Jan 2010 23:20
Location: The Mushroom Kyngdom

Re: An easier way to implement scripting

Postby Quintus » 05 Sep 2012 21:29

Luiji wrote:I think it's diverged into a bit of a general SMC development topic, focusing primarily on scripting.

Perhaps a moderator could split the topic. Whatever we’re currently discussing has only little to do with what the OP, Jonn, posted. And although all posts are still labelled "An easier way to implement scripting" we’re actually discussing the real implementation of scripting (with Stackoverflow as a source for helpful links which really is perfectly valid and on-topic). We should really have one or more separate topics for the stuff in here.

Valete,
Quintus
Aetas nulla ad discendum sera.
User avatar
Quintus
SMC Team
SMC Team
 
Posts: 353
Joined: 14 Sep 2010 18:05
Location: Germany -> NRW -> UN

Re: Scripting

Postby Manscent » 20 Dec 2012 08:22

Any news on this?
Manscent
Spike
Spike
 
Posts: 115
Joined: 15 Mar 2007 04:37
Location: Washington State, USA

Re: Scripting

Postby Luiji » 22 Dec 2012 19:17

Quintus has been working on this in his spare time. I've got something up my sleeve but it won't be online for quite awhile.
Custom Built IBM-Compatible (Arch Linux w/ KDE)
Dell Vostro (Windows 7)
Dell Inspiron 1440 (Windows Server 2003, Debian w/ KDE)
Dell Inspiron 11z (Linux Mint)
Luiji
MVP
MVP
 
Posts: 2703
Joined: 14 Jan 2010 23:20
Location: The Mushroom Kyngdom

Re: Implementing scripting

Postby FluXy » 28 Dec 2012 15:30

Heya,

Thanks for working on SMC Quintus :)

Some topic feedback :
- The Save_To_XML() update sounds good.

- I think backward compatibility with older levels is very important, SMC 1.9 can even load some levels from 1.0 without problems :)
I maintained it by translating the deprecated definitions (filenames, data defaults) to the new one in the level loading.
Many players create their own unpublished levels and will think that SMC 2.0 broke their levels as they don't read the forums/website to check how the levels could be converted.

- CEGUI is not a bad dependency just because it's hard to compile ;) Most other GUI libraries i checked at that time were and still are badly maintained or just don't have much functionality.
Never reinvent the wheel by writing a custom GUI subsystem, that time is spent far better at building the actual game :)

- Don't use Allegro :P OpenGL and later OpenGL ES is the best way to go.

Have fun :)
If i didn't read your post but it was important you can send me a PM.
Any Donation will help this project!
User avatar
FluXy
Admin
Admin
 
Posts: 2857
Joined: 04 May 2004 19:44
Location: Germany

Re: Scripting implementation progress

Postby Quintus » 28 Dec 2012 19:16

Thanks for all the feedback! :) Note however that I’m currently not working on SMC due to both RL and another project that currently eats up most of my free time... I generally don’t like to leave things unfinished, so sooner or later I’m going to complete the scripting stuff but for now I can’t.

Regarding the backward compatibility: I can see the point, but a major version bump should IMO be seen as an opportunity to clean up code. If we don’t decide to do so, the new version should better be 1.10 than 2.0. Also, I agree that the game shouldn’t just refuse to load the levels, it instead should say something like "This level was created with a too old version of SMC" and should probably offer to convert it to the new format.

FluXy wrote:Never reinvent the wheel by writing a custom GUI subsystem, that time is spent far better at building the actual game
I agree and also confess to have violated this principle by writing a custom Lua/C++ wrapping library which now sits around and wants to be maintained. As I already mentioned in IRC to DarkAceZ, it was a very interesting project, but probably a bad idea. I’m not yet sure how I will cope with this self-grown problem...

Anyway, thanks for showing up again :-)

Vale,
Quintus
Aetas nulla ad discendum sera.
User avatar
Quintus
SMC Team
SMC Team
 
Posts: 353
Joined: 14 Sep 2010 18:05
Location: Germany -> NRW -> UN

Re: Implementing scripting

Postby mrvertigo27 » 07 Jan 2013 07:47

FluXy wrote:Have fun :)


OMG, I thought you died!
I'm A YouTube Gaming Commentator https://www.youtube.com/user/Spitfire25565
User avatar
mrvertigo27
SMC Team
SMC Team
 
Posts: 2316
Joined: 20 Aug 2009 16:10
Location: the state of insanity

Re: Scripting implementation progress

Postby Quintus » 24 Sep 2013 12:38

In case there are people watching this thread, you might also want to take a look at this thread.

Anyway, on topic: It’s now possible with scripting to create all powerups SMC supports (including moon and star). So you could now do things like make powerups appear if you defeated a specific enemy or the like (but note, enemies are still work-in-progress).

I’ve set up a website that regenerates the scripting API documentation from the sources every day at 6:00 CET (UTC+1): http://smcsdocs.quintilianus.eu . This way you don’t have to wait for me uploading ZIP files containing the current docs. Just view it online.
There’s also a HTTPS version available: https://smcsdocs.quintilianus.eu/. Note that it’s using my self-signed SSL cert, so you have to decide on yourself if you trust that cert or not.

Valete.
Aetas nulla ad discendum sera.
User avatar
Quintus
SMC Team
SMC Team
 
Posts: 353
Joined: 14 Sep 2010 18:05
Location: Germany -> NRW -> UN

Re: Scripting implementation progress

Postby -DarkAceZ- » 24 Sep 2013 16:36

Shouldn't play_sound() be more like sound_play()? Unless that's going to be the only sound function, wouldn't you want all sound functions to start with sound_*?
User avatar
-DarkAceZ-
Maryo small
Maryo small
 
Posts: 1062
Joined: 28 Oct 2010 17:24
Location: The Level Editor

Re: Scripting implementation progress

Postby Quintus » 24 Sep 2013 18:42

-DarkAceZ- wrote:Shouldn't play_sound() be more like sound_play()? Unless that's going to be the only sound function, wouldn't you want all sound functions to start with sound_*?

No. If you look at the naming scheme for the methods in other classes/modules, you’ll notice that they are made to be readable. This is one of the reasons why I personally like Ruby so much: It is intended to be as natural as possible, while still maintaining full OO capabilities. If you want to namespace things, use modules. This is why you’ll find the sound stuff only in Audio. Ideally, a program reads like a text in such a way you can read out the lines aload and can still make something of it. Given that scripters will not be programmers in the main sense, but rather hobbyists wanting to enhance their levels, I think going with natural names is much better than emplacing scoped names — which I don’t like anyway. do_something reads much better than something_do.

As another example, Ruby provides these very nice post-conditions. So you can write something like this:

Code: Select all
play_sound("mysound") unless rokko.flying?


Yes, this is valid Ruby code. The question mark is part of the method name — clearly denoting this will return a boolean value. The unless postcondition applies to the line preceding it; play_sound is executed if and only if the rokko object is not flying right now. These spelling-centred methods don’t play well together with scoped method names. Again, this is what we have classes and modules for. And I don’t think further dividing audio into sound and music is necessary.

A short overview of Ruby’s design can be found on the official homepage.

But anyway, a valid question. Thanks for asking!

Vale.
Aetas nulla ad discendum sera.
User avatar
Quintus
SMC Team
SMC Team
 
Posts: 353
Joined: 14 Sep 2010 18:05
Location: Germany -> NRW -> UN

Re: Scripting implementation progress

Postby mrvertigo27 » 24 Sep 2013 21:08

can we get a human readable progress report on this project? how is this working, how well, known issues?
I'm A YouTube Gaming Commentator https://www.youtube.com/user/Spitfire25565
User avatar
mrvertigo27
SMC Team
SMC Team
 
Posts: 2316
Joined: 20 Aug 2009 16:10
Location: the state of insanity

Re: Scripting implementation progress

Postby Quintus » 24 Sep 2013 22:23

mrvertigo27 wrote:can we get a human readable progress report on this project? how is this working, how well, known issues?

Yes, we can :). The basic implementation is working fairly well. The mruby integration works, scripts are properly executed and more and more classes get bridged over to mruby scripting API. However, not all classes are bridged over yet, it’s soooo much. In categories, this looks like this:

  • All powerups are accessible from scripting.
  • About half of the enemies are accessible from scripting.
  • No boxes are accessible from scripting.
  • Static sprites should work, but have not yet been tested.

Specifying massivity of sprites is possible, so you can e.g. make platforms appear Maryo can then climb up.

Event support is growing, but not complete. The probably most important event is the touch event, i.e. the event that gets fired when one object collides with another (yes, this also works if it’s not the player that collides), works bug-free as far as I can tell. Consequently, this means you can implement switches that execute other script code. However, may other probably interesting events such as a downgrade event for Krushes are still missing. If you ever wanted to hook into a specific happening in SMC, please tell me so I can look whether it’s possible to emit an event there you can connect to from the scripting interface.

There’s a basic infrastructure that allows a level writer to save and load data to and from savegames when the user saves a savegame. SMC cannot know what objects you want to keep in your savegame, so instead it gives you the ability to specify what you need and restore it on loading. An overview of this is in the documentation.

Timers (oneshot and periodic) are basically working, but quite buggy. If used too heavily or with too short intervals, SMC may crash with a segfault followed by a coredump (on Linux). As far as I can tell, timer cleanup on level exit does not what it is supposed to do.

Excessively generating objcts from within the scripting interface in a short time will make SMC crash. This especially means you need to properly guard your touch event handlers so accidental multiple touches (e.g. if you jump along an object this will cause dozens of touch events) don’t cause massive object generation.

Displaying messages to the user is not yet possible, but planned. There should be a nonblocking message that will just appear on the screen and disappear after a number of seconds and a real messagebox as already known from messagebox blocks (i.e. the user has to explicitely close the message).

There is no real in-game debugging support for scripting. What you can basically do is to use puts to write to the console. Running SMC in windowed mode greatly eases this.

Backtraces don’t work. This is a real problem when your script crashes because of whatever exception. You just get a printout of the exception on the console, but no backtrace. This however seems to be an mruby issue so we might need to wait to get this fixed upstream.

The issue with SMC taking very long to load larger levels is mostly gone. I’ve reworked the UID allocation system so it doesn’t loop over and over to find free UIDs. It’s slightly more complex now, but quite performant. Compared to pre-scripting SMC however, level loading definitely takes longer.

You can’t edit the scripting code from within the SMC editor. Currently you have to work with the .smclvl XML files themselves (just place your code between <script> and </script>). Wiring this up to the GUI requires more CEGUI knowledge than I currently have; this is something I’d love Luiji to do as he seems to have this knowledge.

Apart from scripting, I’ve basically not changed anything on SMC, not even fixed bugs. So you still get an endless loop of the level win music if you win a level played from the level menu.

A very small demo I hacked together shows how you can control Rokko; find the video on my FTP. The code used was this:

Code: Select all
rokko = Rokko.new
rokko.start_direction = :right
rokko.x = 351
rokko.y = -500
rokko.show

UIDS[15].on_touch do |collidor|
  rokko.activate! if collidor.player? and !rokko.flying?
end

Timer.every(3000) do
  if rokko.start_direction == :left
    puts "left -> right"
    rokko.start_direction = :right
  else
    puts "right -> left"
    rokko.start_direction = :left
  end
end


As a summary, I think scripting basically works. I’ve not tested everything you can find in the documentation, but as said this is due for the beta phase. Why should I test alone when there’s a whole forum that can do that for me? ;)

Oh, and I didn’t update the Windows compilation chain so that may not work. As said, I have to focus on specific things, resolving one task after the other. It is much work for a single person.

I hope this fulfills your request for a human-readable progress report. If not, please tell me...

Edit: I’ve attached the .smclvl file of the level in use. Note there’s no Rokko in there — it is generated purely by the scripting code.

Edit2: Hm, well. I wouldn’t say it works "well" to answer your second question. It tends to segfault quite often actually. So, it "basically" works. With bugs and crashes.
Attachments
A.smclvl
Level shown in the demo video
(5.96 KiB) Downloaded 158 times
Aetas nulla ad discendum sera.
User avatar
Quintus
SMC Team
SMC Team
 
Posts: 353
Joined: 14 Sep 2010 18:05
Location: Germany -> NRW -> UN

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron