GUI and Networking support

[Archon]

So, I came across this site from a gamedev.com review - and was pretty impressed with what the website was selling. The evaluation kit worked wonderful so I'm almost sold...

 

Two big-ticket items I noticed the website doesn't really talk about are: GUI and networking support.

 

I do see a few community projects that are creating their own GUI system (luaGUI) - but was really hoping that the engine (or library as some have called it) provided something working out-of-the-box. How much work is entailed to get up a simple GUI. I classify simple as supporting your common controls: button, text, radio buttons, check boxes, slider bars, images, etc.

 

I've come across a forum post talking about the Leadwerks limited networking capabilities. The post mentioned that it could be adequate for up to 64 people - are there any benchmarks or statistics to enforce that? Does the engine provide sample client/server code?

 

I would investigate this myself - but I do not believe the evaluation version gives access to the project creation tool. I did come across the Wiki, but I am hoping there are more built-in capabilities than just "2D Drawing".

[AggrorJorn]

LuaGui is only for simple and for quickly creating a menu. The SDK however comes with a fully completed GUI for Lua: boxes, dropwdowns, sliders etc.

Plus there are also a couple of users who use CEGui. Have a look in the documentation section. There is a tutorial on how to use it.

http://leadwerks.com/werkspace/index.php?/page/resources/_/programming/cpp/leadwerks-and-cegui-r30

[gordonramp]

The SDK however comes with a fully completed GUI for Lua: boxes, dropwdowns, sliders etc.

 

Where is that in the SDK Aggror, I can't find it?

[macklebee]

it was released with 2.31 and had some small examples with it.

[Mumbles]

For the networking, it really depends on what language you are using. BlitzMax has it's own in built networking and C/C++ have a whole range of networking libraries available to use. (Some of them are totally free)

 

But I wouldn't worry too much about networking right from the start. Best bet would be to first, have single player, playable demo of your project. This way, when you come to implement the multiplayer part - if you have to rely on a external library, and you don't understand it, you will probably find that more people are prepared to help you integrate it.

[Canardia]

It wouldn't make much sense to have networking in the engine, since everyone prefers a different network engine. I use a extremely fast and optimized error correcting UDP MMO network engine which can handle thousands of users, but others prefer RakNet because it is bloated with other stuff also. Besides, adding a network library, or any other of the 10-20 additional libraries every game needs is daily routine for any C++ programmer. You just drag the lib file into your project, add the #include header line and that's it.

 

AI is similar also, and most people associate pathfinding with AI, although it's a completely separate function. AI means for me how an animal behaves when you approach it, or when it sees you.

[Mumbles]

but others prefer RakNet because it is bloated with other stuff also.

 

You have such a way of writing... I'm sure people weren't just drawn to the fattest package on offer...

 

But adding to the point above

 

It wouldn't make much sense to have networking in the engine, since everyone prefers a different network engine.

 

Indeed true. As I prefer the reliable TCP for things like setting things like the client's name, handling client pings, setting your player ID, etc. But for the most part of the game (as in, the moving, attacking, etc.), I use the much faster UDP, and without any added reliability or packet sequencing. After all, TCP can already do this without passing its overheads up through all 7 OSI layers - and for anything that does use UDP most of it gets through without any problems anyway.

 

TCP's "reliable" description gives UDP a bad name. I don't know if there's an official figure, but I'd say it feels like UDP delivers over 99% of it's packets correctly, first time. Indeed Quake 3 used UDP as it's communication protocol, and yet, you hardly got warped back to previous positions due to packets going missing. UT however employed a TCP model, and again, you didn't feel to get warped back to an old position after a severely delayed packet had arrived. Very different communication models, but to the casual player, no one ever noticed the difference. So, there's no right protocol to use, it's all down to personal preference. And using a third party library lets you do just that...

[Canardia]

UDP doesn't need to be reliable, and indeed the reliable UDP option is quite useless as it tries to fix old messages which nobody wants anymore. I have a much more optimized UDP error correction, which just takes the newest message, as the game can live without getting any messages for a good time also. In the MMO I'm planning, there's no big difference if you are online or offline. When a player goes offline, his character will keep moving and acting using mimic AI, which does similar things as the player would. For example jumping when walking And in fights, the AI would cast the spells which the player usually casts too. When in a group, the player would follow the group leader and assist on the main assist's target.

[Josh]

Given how badly networking code ports across platforms and how little our professional users care about these two features (they usually already have some library they want to use) I am not too worried about the decision to not focus on these. I think we will eventually have some built-in official solutions, but it's not a high priority. I'd like to focus on what we do best, and not try to recreate libraries that have already been done and aren't that difficult. The GUI will be implemented at the script level. Building that into the core engine doesn't make sense to me.

 

I do have some network code that is a little unique, and it is really handy for syncing entities across a network, but I am not ready to reveal it.

[Flexman]

Given how badly networking code ports across platforms and how little our professional users care about these two features (they usually already have some library they want to use) I am not too worried about the decision to not focus on these. I think we will eventually have some built-in official solutions, but it's not a high priority. I'd like to focus on what we do best, and not try to recreate libraries that have already been done and aren't that difficult. The GUI will be implemented at the script level. Building that into the core engine doesn't make sense to me.

 

I do have some network code that is a little unique, and it is really handy for syncing entities across a network, but I am not ready to reveal it.

 

Is there any Entity.SetKey(...) callback for helping to sync entities? When it receives a key locally it can decide to pass it through the network?

 

I'm currently doing this via MessageReceiveCallback(..) which has a wee bit of code to decide what to send where. On the whole that seems like a good place for it but sometimes you just want a couple of keys to sync.

[Archon]

The Leadwerks community almost makes buying this product necessary; it seems like something I would like to be part of...

 

But for myself as a professional software engineer - timeis what is important (damn over-time). In the days of high school and college you don't have much choice of utilizing free/cheap software. Now that penny bank isn't so tight, so paying that extra cash for a nice GUI or Networking layer is highly worthwhile.

 

While using third-party software is a possibility, the integration often generates more work and problems. If someone has worked out those issues (such as CEgui), then thats one step closer to ideal. But, if I find a solution that has CEgui (or another) integrated nicely with an editor, well I may very likely open my pocket book to take advantage of doing less work for myself.

 

I also fully believe in focusing on your core features - better to have a few that stand out then a bunch of mediocre capabilities. Products like Ogre take a stance on only being a rendering engine - thus focusing on what they do well. This product states that it is a game engine, so from my perspective those core features include networking and GUI - which seem to be a bit lackluster.

 

Don't get me wrong - the presentation of the product, marketed features (rendering, lighting, etc.), tools, and the community do make this a great product. The less time I have to invest on working on the engine and more on the application - the better.

 

Is the documentation of the API publicly available? I didn't come across it on the Wiki/Support pages.

[Rick]

You are exactly right. The debate of if Leadwerks is an API or an engine has happened a few times in the community. I for one find it to be an API. It lacks certain features to be an engine when compared to the other engines out on the market today. If you want to make straight games and don't mind using a predefined structure for how to do that than LE isn't the right product yet. 3.0 will most likely provide this but currently it's not there. It's completely open ended and more structured for you to make your own game engine currently. The Lua implementation however is a step in that direction of defining a game structure. Most of the programmers here (myself included) love that it's open ended because we generally like to control such things in our games, but it's not for everyone.

 

The wiki is located http://www.leadwerks.com/wiki/, but I'm not 100% sure if you can view it if you don't have the license.

[Mumbles]

The wiki is located http://www.leadwerks.com/wiki/, but I'm not 100% sure if you can view it if you don't have the license.

 

Wiki is viewable by all. The test to prove it is to log out first, then follow your own link...

[Archon]

Yes, I can get to the Wiki. I just wasn't sure if that was the entire API.

[Mumbles]

All the commands are listed there, but a bit of a gripe of mine is that when you click the "examples" link for most of the commands, it's just blank.

 

But watching the video tutorials on the wiki front page mostly cures that. The only reason I refer to the wiki now is just to check the order of the parameters. Yes, the IDE will show me this, but the wiki page explains what each of the parameters means, so I'm more likely to give the correct variable for each parameter.

[L B]

I planned to start a easy to use C# networking library that will integrate seamlessly with Leadwerks soon, I'll keep you posted when I do

[Guest Red Ocktober]

It wouldn't make much sense to have networking in the engine, since everyone prefers a different network engine.

 

sorry guy... but i have to wholeheartedly disagree here...

 

networking logic should be built into every aspect of every object in whatever engine you decide to make with Leadwerks...

 

i use Torque's networking implementation as a prime example... all apps are either server or clients, even single player apps... and everything (most of the game stuff) happens on the server and is 'ghosted' to the clients...

 

all actions are sent up to the server and distributed as necessary...

 

all dynamic objects are synced across the simulation...

 

this makes everything so much simpler... prediction so much cleaner and understandable...

 

 

just my opinion...

 

 

--Mike

[Rick]

I agree with Red, but the implementation should be 99% transparent while programming. I didn't find Torque's implementation to be that good/friendly. With things like commandToClient() or Datablocks I just wasn't a fan of it. The idea is great, but if it could really be abstracted from the developer it would be nice.

 

From what I remember with Torque if one called a client function with commandToClient("SetScoreCounter") the resulting client function would have to prefix itself with clientCmd like below. That's just ghetto

function clientCmdSetScoreCounter(%score)
{
ScoreCounter.setText("Score:" SPC %score);
}

[Josh]

Agreed. I think something like SyncEntity() is ideal, where it is just automatic, and then other info would just be raw data. Physics and entities are the only part of networking that I think the engine should have a heavy hand in.

[VicToMeyeZR]

UDP MMO network engine which can handle thousands of users

 

Whats the name? Would like to look at it