Get Started With Lua Events Lesson 6: Splitting Code into Multiple Files: Difference between revisions

From Scenario League Wiki
Jump to navigationJump to search
(Created page with "Category:Lua Resources Back to Get Started With Lua Events This Lesson is under construction.")
 
No edit summary
Line 3: Line 3:


This Lesson is under construction.
This Lesson is under construction.
In this lesson we'll look at how to split the Lua code for a scenario into multiple files.  There are several reasons why this is desirable.  The first is sheer organizational convenience.  If you have several game mechanics and the tables of information required to support them, the events.lua file gets large and confusing in a hurry.  Trying to find a particular event in order to make a change requires finding the code in the first place, and that usually requires knowing exactly what you called some function that you may have completed months ago.  When I work on Over the Reich, I often search for the civ.scen function that controls the event in order to get the name of the exact function that I want to change, and then do another search for that function.  For that matter, if you want to add more functionality, it is not always clear where the code should go.  Having functionality in multiple files significantly reduces these problems.  It also means you don't have to worry about conflicting function and variable names in different parts of the code.
Another reason to have multiple files is to facilitate collaboration.  If two or three people are collaborating on a scenario, only one of them can be working with a file at a given time.  If there is only a single events.lua file, then the designers will find it difficult to work in parallel.  On the other hand, if there are separate files, then each can work on his or her own part of the project when convenient without worrying that they are preventing someone else from working if they are delayed.
A third reason to split events into multiple files is to facilitate the re-use of code.  Re-using code is desirable to cut down on duplicated effort, both in programming and testing.  By having reusable code in a separate file, the user doesn't have to look at the details of how the code works or worry about conflicting names if it is cut and pasted into an events file.  Also, if a bug is discovered, fixing the bug in all scenarios that use the code just requires replacing a file, rather than digging into the events.lua file for each scenario and finding every use.

Revision as of 23:02, 9 June 2019

Back to Get Started With Lua Events

This Lesson is under construction.


In this lesson we'll look at how to split the Lua code for a scenario into multiple files. There are several reasons why this is desirable. The first is sheer organizational convenience. If you have several game mechanics and the tables of information required to support them, the events.lua file gets large and confusing in a hurry. Trying to find a particular event in order to make a change requires finding the code in the first place, and that usually requires knowing exactly what you called some function that you may have completed months ago. When I work on Over the Reich, I often search for the civ.scen function that controls the event in order to get the name of the exact function that I want to change, and then do another search for that function. For that matter, if you want to add more functionality, it is not always clear where the code should go. Having functionality in multiple files significantly reduces these problems. It also means you don't have to worry about conflicting function and variable names in different parts of the code.

Another reason to have multiple files is to facilitate collaboration. If two or three people are collaborating on a scenario, only one of them can be working with a file at a given time. If there is only a single events.lua file, then the designers will find it difficult to work in parallel. On the other hand, if there are separate files, then each can work on his or her own part of the project when convenient without worrying that they are preventing someone else from working if they are delayed.

A third reason to split events into multiple files is to facilitate the re-use of code. Re-using code is desirable to cut down on duplicated effort, both in programming and testing. By having reusable code in a separate file, the user doesn't have to look at the details of how the code works or worry about conflicting names if it is cut and pasted into an events file. Also, if a bug is discovered, fixing the bug in all scenarios that use the code just requires replacing a file, rather than digging into the events.lua file for each scenario and finding every use.