Jump to content
  • Advertisement
Sign in to follow this  
sniperslap

Redundant Scripting?

This topic is 3544 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm interested in finding out if my idea can be improved upon or if it's just plain silly: I'm writing a role playing game rules library (generic characters, skills, items, etc...). One goal I had was to make it data driven so that I could load instances of each object with data from files. The one hook to my crazy idea is that I wanted them all to be scriptable -- very scriptable. Most every object will be capable of generating countless events and any other object will be able to register interest in these events and affect...just about anything else! This is indeed fairly broad, and I'm not averse to narrowing it down as I iterate. Because I'm writing the library in C#, I would like to use C# as my embedded language (via System.CodeDOM). Following everything to a natural end, it's starting to look like I may as well skip out on scripting all together and create everything in .dll libraries!? Does anyone have some design advice to help me realize some benefits in having items stored in XML files with scripts? This just seems like something where so many mistakes can be made. Thanks!

Share this post


Link to post
Share on other sites
Advertisement
The problem with such systems, is that they become impossibly complex, due to their flexibility. We develop frameworks to simplify software development so we can understand the software we create and mold it to a given function.

Since you've embedded a scriptable component in your engine and if you provide enough hooks, you can basically do anything, given enough time and imagination, however consider that each scriptable component unless it exist within a very well define framework and hierarchy can have unpredictable cascading consequences throughout the whole system.

Even then how would you tackle the problem of chaining modifiers and logic? How do items in combination affect other composite items etc..

Take a game like Diablo, they have a very well defined item and stats system. Easy to implement basic item properties, stacking properties, etc.. and the only variations will be stats on those properties. Even then, I'm sure there exist billions of possible items and its up to the designers to narrow that down to the hundreds of useful items in game.

Also look at a game like Nethack, which has a highly scripted object behavior ( all the objects scripts are encoded right in the C code however, but each item basically has its own encapsulated logic and after affects scattered through the C code ). Each item was meticulously implemented and playtested over years to find the right balance and interaction. Even then I'm sure there are many bugs left to uncover.

Better to implement a strict well defined framework and build around that, it will simplify and improve the design overall.

Good Luck!


-ddn

Share this post


Link to post
Share on other sites
What I take away from your most excellent response is that I should instead be defining a simple intermediary language that speaks to each game mechanic I wish to be scriptable?

My thinking was that requiring the scripts to be implementations of event handlers would reduce the complexity and narrow the graph enough to allow both complexity and purpose. It would give each script a strict scope and function without giving it a reason to balloon out of control.

Every script would be handled in a well determined sequence, and thus every action in the game becomes it's own sort of pipeline...

Do you think my predictions on the impact are reasonable, or is the system still too broad?

Share this post


Link to post
Share on other sites
Your always going to have a trade off between flexibility and usability. The idea is to get the best of both worlds with the core code written in your base language and content in a scripting language. Also I use .net's built in xml serialization and iron python for scripting because their very quick and easy to use.
It also helps compile time if you aren't cluttering up your code base with dialogue and open the possibility of modding.

Share this post


Link to post
Share on other sites
I am doing something similar to you (creating a generic first person RPG engine), but I am using C++ and Python. That said, when I was considering using C# (as I still enjoy coding it in more than C++ :P), I was going to use IronPython for my scripting.

In my mind, scripting should be as easy to do and as simple as possible. Expecting your "scripters" to learn C#, which can be a daunting language for non-programmers, is not going to win a lot of fans. Allowing them to use something that is much easier to grasp, Python, is probably preferred.

The way I am doing it in my engine, is that I expose a very minimal set of C++ base classes through Boost.Python, and I then sub-class my Python game objects from the relevant C++ objects as required. This allows me to use those objects through the C++ interface contract in C++, and allows me to write speed critical components in C++.

For instance, in C++ I expose a class called Thing, which is the base class for every game object in the system that requires game interaction (monsters, doors, treasure chests, etc). I've kept that class as generic as possible, but in Python, I sub-class from it to create the more complex game objects. Boost.Python allows me to expose pure virtual and virtual member functions to Python, so I can fully sub-class and overload my C++ defined Thing class in Python.

I know for a fact that IronPython allows you to do basically the same thing from C#, but without the need for a wrapper library (as IronPython has access to all of C#'s class meta data via reflection). So if you have an assembly that defines your base C# classes for the game world, you can reference that when dynamically compiling your IronPython code, and then sub-class from it, use those objects and utilities, etc.

Share this post


Link to post
Share on other sites
Well I can't offer much advice but perhaps share an experience and allow you to take what enlightenment you can from it.

I'm currently working on a massively scriptable mud server in vb9 and I'm attempting to go about it the same way you are, namely via codedom.

So far, the raw power of the system is incredible as well as it's ease in working with it.

I've had two problems crop up so far.

1) My engine is slowly being consumed by my compiled assemblies, to the point that my original program is just a GUI wrapped around my DLLs. Obviously I don't want my scripts to have THAT much power (directly screwing with my network I/O for instance). The way I have things wired up right now, a game object could feasibly launch a complete copy of the server and it would work. *boggles*

2) Because I need to be able to modify the scripts at runtime without a server restart, I need some space between my game objects and my scripts. It's very tempting to allow my objects to be an instance of a scripted class, which means I can't change the script without destroying the object and recreating it. This simply won't work, tempting nonetheless though.

I've learned a lot on this project, the most pointed lesson being the amount of self control this approach requires to prevent it from degenerating into one big glowing pile of awesomeness that doesn't do anything useful.

Perhaps these problems are not exclusive to working with codedom, perhaps they are. Either way I'm looking forward to the insights other people share with you as well.

Share this post


Link to post
Share on other sites
Since I think you are both writing MUD servers, and scripted objects in a dynamic environment are important in that arena, you may want to look at some of the other OO MUD servers like DGD and ColdC. DGD is an LPC server with some modern programming concepts sprinkled in. They both may give you guys some interesting ideas.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!