Writing a programming game, not sure on the best approach

[BlackRider]

I'm working on a simple battle-bots type game to help me develop a scripting system for a much larger project I've been dreaming up over the past few years.

My main focus here is to build a fast & robust script engine that can run several hundred scripts while not becoming a bottleneck in a 3d RTS game. Each robot/unit in the game would have its own script as its AI and the player can change/expand on it in-game. I would like a C styled syntax, but I'm not set on that.

The problem is that I've never done anything like this before and I'm feeling rather lost. Will an interpreter that parses each line of code at run-time be anywhere near sufficient? Should I compile it down to assembly or machine code and run that through the interpreter? Is there a way I can compile it into machine code and run it directly through the CPU instead of an interpreter?

The simple game I'm writing should help me determine how fast it needs to be and help me determine how many instructions per script per game update I can run before it becomes a resource hog.

Any direction would be appreciated.

P.S. I have taken some inspiration from the game Colobot. It was a lot of fun, but a little too simplistic.

[XMEN Gambit]

You could experiment with (and take apart) the java program for Robocode.
http://www.ibm.com/developerworks/java/ ... -robocode/
http://robocode.sourceforge.net/?Open&c ... d-robocode

In the game, you program your own tank-brain modules and turn 'em loose in an arena against each other. It's not quite what you're looking for but it's bound to be one of the easiest to understand. It's had time to get the kinks out and lots of documentation is available as well as the engine itself.

You say every unit in the game would have its own script. I suggest you revise that so every CLASS of unit has its own script. And when you're processing, you process units by class to take advantage of caching. If you need some unique units (heroes, etc) you can have individual classes or sub-classes for them.

[XMEN Ashaman DTM]

Some examples of a scripting engine would be Lua or Squirrel. Lua is a personal fave of mine.

I'm not sure where you are going with your scripting engine, but I would heed Gambit's advice. Also pay attention to the fact that you can't go wrong with something that works like Java (compiles to byte code), but remember that if you are finding that you are having to put so many hooks in your executable for the script, that you may just want to rewrite those scripted portions into the executable.


And if you are still going to build your own, you might want to figure out some unique way of doing things that justifies rolling your own engine. You'd definitely need more than just a parser if you need complex behaviors that can't be broken into simple rules.

[BlackRider]

Thanks for the info. I have actually been looking into Lua, but for my initial 2d demo/game I've decided to use a simple assembly language. It hurts accessibility, but this project is a combination of a learning exercise and a testbed for my next game project. So it's not really something meant to be distributed.

Hopefully I'll have something by the end of this week that's functional enough to demonstrate what I'm talking about.

*edit* Sometimes I wonder if I'm too A.D.D. for this.... I went to look up one little thing to help finish my Game State Manager and wound up spending more than two hours reading about various pathfinding algorithms... and that's not even something that'll get hardcoded into the game!

[BlackRider]

Hrmm... things are going slower than I had hoped. I decided to complete my degree and so school work is eating a lot of my programming time. Plus I've been having some issues with my game state manager and probably won't get to the graphics code until Saturday at the earliest. But I think I'll upload some of my UI and other concept drawings tonight or tomorrow.

All the easy parts are turning out harder than expected. Hopefully all the hard parts will be easier than expected.

[XMEN Gambit]

All my cynicism and experience says, "nah." But I try not to let that stop me, so you shouldn't either.

[XMEN Ashaman DTM]

Just do what major defense contractors do:

1) Make an unrealistic/optimistic schedule.
2) Stick to it.
3) When you run into trouble:
3a) complain
3b) ask for schedule relief
3c) ask for more money
4) ???
5) Profit!
6) Get the project somewhat completed and ready for spiral upgrades and/or block upgrades depending on the development model. (F-16 was crap until the block 30 upgrade.)
7) Defer doing any of the hard stuff until later when you can charge more on a contract mod or new bid.


Blech.

[XMEN Gambit]

Yup, that's the way it works. I think that's the way contractors work in pretty much all sectors, though.