The New Engine & LUA
Rokiyo
A.K.A. .::FeX::. Revenge Join Date: 2002-10-10 Member: 1471Members, Constellation
A.K.A. .::FeX::. Revenge Join Date: 2002-10-10 Member: 1471Members, Constellation
<div class="IPBDescription">Will we see LUA-driven UIs & client scripts?</div>Was just randomly pondering the new engine, and had a vague thought waft through my head:
Now that we have a shiny new engine, will you guys be moving even more stuff into LUA-controlled territory? For example, all that VGUI stuff? Console commands? Client-side scripts?
If there's anything I've learned from WoW, it's that a greatly customisable client front-end is extremely cool and useful.
Now that we have a shiny new engine, will you guys be moving even more stuff into LUA-controlled territory? For example, all that VGUI stuff? Console commands? Client-side scripts?
If there's anything I've learned from WoW, it's that a greatly customisable client front-end is extremely cool and useful.
Comments
We can be reasonably certain the engine will be able to cope with this, matchmaking only equivalently modded installations. So you'll see a list of "pure" servers, a few for each popular mod and then the odd server that allows a free for all, each type listed separately. You might even get "certified" mods that get listed with the same level of promotion as "pure" servers.
I am more concerned with how fast LUA scripts will perform in the high performance world of twitch FPS gaming. C++ is used in source because it is so very quick, even amongst compiled languages. Replacing all that C++ with LUA worries me that it's going to slow down performance. I'm sure LUA is fine for hundreds or even thousands of lines of code, but I can't see it scaling terribly well when it comes to the hundreds of thousands of lines that it will take to implement the NS2 game code. I imagine Flayra will end up shunting some of that back into the engine for Max to optimize, namely the AI for he bots.
It's absolutely perfect for the game logic; this is just reacting to events that take place (kills, deaths, tech choices, etc.). In addition, you get the added benefit of not having to deal with null-pointer debugging. The only way Lua could slow things down is if it gets mixed into anything related to the real-time aspects of the game, which I really don't think they're going to do.
Even then, Lua is not to be underestimated; it's one of the fastest scripting languages available ( <a href="http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all" target="_blank">http://shootout.alioth.debian.org/gp4/benc...ll&lang=all</a> ). I have used it to write code that runs every server frame for a Quake2 server (frames occur something like ten times a second), doing admittedly menial tasks like continually updating player positions, but I've noticed little-to-no performance impact.
You raise a good point about the client-side stuff. I don't know how much scripting support the client will get, but at the very least, I hope they design a GUI system that presents a front-end that is backed by code at the server. This would allow you to move all that !rtv, !rank, etc. sort of stuff into a nicer pop-up. This would seem to be justified just for the commander's menus, so perhaps we'll see it. I am guessing the client will be kept dumb and will get no support for reflecting on the game world via scripting.
Now that we have a shiny new engine, will you guys be moving even more stuff into LUA-controlled territory? For example, all that VGUI stuff? Console commands? Client-side scripts?
If there's anything I've learned from WoW, it's that a greatly customisable client front-end is extremely cool and useful.<!--QuoteEnd--></div><!--QuoteEEnd-->
Hey Revenge, long time no type.
Yes to all the above. Everything "above" the level of entities and basic player capabilities is in script. All UI, console-commands, client effects (things like build/health circles currently), gamerules, the tech tree (both how it's set up and the tech tree implementation), weapons and just about everything that makes the game "NS" is in script. Want to make a new structure a new alien class? You can do it in Lua. Heck, you could probably make a totally new non-FPS game without too much work. This is one of the things I'm most excited about - seeing what kinds of crazy stuff you guys come up with.
To give you an idea, here's a random screenshot of my Decoda showing the names of classes that are currently in NS2:
Ok, looks like there is a hell of a lot of fun to be had in there... Will a player be able to modify his own client and make it unique from other clients on a server? If so, how far are you going to let us run with this ability? For example could a fanatical gorge lover rebuild his UI around easy access to the structure placing commands (for example, he adds a key that gives him a movable mouse cursor, and a bunch of clickable buttons on his screen for each of his building options)? Could a marine commander with 2 screens cover his 2nd screen with an info panel that displays the status of his marines & structures?
In the meantime, I'm gonna go off and daydream about fully functional marine dropships, redeployable turrets and those armor plates on the alien defense chamber actually blocking bullets...
So we're heavily encouraging modding, but we're making sure that the default experience is the unmodified NS2 game. You will always know if you are playing modified or unmodified. Also, I imagine we won't be allowing client-side additional modding even when you're playing some custom community gametype.
There's a big difference between modded *gameplay* and modded *interface*.
I don't think anyone would object to a function that allowed you to customize the UI, although if you added that feature, you wouldn't need to whitelist it.
Still, it seems like it would take less manpower on your team's part to whitelist a function than to add a new feature.
So we're heavily encouraging modding, but we're making sure that the default experience is the unmodified NS2 game. You will always know if you are playing modified or unmodified. Also, I imagine we won't be allowing client-side additional modding even when you're playing some custom community gametype.<!--QuoteEnd--></div><!--QuoteEEnd-->
Vendetta Online is an MMOG that has some powerful client side scripting with Lua. You can completely customize your experience from the HUD to the chat interface and create new 'features'. For example you can create a 'proximity' warning that will tell you exactly who has come near your ship rather than just a plain proximity alarm.
The developers have however 'hidden' certain functionality from within Lua so players can't create client only add-ons that give them an enormous advantage.
So in the instance of NS2 a player could completely modify their HUD to show a countdown between reloads, or perhaps add a percentage of the CC's health or 'mark' locations on their HUD and have the distance to that location show up. They might even be able to add a target-rectangle around visible aliens or an enemy that you attacked (so you won't mix them up with an enemy you didn't attack when you're being rushed).
They would not however be able to access the health of another player, display the location of everyone in the map on their HUD or be able to 'cheat'.
For Vendetta Online this works out very well, mostly because of what type of game it is, but I think a similar approach could be fashioned for NS2.
<b><u>Summary:</u><ul><li>Players can do minor to advanced client side modifications that include displaying reload times for their weapons, marking locations on the HUD, 'skinning' the HUD, display a target rectangle around an enemy you have just attacked, basically anything that pertains to 'them', other than movement speed, setting their health to different values, etc.</li><li>Players do not have the ability to access/modify things like player health, location, weapon, upgrades etc.</li></ul></b>