What would your ideal scripting language look like?

Discussion in 'Game Development (Technical)' started by Adrian Lopez, Mar 11, 2011.

  1. Adrian Lopez

    Original Member

    Joined:
    Sep 7, 2004
    Messages:
    489
    Likes Received:
    0
    A-ha! This is exactly what I have in mind for it, actually. I want to make something like Love2D but without all the licensing baggage of its LGPL dependencies.
     
  2. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    Strictly speaking, no, you don't need a scripting language. In the same vein, you don't need a debugger, you don't need a profiler, you don't need an IDE, you don't need a 3D model editor, you don't need a sound editor, you don't need a level editor, etc. You could write everything in C using notepad, edit.com or /bin/ed. Or butterflies.

    But scripting languages *do* help. For starters, most scripting languages allow you to reload the scripts while the game is running. If your engine's edit-compile-run cycle takes more time than the script's edit-[compile]-load (and if you use something like C++ it will take more time) then you already save time. Moreover if you decouple the game's state from the script's state (or find a way to preserve the script state between script loads - again depends on the language and how it is implemented) you can fix script bugs without having to shut down, edit and load back the engine. This too can save a lot of time, especially if your game has large assets which take a while to load.

    A scripting language and an editor are different things and i don't see how you can compare the two. With the editor you set up the game's world while with the scripting language you set up the game's logic and flow. If anything, when you're making the editor it would be a good idea to embed a scripting language to the editor so that you can extend it without the need to restart it every time.

    In my Alithia engine the editor and game are both the same thing and the scripting language runtime is shared. Not only this gives the game logic all the abilities that the editor has, but since it is interpreted at runtime i can write and test new editing functions while the engine is running, at the point where i need them without unloading and reloading the engine (even though i write in C which compiles much faster than C++, it still is slower than a runtime that is always available right there). The script evaluator was one of the first things i added to the engine, before even adding 3D model. And the "command line" was the first thing i implemented once i had fonts working. When it comes to its design, the engine is highly script driven and so far i'm very pleased with the results.

    Note, however, that not all scripting languages are the same. Far from it. While i can argue that all scripting languages help your game (except some pathological cases like using some sort of brainfuck of course :p), some are more helpful that others. For example if your language requires a complete runtime restart to use new code and it doesn't expose enough functionality for your engine to keep the state, you might need to reload the engine every time you modify the script. This still saves you the engine compile step, but again if the engine needs to reload a lot of assets, the compilation time might not be as important.

    Beyond runtime features there are language features. Someone mentioned that data driven engines are better than script driven engines. Well, in some languages code and data are the same. For example in my Alithia engine, i use the code like this to register entities with the engine and the editor:
    Code:
    entities-list static {
        Blocks {
            plainblock
            curveblock
        }
        Decoration {
            armor1 armor2 armor3
            table1 gtable chair1 chair2
            portrait
        }
    }
    
    The above could be some sort of JSON-like format for declaring a tree, but in this case it is normal LIL code (the scripting language i wrote and use). The "entities-list" function schedules some code to be executed at initialization time which converts the passed list to function declarations for use with the "call-entity-class-constructor" i mentioned in my previous post. For example the "plainblock" is transformed to a function named "plainblock-class-constructor". The "Blocks" and "Decoration" parts are used for adding the entities under the proper categories under the editor's "Create" menu option and the "static" part is used to call the "public-static-entity-classes" function which does the actual transformation (which is called like "public-${type}-entity-classes" with "type" being the first argument to the "entities-list" function).

    Without this dynamic nature of LIL i would need to repeat a lot of the same code for registering these 10 entities. But now not only i type less, but the above code can be easily parsed and/or generated by some other tool that knows nothing about LIL thanks to it's simplicity.

    I've written a couple of articles in my blog about DSLs in LIL and state machines for games. Both use LIL but the latter can be implemented in any language with similarly dynamic nature.
     
  3. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    I don't see any need for repeating code to do the above. In a scriptless environment I'd go with a text file somewhere like...

    Then just read the file in, if the first word is ENTITY, then the next word is the type, and the one after that the entity.

    I'd probably abvoid the text file altogether though and instead use the folder structure and catalogue it...

    Blocks
    +---Curve
    +---Plain
    Decoration
    +---armor1
    +---armor2 etc.

    Then our artists can just drop the items into the folders and "it just works", no recompile, no scripts to mess around with. Get the data from source control and stuff appears in game ready to go. Can't see why you'd be repeating anything.
     
  4. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    Eh, you repeat "ENTITY" and "DECORATION" :p

    (as a side note, the file you posted is also valid LIL code and in fact i could just make it work by writing "func ENTITY {category name} {public-static-entity-classes $category $name}" although this would be slightly wrong since there are non-static entities too :).

    This is far from the same. Entities are engine constructs and have nothing to do with the models stored on disk. The above code registers the entities in the editor and defines class constructors which load the proper models for each entity (the models are expected to have the same name as the entity class) and setup their state. Additionally these are only for the public entities, ie. the entities that will be exposed to the editor. Entities such as fragments from broken items, etc are not exposed since they're supposed to be created from script code.

    What is the same as what you describe is the textures. For those i'm doing exactly what you're saying since textures aren't scriptable.
     
  5. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    Easily avoided.

    This is the point though, with my little text file you could probably get non-technical artists\designers to work with that. But start to throw in braces, statics, public, classes etc and suddenly you're into the realm of coding.

    Maybe I misunderstood what your stuff was doing then. But if you're loading models of the same name as your registered entities then why not just catalogue the models in a folder and use the models that you find to register as an entity? I fail to see what you described as an example of why a scripting language is better than just having something that's data driven. Nor why if you coded something like that up you'd end up repeating code.
     
  6. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    That depends on where the line is drawn. For example if you merely expose low-level functionality on the "host" side (loading, drawing, sound, input, etc.) and create the actual game completely on the "guest" side, then yes, using some kind of scripting language can be indeed worth your time - no matter how small the game is.

    But that's only true because the "host" side is completely reusable. It's a generic environment, which can be reused - the way it is - for any other project.

    A modern web browser (or Phonegap, Appcelerator, Chromeless, whatever) or Flash is such a generic environment for example.

    LuaJIT and V8 (JavaScript) are also pretty fast these days. You can do quite a lot more over there than you used to. E.g. doing some path finding, some AI, some physics, and some particle effects over there is actually fine.
     
  7. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    I'm not writing code for people i'll probably wont work with. And i believe almost everyone here wont be in that situation. Still, i know of a recent case of a game (Conspiracies 2) where most of the scripting was done in Lua by one of the designers who had never programmed or had any idea about programming before. The game's programmer only did the more complex stuff. So it isn't like non-programmers are incapable of ever writing any kind of script code (and in my opinion, when you're making an indie game you must always be prepared to touch everything because it often happens that if you don't do it, then it isn't going to happen... but that is another discussion).

    Yeah, actually you did but that's normal since of course i can't expect others to be familiar with the engine (on the other hand i can't explain the whole engine).

    I'm not loading models of the same name as the registered entities, this is just a convention for the static entities so i wont have to explicitly mention the model name twice. There is no forced association between entities and models.

    I didn't. What i described is how code in some scripting languages can be used both as code and as data so with these languages there is no "better" or "worse" because you use the right methodology for the case. As i said in my previous post, your example is proper LIL code and you could use LIL (or a similar language) to use that example. The advantage over parsing the code manually is that with the manual parsing you write specialized code for a narrow purpose while by using a scripting language that still understand the same (or a similar) format you also have the extra flexibility that the scripting language provides.
     
  8. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    Lisp syntax is like it is for a good reason. The simple syntax allows Lisp code to easily generate Lisp code. Which means the language is easily extensible without having to resort to compiler hacking.

    Adding new language features to the C++ standard involves writing a new compiler. Adding new language features to Lisp doesn't.
     
  9. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    I just saw the quote thanks to HairyTroll's post above. So i also want to add that...

    ...the readability of C/C++ comes from the reader's familiarity with it and similar languages. Back when all i knew was GWBasic i couldn't read a line of C. Someone familiar with Lisp won't have the issue you mention (personally i'm not that familiar but i know people who write in Common Lisp for years now and they act like they have a parser in their mind :p).

    Of course familiarity is important and commonly an important factor in language design for languages which are targeted for mass appeal. Possibly the reason haXe looks like AS3 and JavaScript instead of OCaml for example, despite the language having a similar set of features and the compiler being written in OCaml.
     
    #49 Bad Sector, Mar 22, 2011
    Last edited: Mar 22, 2011
  10. Adrian Lopez

    Original Member

    Joined:
    Sep 7, 2004
    Messages:
    489
    Likes Received:
    0
    One can learn to read and become proficient in almost any language, but that doesn't mean any language is just as easy to read as any other.
     
  11. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    This is true, but it doesn't matter. To a programmer, the readability will depend on the languages he is already familiar with and how much the language in question looks (and behaves) like these languages. To a non-programmer all (serious) languages will look unreadable. Since to learn programming you need to practice it, by the time you learn how to program, your readability preferences are already biased.
     
  12. lennard

    Moderator Original Member Indie Author

    Joined:
    Jan 12, 2006
    Messages:
    2,390
    Likes Received:
    12

    This is true. I'm finding myself annoyed that PHP and Flash do some minor string printing things differently than C. If you are doing the exact same thing as a popular language already does... bloody well follow the convention so everybody following on doesn't have to spend time remembering your languages little quirks in their re-invention of the wheel.
     
  13. lightassassin

    lightassassin New Member

    Joined:
    Nov 21, 2009
    Messages:
    191
    Likes Received:
    0
    Good points. I script in python atm so I'm use to that, just lisp looks very odd, and I tend to think somebody can read (2 + 2) better than (+ 2 2) that I saw of lisp (I've only looked at that article).

    I'd love to see GOAL and if it's as fast as he says (though it appears to be locked down to his studio owned by sony) it would be very nice, especially the threading and the like.

    He stated that he believes it took 4 man years to create, darn shame he can't share it with the world.

    Scripting isn't that hard, especially with some of the newer languages, the hard part is motivating people to use it. Though I've worked with the public long enough to know even finding their own wallet is a task.
     
  14. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    It wouldn't matter if he did. Even if it was the greatest thing ever invented, developers would take one look at it and go "Oh... Lisp syntax..." and that would be that.
     
  15. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    Here is a favourite post of mine describing the advantage of Lisp syntax... and why C macros blow.

    :)
     
  16. lightassassin

    lightassassin New Member

    Joined:
    Nov 21, 2009
    Messages:
    191
    Likes Received:
    0
    Interesting thread, curious to see more about lisp and your post about the macros was valid.

    Have you used lisp for any game development Hairy?
     
  17. Gary Preston

    Original Member

    Joined:
    Aug 5, 2005
    Messages:
    239
    Likes Received:
    0
    We've used scheme which is along the lines of lisp as part of our art pipeline. It's not all that bad once you get used to it, but I wouldn't want to code anything more than simple util scripts in it :)

    Here's a snippet

    Code:
    (define (alfred-delete-excluded-layers image)
        ;; Delete layers starting with an exclamation mark
        (let loop ((layers (vector->list (cadr (gimp-image-get-layers image)))))
            (unless (null? layers)
        
                (let ((layer-name (car (gimp-drawable-get-name (car layers)))))
                    (if (string=? (substring layer-name 0 1) "!") 
                        (gimp-image-remove-layer image (car layers))
                    )
                )
                (loop (cdr layers))
            )
        )
    )
    
    loops are rather "interesting" in that they're a recursive procedure call.
     
  18. MrPhil

    Original Member

    Joined:
    Aug 4, 2004
    Messages:
    671
    Likes Received:
    0
    I would look at it in Visual Studio
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer