Game Engines - GDC: Scripting
Last class we watched a GDC '11 presentation regarding proper uses and techniques of scripting systems and the concepts of the proper architecture required. I'll be going over the information in the presentation, as well as my thoughts and approach to implementing this in our GDW game.
The beginning of the slides started off by distinguishing the main difference between implementing features and core mechanics directly into the main project, as opposed to developing the main project to parse and interpret external commands. The presentation stated that making the game in code is not any different as making the game in scripts, regarding the proper way of implementing mechanics and developing games.
The idea that scripting is "Faking it" is referring to how scripting is not properly implemented in some projects, and that the engine is set up to handle most of the mechanics regardless of the script. They are saying that scripting is not used to its full potential, and is currently being used to modify small values and "fake" behaviors that could be done in code. They later explain the benefits of scripting as opposed to an engine tailored towards a specific game.
The presenters brought up great points that scripting and hardcoding can be represented as robust and brittle systems, where a project would be much better off with a robust and highly dynamic system, as apposed to specific implementation that solves one problem specifically at a time. Economics was a key factor in this statement, since developers do not have the time to specifically cater to each problem extremely well, and how a robust and malleable system works well most of the time.
They stated a lot of benefits that can be gained by having the designers have more control with scripting:
However there are some downsides to scripting, such as the small hit in performance for the game during runtime. They discussed how having a more dynamic and malleable system, where designers can modify and tweak components and values at their content is performance sensitive and systems which are dependent on and rank performance highly do not take into consideration designer expressiveness.
The presenters went over their concepts for implementing scripting properly, they stated that their goal was to keep scripting represented as a "pillar of the Engine". Scripting should be used in mechanic and objective pieces, that together make up and hold the game. The engine's job is to provide the architecture and be open to receiving various designs related to how the game model is set up, in this case a Component and Object model. They set up their Engine architecture so that components could be created and implemented in C++ and also in Lua script. Their main idea was that scripting was the main modifier and source of the game, and that the script was the "glue" that held and tied together all the game components and mechanics.
Their scripts consisted of 3 parts: Components, System scripts, and Data. Each part tied together is what makes up the entire system, where the scripts were dynamic and adjustable enough to be able to take output from one component and set of functions or algorithms, and adjust the output to be prepped and ready for the next part of the pipeline.
The metaphor is that instead of cutting each individual brick to directly fit in with the surrounding bricks (each component and mechanic or algorithm in the pipeline), mortar/cement (malleable scripts to mold inputs and outputs to be compatible) is used to die and hold all the bricks together as one big system.
The term Component Soup was used to describe all the various scripts and C++ code in the entire system, encapsulated in a cluster that communicates with each system to form the game. As they made the game, a lot of script was moved into actual code, and they moved items in the soup to either code or script as each item's role in the game and the relationship with the design was more and more understood.
They discussed how the Data portion of scripts has many requirements for proper functionality in their project, and the need for the data to be able to save current states of scripts (useful for pausing and linking different components), driving the entire system with a data driven approach, and also defining the structure of both of the above. They implemented a system where they define the structures for the data blocks that would be allocated in the engine, and the engine was the governing factor of the lifetime of the blocks. They handled Lua as only being able to read and write the blocks that the engine allocated, and making it impossible to allocate it's own dynamic memory. This could possibly save a lot of debugging and problems down the line.
The system they described to be working was that they had the engineer make the framework work properly, which then was passed to the designer to make it work well, which then was passed to the engineer to make it fast, and then passed back to the designer to make sure it still worked well. They explained how it could be months between each step and that it was important to make sure that all the information and communication was kept consistent.
In summary:
The beginning of the slides started off by distinguishing the main difference between implementing features and core mechanics directly into the main project, as opposed to developing the main project to parse and interpret external commands. The presentation stated that making the game in code is not any different as making the game in scripts, regarding the proper way of implementing mechanics and developing games.
 |
| Example lua game trigger script |
The idea that scripting is "Faking it" is referring to how scripting is not properly implemented in some projects, and that the engine is set up to handle most of the mechanics regardless of the script. They are saying that scripting is not used to its full potential, and is currently being used to modify small values and "fake" behaviors that could be done in code. They later explain the benefits of scripting as opposed to an engine tailored towards a specific game.
The presenters brought up great points that scripting and hardcoding can be represented as robust and brittle systems, where a project would be much better off with a robust and highly dynamic system, as apposed to specific implementation that solves one problem specifically at a time. Economics was a key factor in this statement, since developers do not have the time to specifically cater to each problem extremely well, and how a robust and malleable system works well most of the time.
"... so what we should be asking ourselves is not 'how do we avoid faking it' but 'what’s the best way to fake it?'"
They stated a lot of benefits that can be gained by having the designers have more control with scripting:
- Easy to write branches for designers
- Simple to process and understand logic of simple lines and conditions
- Extremely clear why X or Y happens
- Highly customization
- Iteration times
However there are some downsides to scripting, such as the small hit in performance for the game during runtime. They discussed how having a more dynamic and malleable system, where designers can modify and tweak components and values at their content is performance sensitive and systems which are dependent on and rank performance highly do not take into consideration designer expressiveness.
The presenters went over their concepts for implementing scripting properly, they stated that their goal was to keep scripting represented as a "pillar of the Engine". Scripting should be used in mechanic and objective pieces, that together make up and hold the game. The engine's job is to provide the architecture and be open to receiving various designs related to how the game model is set up, in this case a Component and Object model. They set up their Engine architecture so that components could be created and implemented in C++ and also in Lua script. Their main idea was that scripting was the main modifier and source of the game, and that the script was the "glue" that held and tied together all the game components and mechanics.
Their scripts consisted of 3 parts: Components, System scripts, and Data. Each part tied together is what makes up the entire system, where the scripts were dynamic and adjustable enough to be able to take output from one component and set of functions or algorithms, and adjust the output to be prepped and ready for the next part of the pipeline.
 |
| Visualization of scripting "glue" (GDC11 scripting disla) |
The metaphor is that instead of cutting each individual brick to directly fit in with the surrounding bricks (each component and mechanic or algorithm in the pipeline), mortar/cement (malleable scripts to mold inputs and outputs to be compatible) is used to die and hold all the bricks together as one big system.
The term Component Soup was used to describe all the various scripts and C++ code in the entire system, encapsulated in a cluster that communicates with each system to form the game. As they made the game, a lot of script was moved into actual code, and they moved items in the soup to either code or script as each item's role in the game and the relationship with the design was more and more understood.
They discussed how the Data portion of scripts has many requirements for proper functionality in their project, and the need for the data to be able to save current states of scripts (useful for pausing and linking different components), driving the entire system with a data driven approach, and also defining the structure of both of the above. They implemented a system where they define the structures for the data blocks that would be allocated in the engine, and the engine was the governing factor of the lifetime of the blocks. They handled Lua as only being able to read and write the blocks that the engine allocated, and making it impossible to allocate it's own dynamic memory. This could possibly save a lot of debugging and problems down the line.
The system they described to be working was that they had the engineer make the framework work properly, which then was passed to the designer to make it work well, which then was passed to the engineer to make it fast, and then passed back to the designer to make sure it still worked well. They explained how it could be months between each step and that it was important to make sure that all the information and communication was kept consistent.
In summary:
- C++ is high performance and low designer expressiveness
- C++ core engine should be reusable and not game specific
- Scripts are low performance and give designers high expressive freedom
- All game logic and what makes the game unique should be in scripts (DSL (hit player with hammer))
Comments
Post a Comment