Extent of scripting and modding possible

Well, there is numerous topics already about how controls/UI/various automation should be handled. As we have, obviously, very broad audience here, it seems to be nearly impossible to reach consensus about how, where and how far various thing should go.

For example, look at "Defining Micro" thread which, along the line, also disregards any idea of automation.

While I'm not think that it's worth to spend any effort on advanced AI for auto-dodge (which is far from trivial, especially with scale - tons of agents (units)), I'm strongly opposing any explicit ban for such automation.

What I suggest I believe to be silver-bullet for all this talks and issues, and SupCom already has it - client-side mods and scripting, which doesn't need to be installed at server/every player in network game.

My suggestion is to make it little broader that it was in SupCom, allowing actually refinement (to extent of complete redesign) of game menus, options, input handling (allowing to set hotkeys for absolutely any command in game) AND control of anything player may control, with addition to any information player may get.

I believe that this will equalize chances for those gamers who may click ultra-fast and have will and time to train such skills and those gamers who has slow reaction. Yes, this will reduce fast-clicking skills usefulness, is a game about strategy, not about beating 30 tanks with your 20 tanks by using your tricky hands (but being a mod it means that anybody will still be able to play "hardcore" games with this mods disabled. Probably some lobby UI for querying/forbidding particular client-side mods in particular session will help).

And, as free bonus, it will actually allow community to forge and refine number of most popular interfaces, which Uber may ship-in with game at release (well, some crazy people may even disable strategic-zoom feature, for those who dislike it for some weird reason).

P.S. Side note - while, of course, it would be nice to have scripting engine in some popular language like Lua, it would also vital to have strong C++ API for hard tasks like AI, with ability to temper with GPU/engine's task manager at some extent.

P.P.S. Yes, Uber already stated that they will build a very flexible game allowing very high degree of modding, so this question/suggestion is more about where border between client-side and server-side modding APIs will be. Taking in account that generic AI will be, most probably, implemented in server-side part, possibility of client-side helper AI is not so obvious question.

Possibility of full UI redesing with "legal" modding is also not so obvious.

It's important to keep in mind that by making certain UI mods powerful enough that they'd be restricted from "hardcore" use could result in fracturing the community into groups, depending on which mods are used. While this isn't a problem for mods that add new units, features, or conversions, for a UI mod it can get particularly extreme.

A better result would be to consider, if a UI mod is powerful enough to change gameplay to the extent that it would need to be restricted on "hardcore" servers, then either that mod should become an unrestricted standard in the game, or the functionality should not be available on the UI mod level.

I'd like to say that the interface of FA was also fully changeable. You could simply bypass the normal UI completely and implement your own.

That's what I said - there would be, definitly, border between server-side and client-side mods. We are speaking about client-side mods here (additional units and features are server-side mods). What I've suggested is to restrict use of various mods in particular game session, i.e. for one match in custom game properties. If some player would have such mods installed, they would be simply disabled for that match. This is to satisfy "hardcore" starcraft-able players, so they could have fun too. But I don't expect this feature to be overused.

Yes, as I said, SupCom already had that (and, probably, PA would have it too), but it's only UI part.

P.S. BTW, full-pledged client-side AI with GPU calculations capability, taking into account scale and features, would be perfect playground for R&D in gaming AI. It would be even possible to make special PA-AI tournament, like those with tanks.

We are in the process of figuring this out. The current design goal is to have the UI implemented in a scripting language so that people can make custom UI mods. Whatever language this ends up being will probably be used for the entire front end. We would then expose underlying engine bindings that we used to write our own UI so people could replace or add to it. I do have something in mind but we have a bit more research to do before I make any announcements. Feel free to speculate and maybe I'll use your idea instead

whatever it is I hope it's turing complete. Or at least let's us write functions.

I've heard some pretty low bars for turing complete so be careful what you wish for

I hear PHP is turing complete these days. :?

....... haha but seriously please no php :|

Well lets see Lua wasn't bad, it wasn't great either, but oh well.

Java or even JavaScript could be an option. Especially if everything was handled by overriding or inherited methods. So the system would have an onHit(Obj weapon) function that works fine on it's own but someone could write their own onHit(Obj weapon) that would do what they wanted it to.

Also as someone who would like to try their hand at making single player content It would be nice if we had some in game triggers. So for example we could draw out a region on a planet and have a function get called when the player moved x units of type y into the region. Or get a function call when the player built x number of y building, or blew up x number of y unit.

I have no idea how you could make a truly open ended trigger detection system. Maybe you could have an upkeep function that ran once a second, or whatever time interval wouldn't bog down the game, once every framestep would be brutal! Then someone could override it with their own code. And every possible kind of thing that is happening in the game is being kept track of in a myriad of session variables, or there could be a ton of get() methods. Then in the upkeep function someone could add their own checking triggers.

So in the upkeep function someone could write if(Player[3].getNumUnit("Engineer") > 9){myTutorialMessage("You just made 10 Engineers");}

