Scripting?

[xahodo]

Perhaps it's a good idea to introduce scripting, to allow for as much flexibility as possible. This could make development on the core engine much lighter.

The core developers could focus on things like pathfinding, rendering performance, threading performance, core rules and making life easier for the scripting people.

The scripting people could in turn focus on things like AI, UI, implementing game play (factions vs alignment), designing monsters, campaigns and spicing up maps (missions, events).

Mapping and campaign design people could find that they have more power at their fingertips.

While scripting has a greater performance impact when it is deeper integrated in the game, it does help a lot with flexibility. Since there are two camps within this project, both having their desires, why not satisfy them both with a nice scripting language?

This article might be of interest in selecting a scripting language.

[svenskmand]

I am also in favor of using a scripting languange -- preferably with a c++/java style syntax -- as this will help mappers and possible total conversion people change the game more easily. But I think it is ultimately up to AndrewBuck as he is the guy coding the game. But I think it is a very good idea to use scripting

[andrewbuck]

Hello xahodo, welcome to our project. It's good to see new people getting interested in it.

As for scripting in the game (e.g. for AI and stuff) I am unfortunately not planning on implementing it. My primary reason for this is simply the speed penalty invoked by using a scripting language (not just from the language itself being slower, but also from the overhead involved in passing game data back and forth between the script). The way the game is designed there is a pretty heavy load placed on the server (to prevent cheating), this means that the server has to be very fast and I think the overhead of it would be too much.

Regarding scripting for level design: I have already implemented several "goals" which can be embedded into a level file (things like KillAllEnemies, ProtectCreature, MineNGold, etc). In the future I plan to add a mechanism where the goals added to a level can contain nested subgoals that are added when a goal is either met or failed. This will allow for campaigns that are quite flexible, without the burden of using a scripting language at runtime.

I hope this doesn't scare you away from our project. I am pretty flexible in how we do a lot of the things in the game engine, but this is one place where I have pretty much made up my mind and it will take a pretty significant reason to end up convincing me scripting is necessary.

EDIT: After looking back at your posts I see you have already been here for a while xohodo, but I don't think I said Hi before anyway.

-Buck

[svenskmand]

Andrew now that you will not go with a scripting system I have another suggestion. We could instead have a graphical scripting system, that is each object you want to script has a node in a graph, and then each edge is a action/trigger one object can perform to another. This way persons with less to no programming experience can make advanced levels and game mods without coding It would also be a cool feature in the game engine helping it to become general enough to make other RTS games in the style of DK

[andrewbuck]

That might work, although it won't be until late in the game development. If you can make up some sort of a mockup of this that would probably be a good idea so we can work out the kinks before it actually gets coded up.

-Buck

[svenskmand]

I will see what I can come up with, I will start with the goals we already have, and then maybe add some more.

[xahodo]

OpenTTD can become quite a processor/memory cache intensive game. Why would something like dungeon keeper be more processor intensive as a game like that?

OpenTTD has a scripting system in place for AI. And dare I say that the AI's of OpenTTD have a lot more to deal with then AIs in this game.

As for cheating: why not force the same game state to all clients. The server is always right.

What I'm talking about is that the server keeps a hash of the game state and requests a hash from each client every X game ticks. If a client returns a different hash, the game state on that system is obviously different and so the client is in error, prompting an immediate correction.

This stops things like money cheats, monster cheats, research cheats, etc. The only catagory of cheats not entirely stoppable this way might be the view cheat.

This can be stopped by making view area changes part of the hash... this does, imply that the server needs to keep track of what each and every client sees, while clients are forbidden of doing that.