3
\$\begingroup\$

I'm programming a Side-Scroller, and I've reached the point where I need to program the enemy behaviour. I don't know what I should choose between hard-coding the enemy ships' behaviour or using a scripting language.

Going with the hardcoded way, all different kind of enemies would be different classes derived from an abstract EnemyShip class with a virtual function redefined for each of them. Going with the scripting instead I could do just a base class and a script manager which moves the ships as needed.

What should I do?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ Why do so many people think that Lua is an acronym? It's a proper name; it's Spanish for "Moon". \$\endgroup\$
    – Nicol Bolas
    Commented Aug 30, 2011 at 18:20

3 Answers 3

Reset to default
3
\$\begingroup\$

If you want a lot of different behaviors, go with Lua.

If your behaviors can be determined by some boolean (Aggressive, follows target, ... ...) go without.

Between the two I'd go without also (say 16 enemies and 4 bosses for example I'd hardcode all that).

My two cents are that scripting is usually for scripters, not for coders so if you feel comfortable with the language used, stick to that language, if you don't (and maybe you will want to add enemies months and months after the development was finished) you might want to go with a scripting language as it is definitely more secure than breaking up old code...

\$\endgroup\$
1
  • 1
    \$\begingroup\$ ps. if you really like the idea of learning how to add LUA to a game, go with that. LUA is very cool (lightweight and fast) IMO. \$\endgroup\$
    – Valmond
    Commented Aug 24, 2011 at 12:43
2
\$\begingroup\$

I'd go LUA every time. The fact is, even if you aren't a scripter, it's simply easier to change a text file and run the game (especially if you can do this runtime) than changing something and waiting to compile.

And then you get the added bonus of learning LUA, making it easy for people to mod, etc. etc. etc.

There are more articles on how to do this than you can ever read, so, just go with LUA, you only win ;)

P.S. When I say LUA I mean any scripting language. LUA is just the de-facto industry standard.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ +1, Whenever it is possible to externalize from code a potentially extremely iterative process, go for it. Once hooked up to LUA (Looks hard, its not really) making it so you can reload a script while the game is still running is fairly trivial making this a much quicker process than recompiling every time you want to change an angle and/or velocity to see how that affects the movement. \$\endgroup\$
    – James
    Commented Aug 24, 2011 at 23:05
  • \$\begingroup\$ Yes, basically Game = Content (textures, enemies, levels, scripts, menus, etc) + Engine (rendering sys, physics sys, sound sys, etc). Anything that can be externalized to data should. Period. \$\endgroup\$
    – pek
    Commented Aug 24, 2011 at 23:50
  • 1
    \$\begingroup\$ Not always true, a small game doesn't need the overhead of LUA. I'm not talking about code or memory consumption but the fact that you must use two different languages and that when you are in the LUA part and you need a new fonctionnality you have to implement it in C++ (say), link it to LUA ant then use it in LUA which can be more complicated. Otherwise I'm with you there :-) \$\endgroup\$
    – Valmond
    Commented Aug 25, 2011 at 7:03
  • 1
    \$\begingroup\$ @Valmond: The "overhead" of using a different language is easily made up for many times over by the faster development you get out of it. You can make it easy to restart a level almost instantly, reloading all of your scripts. This makes the cycle of "make change, test, did it work?" much, much faster. And that is far more important than the minor issue of having a new language. \$\endgroup\$
    – Nicol Bolas
    Commented Aug 30, 2011 at 18:22
1
\$\begingroup\$

In my experience, LUA can be great for small scripts that control a single entity's behaviour. Not needing to compile the scripts means that you can iterate on the behaviour very quickly, making small adjustments and reloading the script to immediately see the new behaviour. When you start getting into complex logic, however, it is invaluable to have the structure that is enforced in languages like C++. Having a compiler and a debugger to catch problems can save you a lot of time.

In your case, it sounds like you are thinking of having your AI driven by your compiled language (i.e. at a high level, managing the game state and the entities therein in C++ or some similar language), with the behavioural logic for individual ship types in LUA. That seems like a sensible way to go. I would not, however, try to have the entire game's state handled by LUA - it could make it incredibly difficult to debug.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .