Exult beyond U7?

[Madoc]

I'm very interested Exult as a platform for new games (either with or without the U7 graphics). As far as I have seen, it is already possible to develop a completely new game, with a new storyline, new NPCs and so on from scratch, using the Exult Studio. You have done more than great work on this, and to my mind, Exult is the most mentionable U7 fan project.

However, U7 was pretty limited, especially when it comes to usecode. Fans of Ultima-like games probably want to have a game that allows more complex dialogues, a more "realistic" world and so on. In order to realize this, usecode is not sufficient.

Now comes my question: Do You consider to develop Exult beyond the technical limits of U7, or would You support such a development by someone else? I am thinking of a richer usecode, maybe cross-compilable from other programming languages, with an engine that would be "downward compatible" to run the old original U7 code.

[Gradilla Dragon]

Maybe you should take a look at engines like ika then.

http://ika.sourceforge.net/

That one uses an actual programming language for the scripting, and it's much more flexible.

[Madoc]

The problem that I have with such engines: I'm a coder, not a musician or gfx person. Those engines usually come with pain-in-the-eyes, manga style graphics and terrible music. (Okay, to be less impolite: Those engines, along with their default graphics and musics sets, are perfect for doing something like Legend of Zelda, but not for western, Ultima-like games.) U7 has exactly the kind of "default" graphics that I like. And moreover, I took a look at the code of the engine and found it very well coded, comprehensible and extensible. More often than not, I'm having problems with the code of open source projects. It usually does not take long until I find the first few obvious flaws or even bugs. Not so in Exult...

That's why I would prefer Exult as a base for building a new game on.

[drcode]

I'd certainly be interested in enhancing Exult's capabilities. Keep in mind that our 'usecode' is a made-up language, so we can expand it pretty much any way we want, and the same goes for the 'intrinsics' that let you access the engine.

[SB-X]

In what way could usecode be "richer", and allow a more realistic world?
I'm assuming you're not just talking about coding style, and would just prefer to use some other popular language. I'm only a usecode novice.

[Gradilla Dragon]

You are misjudging Ika. It's way different from all others. It's not an rpg construction kit like RPGMaker and other sucky game kits.


Bad points: It has no music, graphics, sound or anything, just the tools for developing games. The tools aren't even integrated. It doesn't even have a save format of its own.

Good points: It allows you to create pretty much any kind of game, although it gives many facilities for RPGs. You are the one to define the savegame format, deciding what to save and how to store it, since you have access to a great deal of things. It uses Python, which is not complicated and gives you an enormous degree of flexibility in what you can do. You can create your own gameplay types, and having several of them in a single game (imagine for example having an U7 gameplay and then temporarily switching to platformer gameplay for a special minigame or something).

[Madoc]

@SB-X:

First of all, I see a division between the usecode "virtual machine" and the programming language used to generate the usecode "byte code". If there is a clear interface that allows creation and serialization of usecode opcodes, You could create usecode compilers for different programming languages. (Although I think it would be a bad idea to have many different programming languages; this would just confuse people.) The usecode PL and the VM could be developed and maintained quite independently from each other, just in the same way like in Java or .net.

When it comes to RPG development, I have a lot of ideas that would require a lot of programming. Of course, I'd like to program in an object oriented way. However, this does not mean that the underlying "usecode VM" would need to be object oriented. All object methods can be compiled to be functions, and the OO thing would be just an issue of the programming language. One could add features to the programming language such as interfaces and abstract methods that would not even appear in the generated byte code.

But I'm not sure wether this would make sense for Exult, it's just an idea that I'm currently thinking about. Some considerations however would make sense, like for example:

- As I understood, current usecode has a limit of definable functions. Why not break that limit?
- It would make sense to make usecode modular. To achieve this, it's obvious that the assignment of numbers to functions must be managed by the compiler in the linking phase. Otherwise, one could not use another developer's module if it defines function numbers that are already defined in another module.
- Why not allow dynamic creation of objects / memory allocation? - Well, one should keep in mind that it might lead to memory leak problems...

If You consider the second point especially, the idea comes up to invent a layer between usecode "byte code" and the concrete programming language; a kind of "intermediate language". It could be a first step to create and implement this intermediate language.

But as I said, those are only vague ideas of mine. I need to think about them and find out wether or not they make sense.

[Madoc]

I forgot one idea, and it's freaky: Whoo, what about calling some machine code from a usecode script? Something like a "usecode native interface"? Then the real fraggles out there could write their code in C++ and call it via usecode.

On the other hand, one might get killed for such an idea. I know that.

[Madoc]

@Gardilla:

I'm sorry, I must confess that I did not pay enough attention to ika. I will take a closer look on it some day though.

Currently, I am really overwhelmed and fascinated by Exult. It has by default all the graphical features that I would like to have, and I'm free to attach my own code and ideas to it. I can even download the source code, and it's really well programmed. That's a rarity in open source projects. The compiler is extensible, and that gives me that twitch in the fingers, urging me to extend it.

[Madoc]

@DrCode:

Thanks for that statement. So I'll probably ponder over Your code on this or the next week-end.

[Gradilla Dragon]

With ika, you will rarely ever need to touch its source code. Ika is written in C++. The game scripting is done with Python, but you aren't even limited to that. There was a game done for the 2003 Christmas game making competition, which included a binary dll written in C++ in order to have a special snowing effect in OpenGL. That dll is loaded from within the game scripting. You have access to your whole system from within the game scripting, since you are using a real programming language.

This is the game:
http://ika.sourceforge.net/files/winter-27-dec-2003.zip

Notes: I think you additionally need to download some additional DLLs from the site. Also, the snow effect dll is for Windows systems and unfortunately the source was not provided.

Oh, and there was a fighting game for the 2002 Christmas game making competition:
http://ika.sourceforge.net/files/ultima ... terx10.zip

[SB-X]

Could you make a set of intrinsics to import functions from a DLL?

[artaxerxes]

I'm not speaking in the name of the group, just my own. Exult has always tried to be portable across many different platform. Having a DLL import intrinsic would kinda kill that feature, don't you think?

Artaxerxes

[Madoc]

@Artaxerxes:

Surely, You are right. If a native interface would be provided, plaform incompatibility would be lost. That might be a killer argument.