🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Scripting & Multi-Threading

Started by
0 comments, last by Jx 21 years, 10 months ago
So... i''m thinking about going down the path of adding scripting capabilities for the AI in my engine. The reason for doing this is because, at present the specification (that i''ve given myself) calls for easy addition of new units to the game world in expansion packs or similar. Therefore I want users to be able to completely design new enemies (or helpers) with their own specific behaviours. Anyway - the point of this post is (and I must a admit, I know not alot about scripting) a) should I run my scripts in a thread (this is what i think should happen) and if so b) What happens if I have say 25 game entities all on screen at once? Surely I can''t have 25 threads with 25 VM''s running at once? Actually, whilst writing this post, I''ve come to the conclusion that I wouldn''t need to do this... Ok, how about this then: Each game entity has set functions that it calls every frame for example UpdatePosition etc. Could I just implement these functions in the script, let the C++ code know about them and call those functions specifically? OR is there a better way all together.... I''m pretty much decided on python for my scripting langauge btw. jx
Advertisement
What you''re describing in the latter half of your post is a lot like a "state machine". Basically, the entity has persistent state, which it uses and (possibly) changes each timestep. STW for plenty of information about this.

Personally, I dislike state machines for certain AI activities; it just isn''t optimal in some situations. For those, I would suggest a multithreaded model.

Now, here''s something cool: depending on how you''re doing it, you MIGHT NOT ACTUALLY NEED TO USE REAL THREADS. Both Python and Lua now have support for non-preemptive multitasking(or "coroutines"). Basically, you call a script, which does stuff, and then voluntarily passes control back to your program, saving information about what it''s up to. The next frame, your program reactivates the thread of execution, and the process continues. You can have as many coroutines as you want.


Don''t listen to me. I''ve had too much coffee.

This topic is closed to new replies.

Advertisement