on the (off-)topic, as long as you don't have the human players submit to a Turing test, that would probably reduce the player community dramatically.

thats little bit new for me. Actually you need an alphabet, an input and output and of course an process. The alphabet gets through the process from input and out to output.If its turing complete, you can do all with it. Its just not able to say that for everything is a turing machine, but well I guess i know what you mean.

Whatever you do, please don't use Javascript.

Would the UI side be able to ask the server to run some functions? For example, calculating some pathfinding, ballistics and such ; I can imagine some people wanting to improve the units behaviours or create new states/orders, so re-using server-side functions instead of re-writing them with scripts could be interesting.

C++ for everybody!

Bah! Assembly, know your machine! :twisted:

Prolog fools!

http://en.wikipedia.org/wiki/Prolog


Also as an aside Eclipse is free ..... Microsoft is charging for Visual Studio now. Sooooo java is looking pretty good right about now.

Bleh on Eclipse. That's one clunky IDE.
Vim + makefiles/cmake = proper development.

NO JAVA. I have programmed in a lot of languages and I hated Java the most. I have also worked in many IDEs and disliked Eclipse the most. So if it's java, I won't be modding it...

Hey, Neutrino, thanks for answer! Your plan is very cool, but it is more question about how much engine API you are going to expose.

As soon as scripting language is initiator for all tasks, while C++ code is used for all heavy-lifting (with, please, C++ api to extend this "heavy-lifting" part) (i.e. script decides when/how to process input and what to output (render), including all 3D and 2D drawings) - it should be able to do almost any reasonable task. But, AFAIK, most of scripting virtual machines tend to be single-threaded (non-reentrant) by design, which makes this scheme rather idealistic.

IMO, it's absolutely vital to be able to:

• Mess with any possible setting (graphics/audio/input, etc) from scripts to allow user-made options UI.
  
• Ability to add new generic commands/interfaces/actions/you_name_it and bind them to hotkeys (i.e. user/script-triggered actions. It could be actually callback scheme when input handing is done in C++ code and then binded to script/C++ module functions, implementing particular tasks. From giving unit orders to handling factory queue, such tasks).
  
  By generic I mean that you may have same interface, like "awesome.move.unit", which is binded to RMB with inputs "unit, position". Any module may register itself either as provider of this "awesome.move.unit" (only module actually implementing move, but it may delegate it for other modules), listener for actions on this interface or user.
  
  I.e. old-good message/event bus pattern, used for centuries for similar tasks.
  
  This will allow some level of polymorphism, allowing easy replacement of particular functions or bindings without full-scale rewrite of existing implementation.
  
• Full-scale 2d/3d drawing API for drawing both HUD (on-screen display) and 3d-elements like beacons or plan-markers.
  
• Ability to bind particular input-events (key press/release, mouse press/release) from particular screen regions to specific script functions.

I may think only about some kind of OOP approach for UI part, with widgets, keyboard and mouse handling, relaying all real job and non-handled input to this "interfaces"/message-bus mechanism. This would be "initiator" part, while "interface" providers are "callback" part.

As interface provides could be easily implemented in both scripting and C++, it will also allow to implement some mod parts in C++ for performance reasons.

Standard interfaces, as well as mod-added, could be separated to server-only, client-only or common. In addition to different API exposure it should be more that enough to prevent abuse, while not building any explicit barriers for any-scale automation.

About languages - it's not big deal, but please (please!) make it possible to:

• Reload functions/scripts/resources without complete restart (Python < 3.0 can't do that)
• Use external editor (There is a bunch of games with only-internal editor (X-series, for example). This is crazy).

I personally may only add that Python, while being cool for UI tasks in particular, is, IMO, very harsh in terms of memory management and constantly producing memory leaks (as most game engines using Python tend to disable garbage collection until load/reload, and Python's ref-counting behavior is far from clarity).

I've seen Lua, Tcl, even Lisp in some games. But Lua definitely seems to be very common option, due to it's low interpreter size and code footprint (luakit.org realization), making it very easy to tweak and hack language for your own needs. (ActionScript is second common choice for UI tasks, btw).

P.S. To be extremely revolutionary, you may try to use Erlang in your engine. It could prove itself very cool for game tasks due to lightweight threads and prolog-inspired logic-oriented syntax (which is very cool to build FSM-powered things). Until you start using strings, that is =)

P.P.S. Calm down guys, Java is not scripting language. (BTW, JavaScript has nothing common with Java but name). And as soon as external editor supported - any kind of IDE or build-system will make the trick, so what bid deal?

Angelscript seems to be fairly popular with some game developers, most notably for the way it interfaces with C++. It's also apparently pretty quick in terms of performance.

Now I'm not openly vouching for it, since I haven't used it myself (yet), but I've seen it work nicely in several games, so it is worth looking into.

OK yeah these are a lot of really good points. I guess we should just go for something with a low memory footprint that executes as fast as possible.

As someone coming from Ruby: Use mruby!

https://github.com/mruby/mruby

http://geekmonkey.org/articles/36-an-in ... -mini-ruby