Jump to content
  • Advertisement
Sign in to follow this  
UnoriginalGuy

Scripting the guts of my game?

This topic is 3826 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

After finishing a few normal games in which the logic was entirely compiled into the main executable I am thinking about changing things up for my next project and wondered what you guys thought... I'm thinking of using an off the shelf scripting language and instead of writing the actual game logic within the main executable I'll just develop a batch of functions and scripting in most of the "content." This will cost me some time at the beginning of the project but when I come to debug and develop content I should see a huge saving. At the moment I have to keep on compiling, testing, changing, and that cycle costs me a lot of time. If I was using a script or set of scripts I could simply have it clear state and reload. Debugging will also be easier because it should be much more apparent if it is a content problem or a engine problem. Do you guys think this is a wise road to take or a huge time sink?

Share this post


Link to post
Share on other sites
Advertisement
Ever since I started to use Lua my productivity changed dramatically. I find it much easier to write pure game code. There have been times where I have gone weeks without re-compiling my executable. In fact, the thing that annoys me most is that I didn't start out by using Lua, I had to port lots of functionality from C++ to Lua. Right now there are still some things that I would love to have scripted but I don't have the time or inclination to change them now that they essentially work.

If you are reasonably experienced - which you sound given that you have finished a few games - I would highly recommend it.

Share this post


Link to post
Share on other sites
This might be a silly question but where is your line between executable and script functionality? I mean how privative are the functions in the main executable? For example do you handle level transitions on the script side or simply ask the engine to import it all?

Share this post


Link to post
Share on other sites
Well, my game is Asteroids, but so far the executable (for the most part) doesn't know it [grin]. Well, apart from the menu system - that part would fall under the category of "some things that I would love to have scripted but I don't have the time or inclination to change them now that they essentially work". [smile]

Right now, the graphics and "physics" are handled by the executable. The scripts can create Entities, add images to them, set the rotation, position and speed, collision geometry etc. The executable notifies Entities of any collisions that occur. It moves them every tick and calls a scripted "update" function for each entity. There are lightweight entities, called effects, that have no "physics" or collisions and are used for purely graphical things e.g. Text and a minimal HUD, explosion animations and the starfield that is the background.

Level transitions are handled by the scripting side by removing unwanted entities and creating whatever other ones. There is a single function, StateUpdate, that is called every tick independent of other entities, this is where things like checking whether a new level is required is done.

There are a number of things I am unhappy with because the scripting system evolved from a C++ version (e.g. currently an Entity can only be associated with a single image), but overall I find it much easier to work with than the C++ original.

Of course, it depends on your game. I like small 2D games, so I doubt I would notice performance wise if pretty much everything had been written in Lua. If you are writing a fancy 3D game, you might need to put more thought into what is and isn't scripted, e.g. pathfinding, etc.

My project has moved from everything in C++ (Lua was originally used for configuration) to all the game logic in Lua and the rest in C++. I think its easier for the executable to be primitive. It can be relatively easy to port stuff back to C or C++ if you need a speed boost, but it is very difficult to justify re-writing C or C++ in Lua unless you can get some concrete advantage from it.

What kind of game are you thinking of making?

Share this post


Link to post
Share on other sites
Quote:
Original post by UnoriginalGuy
Do you guys think this is a wise road to take or a huge time sink?

It is generally wise to make your programs data-driven. Just like anything else, you can make it a time sink by over-engineering.

First consider the obvious examples of art, maps, levels, and sound: You don't directly code graphics models and audio samples. You don't hard-code the full environments of buildings, dungeons, levels, or whatever else. Although it is possible with extremely simple games like Pong that only require a few graphics primitives and beeps, it is impossible for larger games. Your application should load resources at runtime. They can be modified independently by anybody with the proper tools.

Next, let's look at ui elements. They are partly graphics that must be laid out, but they also require some code to work with them. Again, it is foolish to hard code the positioning and layout of every menu screen, ui animation, every HUD element, text formatting, and everything else directly in code.

It isn't that hard to make exporters or converters or other tools so that you can lay out your game in one tool, like Photoshop or The GIMP or Maya or custom level editors, and use the converted scripts directly in your game.

It does require some integration between art (or sound) and code, but once the integration is complete, the final details can be worked on by somebody else, or by you without requiring a code rebuild for simple data changes.



This same situation applies with scripting of game logic. You must remember that scripts are still essentially code. They must be debugged. It is good to have a way to check them for errors, validate them with a tool, edit them, and so on. The more things you do with your scripts, the more they become a full-featured programming language. Taken to the extreme, this makes your game engine into nothing more than a script interpreter. Unless you want to make script compilers, IDEs, debuggers, profilers, and so on, you are best keeping it simple.


The right balance between script code and compiled code is something unique to each project. A carefully written game can even reload the script data (and other data like art and sounds) mid-game, enabling rapid development of new concepts at the beginning, and fine-tuning later on.

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!