|
Socoder -> Concept/Design -> Scripting in a game... |
|
| Fri, 04 Jan 2008, 19:39 | |
HoboBen
|
So far I've got settings, 3D maps, object properties, and console commands all loading and parsed on automatic. I have one beast left to wrestle: Object Scripts. I was thinking of loading them all in advance, "compiling" them down to stuff like opcodes, handling constants and stuff at that point. Then I'm going to stick each line into an array and then do something like parse one-line of each script per main loop, procedurally. Surely there's a better alternative than that? Or maybe, set up event listeners for events specified in the script like "playerx > 10" or "objecty < 10" which are checked every loop but the script is only acted on when one of the events is picked up. Ideas? Each object's script will be running in isolation. Maybe a redesign would be better so that just one script controls everything, and runs from the player-perspective instead? I'd prefer not to go this way though, because it would introduce a lot of repetition instead of being able to define object behaviours (e.g. specific A.I.s, doors, lifts) just once and then plug them in anywhere as I can with my object properties scripts (e.g. crates, barrels). -=-=- blog | work | code | more code |
| Sat, 05 Jan 2008, 00:50 | |
Cower
|
Use Lua or another scripting language of your choice. Attach a (scripted) function to each entity/object that is called upon update. For example:
|
| Sat, 05 Jan 2008, 12:15 | |
|
HoboBen
|
So parse the whole of every script every loop? Sounds a bit demanding. Assuming I did though, how would I store it in the code? An array of lines inside each entity type? -=-=- blog | work | code | more code |
| Sat, 05 Jan 2008, 13:18 | |
|
Cower
|
No, Lua would load the script and compile it at runtime so that it's in its most optimized form. As an interpreted language, it's probably the most common and optimized for use in games. There's also Python, but in my experience it's not really well-suited for game code (the C API isn't, anyway). Writing your own interpreter, while a nice exercise, isn't really a good idea. If possible, and since this is possible, you should use an existing solution written by people who understand the subject far better than you or I. If you're using BlitzMax, Lua is already accessible via Axe.Lua. If you're using Blitz3D, you'll have to be a little crafty, but it's possible to use as long as you can come up with a method to get around the lack of callbacks (use a messaging system, write certain parts of your game logic in C to handle it, etc.).
|
| Sat, 05 Jan 2008, 13:36 | |
|
HoboBen
|
Writing my own is half the fun!  I'm using Cobra by the way - it actually got released
-=-=- blog | work | code | more code |
| Sat, 05 Jan 2008, 14:19 | |
JL235
|
I agree that you should use Lua because it was used in FarCry and Homeworld 2. Certainly shows it is industry standard. However if your really interested in building your own interpreter, it isn't as easy as it looks. I wouldn't imagine how I'd go about doing it in Cobra as there are tools such as JFlex and CUP which I use for generating the parser Java code for my interpreter. Although it's possible to write it all from scratch, I would hate to build it myself and it would be no where near as powerful and efficient.
|
| Sat, 05 Jan 2008, 19:48 | |
|
mindstorm8191 |
HoboBen: I think it all depends on what you plan on doing. I was working on an invaders type game a while back, and to control the enemy appearances and boss movements, I decided to use a script. It didn't have to be anything complicated, I had each line with a description of what it did, followed by 0 or more pieces of data. I was able to construct whatever enemy types and movement patterns I needed with the script. The program parsed the script, and everything had a predetermined purpose in the interpreter. Most of the script simply filled out data structures for the program, which did their own thing in the game. You don't always need something complicated to get the job done. You don't need to make scripts look like language code. Even while loops and condition checks can be done in a simpler manner, if you ever need them. Just keep it simple! -=-=- Vesuvius web game
|
| Sat, 05 Jan 2008, 20:20 | |
|
HoboBen
|
You're right about keeping it simple; I'm not after a Turing-complete scientific mathematical scripting language or anything. I could just have the scripts with a bit of data and say "right, that's a door, so I'll hardcode "case object.type = OBJECT_IS_A_DOOR then actLikeADoor()" and that would work. I've done that in 2D, where things are quite simple in that you can usually be sure that there's so many types of enemy, that act in a finite number of ways. But I'd quite like to have a proper scripting solution. Honestly, most of it I've got written already to parse that sort of data. My map data, settings-reader and object property definitions both share 90% of the same code, and just call the same exact functions in a slightly different order, sticking the results in slightly different places. My console shares the same IF/ENDIF conditionals function, even though it works completely differently otherwise. So that part is all out of the way. I'm hoping when I'm done that everything is flexible enough that I can create brand new games changing nothing but these text script files. (Alright, maybe paying for a real artist! )Before I start on the proper physics engine, this is the last thing to get out of the way.  There won't be much to check. Variables for Player XYZ, Object XYZ, Player-Object Distance, Object Health, and a perhaps (once the basics are done!) script variables so that the object can have a memory, and "functions" for move object, destroy-object, parent camera to object, and parent object to camera. That's not too ambitious I hope, just a few things which will be still able to make the scripting quite robust in what it can do. Still not sure how best to run it in real-time though. I might go with the setting up listeners for if-statements, so that things are only parsed in real-time when events become true. -=-=- blog | work | code | more code |
| Sat, 05 Jan 2008, 20:49 | |
|
HoboBen
|
Hmmm, it's not going bad actually. I'm planning it out and it looks like I've cracked what to do. The syntax is as ugly as anything though. Cause I'm hacking everything into the same reusable functions, instead of: It's an ugly Because it's just less work! There's hardly any to do, now that I think how easily it will just piece into what I already have. Adding variables here might mean duplicating one of my units word-for-word almost though, unless I come up with a dirty solution. |edit| I just thought of a dirty solution!  Yeay! |edit|
-=-=- blog | work | code | more code |
| Sat, 05 Jan 2008, 22:31 | |
|
HoboBen
|
I think I over-thunk it! It got easier and easier as it cleared up - it barely warranted another function (though I don't begrude adding one; I want to do fancy things like macros in here) Here's the initialisation code, that's working perfectly. (everything is read into the listener type now) And now there's manageable 2-4 lines per listener to be parsed each loop. I just need to get that wrapped to the same functions, and I'm done! (apart from variables, but I have a better idea for those, and they can be shared by all listeners on an object.) Blimey. I might cheat on having complex statements (AND/OR) in listener conditions though, and brute-force it with two listeners sharing a flag. |edit| I'm not going to quadruple post! But holy catfish, batman; it works! I mean, really, really well! |edit| -=-=- blog | work | code | more code |
|
|
| |||
|
| ||||