Monday, 4 July 2011

Tech feature: Script Overview #1

I just recorded a little clip about how scripting works in HPL3. In this film I just talk about the very basic elements of scripting and will follow up with another movie were I talk about some more complex features:

Make sure to watch in in HD:


  1. I love these tech features that show how you constantly make progress with your next game (that will obviously be called Depth - The Dark Descent). More of this please. :)

  2. That was very interesting! Did you have to extend AS for all that exception handling and reloading or is supported out of the box?

    And also, tho I know it's totally unrelated, how do you do 3d picking in your engine? If you can write me a sentence or two about it it will be highly appreciated and it will help me a lot as I'm not sure which method to choose for my engine.

  3. That was brilliant! The futures shown are very good. I can't wait for the next post.


    How are you so sure it will be called Depth -The Dark Descent? I think that Thomas changed the name or this code isn't from the new game after all. It might be a code from the previous games tested on the new engine.

  4. Nikita:
    AngelScript supports the exception handling very easily! The reloading is bit more complicated, especially since a lot of data need to be saved and the added during reload. Will bring that up in the next part.

    The 3d picking is simply a ray cast in the physics simulation.

  5. How about OO?

    It would be really convenient not to have methods that take string parameters in order to affect a specific entity - it is very limiting.

    It's much better if you can do something along these lines (pseudocode):

    Entity table = GetEntity("Central_Table");
    Entity t = GetEntity("Central_Table_Trigger");
    Monster m = GetEntity("Monster_001");


    // then, later, when the trigger entity is... triggered...
    Entity oldWeapon = m.SetWeapon(new Axe(220)); // damage parameter
    RemoveEntity(oldWeapon); // to be garbage-collected...

    Player p = GetPlayer();
    p.SetReaction(new FreekoutReaction("freakout.rct", 600));
    p.LookAt(m.GetLocation(), 200);

  6. Regarding the OO example.

    Yes, that kind of code is very much supported. The only thing you need to do is to cast the handles correctly, for example it would look like:

    cLuxCreature@ pMonster m = cast(cLux_GetCurrentMap().GetEntity("Monster"));


  7. Looks great, especially the way it reloads the script without having to restart everything. How do you decide what should be scripted and what should be coded into the executable? Is there very much overhead when using a script or is it generally pretty fast?

  8. So far all heavy duty stuff (for example object picking) is done in C++ code. Some of these computational stuff is obvious, but others might not pop up until later. In that case I will try and make some generic c++ function for that section. The goal is that script is more of a logical/control-flow system.

    I am not sure how much slower script is and it depends a bit. For example lots of smaller script calls generally take more than calling few longer scripts (because of call overhead). In any case, as long as heavy stuff in C++, scripting is fast.

  9. I'm guessing Thomas is trying to keep the core mechanics in the C++ code, while pulling out most of the gameplay mechanics out "to the script" - thus making everything more customizable.

    BTW, isn't it possible for the game to preload all the scripts it requires for a certain area - as in the end product, scripts are not going to change during gameplay?

  10. Stuff that is computational heavy is often very "exact" in terms of determining if it works or not. You can usually sit with the code a lot and then do some testing and then it is done.

    With gameplay code this is not the same as all. You often do not know what you want up front and need to figure that out during coding. Doing this with C++ code that takes some time to rebuild and require reload of the game is just horrible. And the main reason is for the script to speed up this process. This also leads to the game being VERY customizable, but it is not the main goal.

    Reloading is not done for the actual game. So no problem there. Could even pre-compile all scripts and have the byte-data as data files.

  11. Hey Thomas,

    I know this is offtopic, but I would love an article with your impressions on the Bioshock Infinite demo. It was just released today. You can watch it on gametrailers.

  12. My Bioshock Inf impression?

    - Increadibly Beatiful world, will be interesting to explore
    - Tons of mindless combat that just seems to just go on and on.

    I wish they could just have skipped the combat altogether. Then it might have been a REALLY interesting game. Still, interesting enough for me wanted to play, just not expecting anything amazing.

  13. I agree with Thomas about Bioshock.
    They seem to use a massive physics engine like PhysX. Is Newton capable of destructions already, even not in this scale ?

  14. My guess would be that all major destruction is pre-computed and simply stored as animations. Like the rail-bridge scene in Half-Life2 Ep1.

    As for newton handling generic destruction (big difference here since almost all destruction you see in games is pre-made), yes it is!

  15. Thomas:
    1. Does the engine or script generate the graphics? Because I want to try and make my own game.
    2. Can you make 3rd person games in the engine?
    3. Does every game you make in HLP3 look and feel just like Amnesia?
    Please try to respond.

  16. Tyler:
    Can sum up in one answer:
    You should be able to make an RTS game by modding our next game.


Note: only a member of this blog may post a comment.