Jump to content
  • Advertisement
Sign in to follow this  
Orfby

How much of my game should be written in a scripting language?

This topic is 1238 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

NOTE: The game engine isn't done yet, so don't feel any hesitation to suggest I completely redo the whole engine design

 

Currently I have a system where there is a C++ program, who's main purpose it to be a very open framework for Lua. The C++ program first exposes a low level API (mostly based off of the SFML Libraries) to Lua, and this API only has classes like Texture, Text, Font, Sprite, Window etc. (Very based off of SFML). After exposing the API it runs all instances of init.lua in all "Content Packs" (each pack is it's own mod, and the "Base" pack is all vanilla scripts). init.lua is only run once, and is basically for setting up all objects for the start. Next all instances of draw.lua and update.lua are run, where draw.lua is run every game loop, but update.lua only happens every x number of milliseconds (every 20ms for example).

 

I feel like this system is way too non-specific and (though I haven't tested it) could be very slow, so I thought that I should have more classes in the API. I could create a TileGrid class which handles individual Tile class (my game isn't tile based, its more of a suggestion), then expose that class, but I don't know if there is any real benefit to doing this. So, is my previously planned design good, or does it need to be more specific?

Share this post


Link to post
Share on other sites
Advertisement
After exposing the API it runs all instances of init.lua in all "Content Packs" (each pack is it's own mod, and the "Base" pack is all vanilla scripts). init.lua is only run once, and is basically for setting up all objects for the start. Next all instances of draw.lua and update.lua are run, where draw.lua is run every game loop, but update.lua only happens every x number of milliseconds (every 20ms for example).

 

 

The thing that strikes me the as most-concerning here is that the engine "runs all instances of init.lua," and similarly all instances of "draw.lua" and so on. What determines the ordering here? Ordering is important to consider in this kind of scenario. Have you ever tried to run a lot of mods in Skyrim or some other Bethesda RPG? The ordering of mods is important because they can independent set up or stomp on certain core features and thus break eachother if not done in the proper order. The biggest weakness of your system as proposed is the need for this ordering, and the fact that you don't (seem) to have a mechanism to control it.

 

The next-most-concerning aspect of your system is that you don't describe the method by which data is transferred or access between the init.lua scripts and the corresponding draw and update Lua scripts. It would be interesting to know how you plan to expose that as it might suggest other issues in your system.

 

Beyond that, it's an approach that seems reasonable and common. Performance may or may not be an issue depending on the specific implementation decisions you make, but that's what profiling and refactoring are for; I wouldn't worry overmuch about it until you've got a working prototype that you can take some actual benchmarks on.

Share this post


Link to post
Share on other sites

I have made some large games in lua and the speed of lua was often not a problem. If it is you can always rewrite the part that need more speed in C++ or (as is most common) find another faster way of doing it in lua :).

Share this post


Link to post
Share on other sites

In response to Josh Petrie (in paragraph order):

 

1) I do have a algorithm that runs the files, and its a lot more strict than I made it out to be. The way it works is that it first goes to the folder "./Content/Base/" then runs init.lua. Afterwards I use a C++ library to find all other folders in "./Content/", then run their init.lua. After that I just run draw.lua and update.lua which are in the same directory as init.lua, but I run them in no specific order.

 

2) I also thought that it would be an issue, but apparently its not. According to this stackoverflow answer:

in Lua, all the global variables are stored in the global table _G (called environment). Unless someone modifies it explicitly, it is destroyed only when the Lua state is destroyed.

 

I'm not entirely sure if he/she means that variables are available across any files you execute, but if not, I'll compact the three files into one file and make them individual functions ;)

Edited by Orfby

Share this post


Link to post
Share on other sites

1) I do have a algorithm that runs the files, and its a lot more strict than I made it out to be. The way it works is that it first goes to the folder "./Content/Base/" then runs init.lua. Afterwards I use a C++ library to find all other folders in "./Content/", then run their init.lua. After that I just run draw.lua and update.lua which are in the same directory as init.lua, but I run them in no specific order.

 

 

 
So the init.lua scripts from the Content directory run in enumeration order (likely alphabetical order)? Content/A/init.lua will run before Content/B/init.lua?
 
That's reasonable, but awkward if you ever do need to control ordering since it means renaming the folder. This may lead to you naming things Content/zAwesomeMod and Content/qNewSpells or something just to get the order you need.
 
 
2) I also thought that it would be an issue, but apparently its not. According to this stackoverflow answer:

 

 
This is true, but what I was getting at was thinking about the development experience for the user. Relying on the fact that everything is a global in the Lua state means that a script developer will first need to make everything global, can also quietly and easily access the globals from other scripts if they know the name (encapsulation violation) and need to know the names of every global system service provided to them by the engine. It's doable, it's just not the most pleasing system to work with, as a person developing the scripts.

Share this post


Link to post
Share on other sites

I would first come up with your threading strategy to be honest because scripts can mess dramatically with that. If you allow to much modification from the scripts that could for example call or send events to other entities, your threading strategy can become cumbersome all of a sudden or even impossible to do.

 

Scripting is nice but you need to really think about what a script is allowed to do because it can cause conflicts with other systems and/or cause performance issues that are hard to solve all of a sudden.

 

Data Driven en oriented code can give you a lot of the benefits of scripting without needing to have a scripting language embedded in the code.

Edited by NightCreature83

Share this post


Link to post
Share on other sites

in the final analysis, scripting and data driven design are ways to change game code (scripting) or game data (data driven design) faster, with (hopefully) simpler tools and skills.

 

if you do it in code, you need a programmer, a compiler, and build time.  with scripts and DDD, you can get away with a non-programmer, some sort of text or level editor, and no long build times. programmers are expensive. compilers, and related tools and hardware are expensive. 

 

scripts and DDD come with some overhead: implementing the scripting and data driven systems. this is why they can be overkill in some cases.

 

there can also be performance hits from scripts being slower than code by nature, and any additional load times dues to DDD.

(i just added a bunch of mods to skyrim on a low end PC and now get script warnings when the framerate drops).

 

for each method, the "break even point" as to whether its worth it or not is similar: in the long run, what will get it done faster / cheaper?

 

if your data changes a lot during development, and/or you want non-coders to be able to change it, DDD looks good.

 

if your code changes a lot during development, and/or you want non-coders to be able to change it, scripting looks good.

 

also, when designing a game to be modable, scripting and DDD are common ways to let a modder get code and data content into a game.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!