The Ur-Quan Masters Discussion Forum

For a while now I have been trying to design and implement a dialog system that will be able to do all the conversations in UQM without anything being hard-coded. So far I haven’t had much success since each time I get the design to a demo form I find something done in UQM that throws it off. I also want it to be rather simple and easy to edit. So I decided to ask for some input from the devs.
 
If you were to try to make UQM’s dialog logic to be non hard-coded how would you go about this task?

Would you want to transfer the logic to some kind of scripting language?

Would you want to use OO programming?

A scripting engine might be best. However, it could be difficult to implement, as the game was never designed with this in mind (Kinda like network play...)

The only real reason I can think of to do this would be to allow greater flexibility in modding (i.e. don't need to recompile UQM to change dialogue); translations should work fine with unmodified dialogue logic. For similar reasons, one would probably want to move the entire adventure game logic (triggers, items, et.c.) into something easily modified.

Python and Perl, for example, integrate quite well with C (and C++) programs and would be naturals for moving functionality out into an interpreted (or at least pseudo-interpreted; many implementations of these are just-in-time compiled) language. Civilization 4 (http://www.2kgames.com/civ4/home.htm) (warning: Flash- and music-heavy official site) uses Python for most of the gameplay rules and part of the UI, and I prefer Python's syntax over Perl's.

What difficulties are you having?

As far as I can tell, all you should need are:

1) string set (flags)
2) string-> integer map

Both of which are readable and writeable by conversation, and are maintained persistently.

When you enter conversation, the engine loads the map with your current position, position in-system (if applicable), position in planetary system (if applicable) and the date and the composition of your fleet and what modules you have. These last can be encoded in integers, even if there is no obvious mapping.

When the conversation is over, the engine checks to see if any of these have been changed.

This should cover the cases like being given ships, being moved from one place to another, time elapsing, and so forth.

What else tripped you up?

My main problem was that I was programming it so all actions could be handled in a fashion where I would not use scripting. But I was not able to design a system capable of handling all the actions that can be done. So I have decided to redesign it with scripting as a primary component. My main reason for trying to do that way was I wanted the whole campaign to be created from a nice GUI app.

It seems to me that the script is one of the things in which scripting is least of a problem.

That would have been interesting, almost a game in itself that is about creating other games. I can also see how that sort of a system would be very difficult to design, though.

Bioslayer, I love you, you know I do. However, I still think you've bitten off more than you can chew. First and foremost make a little game with hard-coded game logic. Get SOMETHING done. Then, once you've done that and understand what a scripting system would require, the intricies and interconnectedness of all things, then try to make a scripting system.

That's my 2 cents.

With my own game-design work, I've found it's actually quite easy to devise a scripting system.

Consider a conversation node 'foo'. Now, node foo has several conversation options. If you say the option labelled 'bar', then you never again get to say 'bar', and some global flag is set. If you say 'quux', you go to a different node.

Here is how I would represent all this in my quick and dirty scripting system.


I used a system very similar to this one for a FF knockoff I've been working on. It's surprisingly flexible, especially when you allow more general consequences and conditions like +cash:20 (gives 20 zorkmids), -cash:30 (takes away 30 zorkmids), ship:overworld15,20 (moves the ship on the map 'overworld' to square 15, 20), +item:wooden_sword (gives a wooden sword), =item:wooden_sword (checks for posession of a wooden sword), etc.

If you want to have variables presented as text (your credit with the trader), that could be indicated by $key_in_that_integer_map, for example
which retrieves the value stored in the melnorme_credit variable.
you could change it by using +melnorme_credit:30 or some such construction.

I haven't done that, but that's just because I decided to make stores and such a separate behavior than conversations.

i am also looking at coding a dialog system like the one from star control 2 and havent had much luck but can say :

the method in the source of UQM is very messy