Balancing Scripting and Hardcode
BlitzMax Forums/BlitzMax Programming/Balancing Scripting and Hardcode
| ||
| I'm interesting in using LUA in my level editor and game engine. As i design my engine in theory, i often ask myself "where's the balance". I want to make a 3d action flight game and i want triggers. I want triggers that are physical and ones that aren't. Triggers that are general purpose and ones that are specific(for easy of us and visual icons). This make perfect sense for a scripting language. Now the issue comes in..how of the game should actually be scripted. Bullets? Ships? Controls? I'm deciding to maybe take an unreal approuch and almost make the hardcore just for intense math, collision, graphics, and music. If i have a ship type..with properties such as speed, health, ammo.. should that be in the script or in the hardcode? I start to think about how many "linking" functions i'll have to make from blitz to LUA and that's alot of time as well. On top of that, scripting isn't fast i'm guessing. I've researched LUA and i've thought about the complexities quite a bit... Having one variable in one script access another. Saving state and so on. So i'm here asking where's the balancing point..for one programmer? |
| ||
| No one..i guess i might be on my own here. |
| ||
| I'd offer some advice but this is really dependent on what you're making. As I'm making something akin to GameBench, only the rendering, math, entity code, etc. is hardcoded -- anything that would benefit greatly from being left in the core runtime. I've left in the option to use DLLs for game code as well, so really it's up to the user how they want to go. |
| ||
| I plan on using scripts for future, larger games to allow players to tinker with things, but for current, smaller ones, I'm hardcoding most things, having just a few user-editable data (text) files to allow players to change unit stats, icons, and the like. In larger teams, where it's not convenient to rebuild the project with every change during development, scripting is good for the designers since it allows them to adjust things in-between builds. But since I'm the only programmer (plus handling all designing <g>) for these projects, and it's easier to just rebuild, the only reason that I see for me to use scripting is to allow players to mod the game after release. YMMV. |
| ||
| i'd avoid using script if i were making a game (an therefore the engine to run the game in)... but, like Wendell said, if i wanted to allow the users to mod or tinker he thing, i might consider adding scripting to the game... --Mike |
| ||
| I agree with scripts being most useful for modders. It really depends on the scope of your project. For me as an artist, scripting is handy, but its most useful when its embedded in your level design and modeling tools, but still accessible externaly in an IDE so that coders get to play too. Unless your scripts can be compiled in some way, they can be slow, and not really ideal for defining gameplay, advanced AI and what have you. |
| ||
| I'd go with scripts and files to define stuff all the way. Stuff that you can edit in notepad. |
| ||
| depends on what you plan on doing with your game. If you're goal is to make a re-usable framework/codebase scripting makes a bit more sense. If you're making a one-shot game that you don't think you'll be modding/editing extensively, you will save much more time just hardcoding the gameplay and other elements into the game |
| ||
| I'd offer some advice but this is really dependent on what you're making. And equally important, who you're making it with.I think the balance is to expose as much of the interface as is nessecary/requested. The advantage is that the closer to Grey Aliens position you are, the less often you'll have to recompile/restart. Depending on the size and market segment of your product, this could be a real factor. |
| ||
| thats very true er, Flameduck, Torque takes about 10 minutes to compile. Wouldn't want to do that more than a couple of times a day :) |
| ||
| Torque takes about 10 minutes to compile. Wouldn't want to do that more than a couple of times a day :) Compiling isn't nessecarilly the only problem. Loading and populating large data sets could take more than an hour (one I used to maintain took nearly 4).Scripting allows you to swap/patch stuff while the system is running. Sometimes, downtime isn't an option. Oh and wrong Mikkel btw. |
| ||
| I almost want to use scripting to govern game rules. Damage amounts, rates of speed, tutorial triggers. AI behavior( not the AI calcs..just behavior series). Have a infinite spawn of enemies until an objective is met. Involving timers and having different pathes branch from them. Just dynamic craziness that'll just be a mess to hardcode because you'll be making so many special cases. I want to have a door open and then the AI get scared and run off. Imagine programming level 3, room 4, door 2, if door opens.do this. I mean, it's almost rediculous. In all seriousiness..i don't want people to really mod my game..i just want to make a good cinematic game that reacts to things that are happening with the character and enivornment. |
| ||
| It's definitely a plus if you do get a scripting engine working with your game. It can save hours of re-compiling. What you're asking for is alot of work for one person though... Good luck with that venture |
| ||
| Torque takes about 10 minutes to compile ouch, that would drive me nuts with lost productivity. One neat feature Delphi has is a syntax check that doesn't compile, but reports any errors - really quick and cool.Anyway, for me, it's not so much the recompiling issue which I why I'd use scripts and files, it's so I DON'T have to alter code, I can use files in notepad, and copy paste sections, and give them to other people to fill out, and have editors filling them out etc. |
| ||
| Does it still take 10 minutes if you do a quick compile, ie keep pre-compiled parts? |
| ||
| I'm not sure whether I'll use scripts. It depends what kind of game, how responsive, how much time you have from the CPU/GPU and other factors. When you think of scripts you probably think of interpretation and all that. That's the part that makes it slow. However behind the scenes each script command is already a piece of hardcoded code, so it's not as if it's going to be way slow. I would keep the stuff that the user really don't need to be messing with for hardcode and script the rest. ie they dont need to really have scripting for collision detection or display rendering. Let em choose what objects and where and what they look like and the timing etc, but that's enough. |
| ||
| Basically using scripts/files means that you actually have two layers on top of hard code. One is the actualy files, and the second is the structures you read (and parse) them into. It's these structures that they game uses to decide what to do, otherwise it would be dog slow, reading files each time... |
| ||
| well i'll load the scripts into memory at loading time. I'm thinking each object has a general script that gets ran. Type mavObject field Script:String (blah blah) end type Then in the hardcore..when this generic object is accessed, it'll run the script at one is present. Making a cinematic game is important to me..if i can't do it now..then i rather make practice projects..then a game with a bigger team. I just know what i want my game to be. It's like a movie director is working on a game. |
| ||
| I think Grey Aliens structure suggestion (command tree ?) is a better (as in perfomance) solution. It's also slightly more complicated to code, but I think in the long run, it's probably better for it. |
   |