New engine please

For developmental things relating to the graphics of the game.
User avatar
2020
Outside Corner Grinder
Posts: 1322
Joined: Thu Dec 29, 2005 9:21 pm
Location: the present, finally

Re: New engine please

Post by 2020 »

The kid is playing Agario. Have you played? Of course there are swear words all over the place. The difference is, it is just a name, whereas chat is the issue. And chat enables deeper engagement.

We came up with a solution before, and Z-man set up school server, I believe. But I never got a chance to use it. This child-only area, or policing chat, they are tricky issues.

Hey Sinewav, sounds good. So, no movement made wrt money in the community?
hold the line
User avatar
sinewav
Graphic Artist
Posts: 6413
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: New engine please

Post by sinewav »

2020 wrote:Hey Sinewav, sounds good. So, no movement made wrt money in the community?
Nah, the community is now just a small handful of players and about half of them are rotten people. The game is static. Although, positive change can happen quickly, so I keep my hopes up.
User avatar
Jip
Round Winner
Posts: 397
Joined: Sat Sep 26, 2009 5:32 pm

Re: New engine please

Post by Jip »

For the C# lovers:
MonoGame (https://github.com/mono/MonoGame) is not really an engine but a framework.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: New engine please

Post by Z-Man »

Jip wrote:Looking for python? Allready tried Godot Engine?
Someone has. I think that's the thing that was pitched to us on IRC a bit back; I found a binary of it in my download folder.

I have looked at it now, too. And yeah, it would do fine. It's not as pretty as Unreal or Unity, it completely lacks reflections and fancy post-processing like Screen Space Ambient Occlusion. But reflections can definitely be added (in my job, I forced reflections into a completely uncooperative visualization system that neither gave me control over texture coordinate generation nor full control of the camera projection matrix, Godot does that and has cubemaps and render to texture...) and SSAO is just a shader you can write yourself or steal, the question is whether the Z-channel of the finished render can be accessed, the shader needs it. Or we could wait for someone else to implement it. The development community looks healthy enough.

On the very plus side, Godot game code can be C++ OR the very Python-like GodotScript and bindings between the two are relatively easy to set up. GodotScript was developed with precisely that in mind. And it supports multithreading. That beats Unity hands down in my book (C++14 made me love it again, rembember?). Godot does matrix multiplication the right way round. I didn't check the other two, but the industry standard is to get them wrong. The price for having no garbage collector (even Unreal has one, it just operates on whole game objects and is therefore not so big a performance problem) is that Godot uses pure reference counting of its core objects, which means that you can create leaks even from script by creating cyclical references. So don't do that.

Godot supports development on Unix, Windows and OSX. Targets are those and also IOS and Android and browsers. You naturally can build for Linux and Android on Linux. With regular cross compilation, you can build for Windows. With a bit of black magic, you can even target OSX. And if you open a portal to all seven dimensions of hell, you can even compile for IOS on Linux. Of course, you only need that if you have C++ code; if you just use script, you can deploy your game just like that with the right template, say the docs. Unity and Unreal require a Mac either way and development on Linux is not officially supported.

Godot also wins with the best documentation page ever.

Godot is MIT licensed, so of the engines brought up here that I can remember, it would be the only one where we would have a chance of integrating the source we already have. Unreal is Open Source as well (yes! A change since last time we spoke of it, I think.), but it's not Free and the License explicitly says you can't publish your product under the GPL. So best we could do there would be to publish the game in a way that the users combines the GPL parts and Unreal parts on their own, which would be too cumbersome both for us and for the users. Won't fly. Unity has the same legal problem there and the technicalities are two or three notches worse.

So, more musing. Porting Armagetron over to Godot would give us a better look. Not as much of a boost as Unity or Unreal, but at least it'll move the game into this century, possibly even decade. It would give us basically free scripting, though the usual problem remains: How would we sandbox scripts so they can be safely downloaded? Well, relatively simple, possibly, the list of bad things scripts can do is limited.
We'd get rid of a couple of dependencies right away: autotools, SLD*, GL, GLEW, FTGL and freetype are all immediately replaced by in-engine stuff. boost::thread would also be quick to replace. That leaves only libxml2 and protobuf and the boost header only libraries. That's not a bad immediate build complexity reduction (for stuff we manage ourselves, of course Godot itself is not entirely trivial to build).
To get to mobile and browsers, we'd either need to integrate the remaining libraries into our build and include them, they need to receive the same cross compilation treatment... the header only boost libs would be fine as they are... Godot has some rudimentary XML support, I don't know if it's fully functional. Does not look that way to me. We could finish that work.
But I fear that may not be the correct path there. If we need to give up protobuf, we'd give up compatibility (sort of, all servers and clients still can talk using the old non-protobuf protocol, we'd just have to not remove the old protocol as originally planned). And we're using xml for maps and cockpits. Both would be translated to just Godot scenes, which are serializable, so you can just directly use them. So the right way to get rid of libxml, I think, would be to just get rid of the systems that use them and replace them with better ones that fully use the engine's features. Best of all, as long as the server supports both the old XML map format and the new scene based format, it can translate on the fly for clients that don't understand the XML any more.

As far as I can see, that would be the best way to go from where we are to a better place without making too many hard cuts on the way. Of course, the idea of the better place would be exploding user numbers again, and that automatically means the relative number of players who would be negatively affected by hard cuts is minimal in the best case scenario, and in the worst case scenario we run the thing into the ground and nothing matters anyway. So hard cuts may not be such a bad thing.

I might make a simple, GodotScript only proper 90 degree turn local multiplayer only test project. We'll see. Apparently, I have the time and energy to write meandering posts for two hours, so who knows? But first, I'll do the ball balancing ultra-simple game I wanted to make for a year or so.

And yeah, I also had extended looks at Unreal since they changed their licensing model to the current one (Zero cost for folks like us, full access to the source, permission to modify it as you please). It's basically as FOSS as it can get, considering someone wants to make mad money on it from people doing big, expensive projects. And it's really, really good. The C++ editing is well integrated with the editor, is my programmer's view standout feature. For a new project, I'd personally strongly consider it before Unity in all cases. It's a bit of a function of project size in terms of world/level size and budget for art; the bigger the project, I think, the more I'd default to Unreal over anything else. The hardware requirements are no joke, though. First time loading here takes 30 seconds or a minute.

Unity has lost my favors a bit. I don't hate it, it's still pretty well done, but I guess they really gets on my nerves with their overall strategy. Possibly something to do with their new boss, probably confirmation bias... You have to pay to get rid of their splash screen, and they hiked the price for that on the new editions, you essentially can now only rent the thing (you own a copy after renting it for a period of time, but essentially the price for that has tripled). They have a good serialization system, but to prevent abuse, it's not accessible to users. On the one hand, I can understand why they do that, but on the other, it drives me bonkers. And I'm not hearing good things about the stability of the editor when large projects are loaded. And any problems you find, you can't fix yourself.
Monkey
Match Winner
Posts: 759
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: New engine please

Post by Monkey »

Z-Man wrote:Godot is MIT licensed
The MIT licence is fantastic for a game engine; we couldn't wish for a better licence really.
Z-Man wrote:Unreal is Open Source...but it's not Free....It's basically as FOSS as it can get
Epic Games wrote:Unreal Engine is now FREE. FREE for game development. FREE for Virtual Reality.FREE for education. FREE for architecture. FREE for film.
From what I can see (https://www.unrealengine.com/eula), Unreal Engine is neither open source nor free. I don't want to be pedantic but I feel these things are important. :P
Z-Man wrote:Porting Armagetron over to Godot would give us a better look. Not as much of a boost as Unity or Unreal, but at least it'll move the game into this century, possibly even decade.
I don't want to go off topic but I'm very unconvinced that Arma's graphics is the reason we don't have many users/players. I'm not against having a new engine, it's just that I would like you guys to choose the right one (one that ticks all the boxes or as many boxes as is possible). I have my concerns about all three engines mentioned above but I'll stop for now. Of course I know that I'm not an Arma developer and you guys have the final say, however I do feel the need to give my two cents. :)
Playing since December 2006
User avatar
sinewav
Graphic Artist
Posts: 6413
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: New engine please

Post by sinewav »

Monkey wrote:...I'm very unconvinced that Arma's graphics is the reason we don't have many users/players.
I agree and disagree. I agree because I think there is a limited audience for this kind of game in general, which keeps the population low. I disagree because there are certain graphical elements that Armagetron should definitely have. With every game, expectation versus reality and first impressions are a big factor. When people want a "TRON" game they not only expect good game mechanics, but visuals too. The aesthetic of TRON is a big deal.

I boast about having played nearly every lightcycle game in existence (up until a few years ago when it became impractical). Armagetron was always low on my list. It wasn't until I decided to play online that I got hooked. There are just so many better looking variations, and if you just play local games then more often the choice of "which lightcycle game?" comes down to graphics. Does the game look like TRON? Being able to immerse yourself in an environment is important.

Amazingly, much more than a decade later TRON 2.0 still looks fabulous. One reason why is the spectacular lighting effects. Hey, remember the Bloom Mod for Armagetron? The subtle effect is really powerful. And it's not just the lighting, but also the textures, gauges, and textual elements. Arma's default set is almost comical. I understand the need to distance the game from Disney's IP, but really, that Rim Wall is garish. And the 0.2x HUD looks like something out of a 90s flight simulator.

And if that were not enough, there are some definite usability issues when it comes to the menus. I mean, not horrible issues, but we can learn a lot from the last decade of UI/UX research and make small improvements.

Since I've moved on to to 0.4x with my own textures and modifications I forget how clunky Arma looks until someone posts a screenshot. I can't say the game is aging well.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: New engine please

Post by Z-Man »

Monkey wrote:Unreal Engine is neither open source nor free. I don't want to be pedantic but I feel these things are important. :P
I read the license. You can get the full source, you're allowed to modify it and distribute binaries from it, you can share your engine modifications*. There are restrictions to the sharing. How you license your own game code and data is your own business**. Stated that way, it's not too different from the LGPL, except that the nature of the restrictions is different***. That's open source to me. And if you don't make any money and make sure nobody else can make money from your product legally, you owe Epic no money. That's free. Now, of course, I vastly prefer the restrictions of the LGPL and GPL and any other proper FOSS license to those of the Unreal Licence, and the Unreal License definitely is not Free, capital F. I stated before that I think the GPL's Freedom is not the freedom of people, but the Freedom of the software to find new developers. Unreal definitely does not have that.

(*) you don't have to, though. Unless your modification is integration of an additional scripting language, then you have to share it in source form. Odd.
(**) caveat: the royalties are per product, not per licensee. So if you give away your source and assets for free and someone else builds your game and sells it, you may be the one having to pay the royalties. So avoid that.
(***) (L)GPL's restrictions are aimed at keeping the software Free, while Unreal's restrictions are aimed at not allowing anyone to cheat themselves out of paying royalties.
Monkey wrote:I don't want to go off topic but I'm very unconvinced that Arma's graphics is the reason we don't have many users/players.
It's a reason, but I don't think it's the main one. It also would not be the main reason for a switch to an engine. The main reason for that would be that ideally, a proper engine would allow us to develop features faster. Take the UI, for example. Every engine comes with UI frameworks that are ready to use. You click together how the interface looks and then hook up your buttons, sliders, checkboxes and whatnot to your code. You also get a fully featured 3D level editor for free.
Monkey wrote:I have my concerns about all three engines mentioned above but I'll stop for now.
No, please go on! What's bothering you about Godot in particular? Of the things they do, two things bother me:
- there are memory management macros for C++, and apparently, the delete ones are required, deletes can be canceled. I'll stop worrying about them if I can manage to wrap them into an allocator. I suppose internal objects that don't interface with the engine can be managed by regular shared_ptr and unique_ptr.
- signals/events are identified purely by their name string. So if you have a typo there, you only notice it when triggered events don't reach your handler. It's unavoidable that in the duck typed scripting language, some errors only crop up at runtime, but my making events, say, some kind of per-class regular members like functions, the errors could be caught at event registration time. Softening that complaint, you can of course create these things in C++ yourself and in the script editor, event names have auto-completion.
Other than that, every design decision on their part that I know about looks alright to me. Not having tried it too much, I'm worried about bugs and finding out they simply don't do <critical feature X> yet.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: New engine please

Post by Lucifer »

Z-Man wrote:- signals/events are identified purely by their name string. So if you have a typo there, you only notice it when triggered events don't reach your handler. It's unavoidable that in the duck typed scripting language, some errors only crop up at runtime, but my making events, say, some kind of per-class regular members like functions, the errors could be caught at event registration time. Softening that complaint, you can of course create these things in C++ yourself and in the script editor, event names have auto-completion.
Sounds like a worthy contribution to the project would be a preprocessor that either checks or generates the code needed, similar to Qt's tool (whose name I've forgotten).

Does Godot allow you to write the UI with the scripting language? That would be a huge plus for me. UI does not need to be high performance, and the widget code that does need to perform well is already implemented in C++, or at least it sounds like it is. Other obvious places for scripting: AIs, Zone logic (the C++ objects can keep internal counters as needed and just make them available to the script to read). It would even make CTF much easier to implement.

As for serializing, I say we don't leave protobuf if we don't have to. You've written a network layer that works really really well for this particular game, and I'm not seeing somebody's general-purpose network stuff working as well, but I would be interested in testing somebody else's stuff and possibly contributing to make it work better for us (and hence helping it work better for everyone who uses it).

I didn't look at the Godot webpage. What's their release schedule like?
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
Monkey
Match Winner
Posts: 759
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: New engine please

Post by Monkey »

@sinewav and Z-Man
Let me put it this way: If Arma suddenly had awesome graphics but nothing else had changed, do you think more people would be playing it? I don't. We may have to agree to disagree on this one.

@Z-Man
I think it's clear we have differing views on what constitutes an open source licence. That's fine. I still don't like the Unreal licence, whatever type/class of licence one may call it.
Z-Man wrote:GPL's Freedom is not the freedom of people, but the Freedom of the software to find new developers.
As for FOSS/ open source licences, I prefer BSD/MIT style to GPL/LGPL and I believe that the former can actually be more beneficial to software in terms of finding developers and keeping the software free. BSD/MIT software is of use to more people than GPL/LGPL software is, due to the fewer amount of restrictions in the licences. Many people/companies either contribute code or funding (or both) back to BSD/MIT projects as they have a vested interest in its success. Examples of this can be seen in the BSD world.
Z-Man wrote:What's bothering you about Godot in particular?
Well, for a start, it seems to be a relatively young project. Secondly, a "python-like" scripting language. How many potential Arma developers are going to want to learn yet another language, one that's specific to a single game engine? It does have many good points though so don't think that I'm just the voice of doom and gloom.
Playing since December 2006
User avatar
sinewav
Graphic Artist
Posts: 6413
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: New engine please

Post by sinewav »

Those are solid points, Monkey.
Monkey wrote:@sinewav and Z-Man
Let me put it this way: If Arma suddenly had awesome graphics but nothing else had changed, do you think more people would be playing it?
I do think more people would play, but it probably wouldn't change the online experience a whole lot. You can't discount the amount of people who play locally. Arma has no competition when it comes to online play but way too much competition for local only players. A new engine coiuld make us to be the best local game too, assuming a rewrite would allow us to add features other lightcycle games don't have (I can think of a few).
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: New engine please

Post by Z-Man »

Lucifer wrote:Does Godot allow you to write the UI with the scripting language?
Yes. The script bindings are generated from the same binding code as the editable properties in the editor. Whatever you can do in the editor, you can also do in script.
Lucifer wrote:Other obvious places for scripting: AIs, Zone logic (the C++ objects can keep internal counters as needed and just make them available to the script to read). It would even make CTF much easier to implement.
Yep. Now, a thing I need to investigate is how C++ code can 'call' script code. The usual holy grail, virtual functions in C++ that magically can be overridden in script won't work here, but signals/events can be triggered in C++ and caught in script. And if they did not totally botch things (I'll check), the implementation of the function that handles an event is found via the scripting code, calling the function in script if it exists or the function of the same name in C++ if it doesn't.
Lucifer wrote:As for serializing, I say we don't leave protobuf if we don't have to. You've written a network layer that works really really well for this particular game, and I'm not seeing somebody's general-purpose network stuff working as well, but I would be interested in testing somebody else's stuff and possibly contributing to make it work better for us (and hence helping it work better for everyone who uses it).
In the early days, Arma followed the same principles as those generic network systems: Clients send commands, server executes them and syncs objects to the clients. In this pure form, it's not cutting it. We're still using the basic principle because that's the only sensible way to avoid rampart cheating, but we send more information than "turn left" to the server (generic systems would allow that part) and do more on processing the sync messages from the server (generic systems would have difficulties there). But protobuf is just the way messages are encoded. That can be swapped out for something else if it's more convenient.
Lucifer wrote:I didn't look at the Godot webpage. What's their release schedule like?
No fixed schedule as far as I can tell. They set goals for the next release and release when ready.
Monkey wrote:@Z-Man
I think it's clear we have differing views on what constitutes an open source licence. That's fine. I still don't like the Unreal licence, whatever type/class of licence one may call it.
Totally understandable.
Monkey wrote:
Z-Man wrote:What's bothering you about Godot in particular?
Well, for a start, it seems to be a relatively young project.
Yeah, publicly in its open source form, it's about two years old. It has been in development and use internally at the company of the two leads that I can't remember for at least ten years, however. So it's not just two dudes starting out and throwing new stuff together. The things it does are informed by previous experience. The scripting language for example, they went through Lua, Python and Squirrel before, none of them worked as they wanted.
Monkey wrote:Secondly, a "python-like" scripting language. How many potential Arma developers are going to want to learn yet another language, one that's specific to a single game engine?
Those not wanting to learn another language can stick to C++ ;) GDScript is really easy enough to pick up. The bulk of the learning is getting to know the engine's APIs, and that's something you have to do no matter the language. Also, C# support apparently is in the pipeline via Mono.

I was wrong abut one aspect of signals: You do have to declare them and trying to connect to a non-existing signal (that is, registering a callback) gives you an error. Emitting a non-existing signal goes by unnoticed, however.

New point of worry is the error handling, though. Seems like the error handling philosophy is to log any errors to the console, but continue regardless. I suppose you have to check for nulls everywhere.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: New engine please

Post by Lucifer »

Z-Man wrote:
Lucifer wrote:Other obvious places for scripting: AIs, Zone logic (the C++ objects can keep internal counters as needed and just make them available to the script to read). It would even make CTF much easier to implement.
Yep. Now, a thing I need to investigate is how C++ code can 'call' script code. The usual holy grail, virtual functions in C++ that magically can be overridden in script won't work here, but signals/events can be triggered in C++ and caught in script. And if they did not totally botch things (I'll check), the implementation of the function that handles an event is found via the scripting code, calling the function in script if it exists or the function of the same name in C++ if it doesn't.
Your comment farther down about signals sounds like it'll be sufficient. We'll just emit signals from C++ code whenever we want to make something scriptable. I can't imagine there's a whole lot of situations where we'll want to call scripts from C++ code directly, so if you've got any ideas that can't be handled with signals, I'm interested. :)
In the early days, Arma followed the same principles as those generic network systems: Clients send commands, server executes them and syncs objects to the clients. In this pure form, it's not cutting it. We're still using the basic principle because that's the only sensible way to avoid rampart cheating, but we send more information than "turn left" to the server (generic systems would allow that part) and do more on processing the sync messages from the server (generic systems would have difficulties there). But protobuf is just the way messages are encoded. That can be swapped out for something else if it's more convenient.
I honestly can't imagine a situation where we'd really need to use the engine's network stuff, unless syncing objects becomes much more difficult without using the engine.
Monkey wrote:Secondly, a "python-like" scripting language. How many potential Arma developers are going to want to learn yet another language, one that's specific to a single game engine?
Those not wanting to learn another language can stick to C++ ;) GDScript is really easy enough to pick up. The bulk of the learning is getting to know the engine's APIs, and that's something you have to do no matter the language. Also, C# support apparently is in the pipeline via Mono.
I don't have any problem learning a new language. Seems like I manage to learn a new programming language every year or so whether I want to or not.
New point of worry is the error handling, though. Seems like the error handling philosophy is to log any errors to the console, but continue regardless. I suppose you have to check for nulls everywhere.
I suppose we could make a thin wrapper that does the null checking for us. Could probably write a Python script to generate it. :)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
Monkey
Match Winner
Posts: 759
Joined: Thu May 22, 2008 12:36 am
Location: England, UK

Re: New engine please

Post by Monkey »

Z-Man wrote:Godot has been in development and use internally at the company of the two leads that I can't remember for at least ten years
That is good to hear.
Lucifer wrote:I don't have any problem learning a new language
I find that the more languages I use, the less good I am at each of them. I struggle to believe that the opposite is true for any human being.
Playing since December 2006
User avatar
Ratchet
Match Winner
Posts: 779
Joined: Sat Mar 15, 2008 5:55 am

Re: New engine please

Post by Ratchet »

I just wanted to say that Rocket League uses the Unreal engine. And my God is it absolutely stunning visually. My PC plays that game on maximum settings far more smoothly than arma has.

I'd be interested in playing tron again with a massive overhaul. Not that it matters much, but yeah.
Image
"Dream as if you'll live forever,
Live as if you'll die today." -James Dean
User avatar
aP|Nelg
Match Winner
Posts: 621
Joined: Wed Oct 22, 2014 10:22 pm
Contact:

Re: New engine please

Post by aP|Nelg »

Monkey wrote:
Lucifer wrote:I don't have any problem learning a new language
I find that the more languages I use, the less good I am at each of them. I struggle to believe that the opposite is true for any human being.
I don't know about all that, but I hope you realize he means programming languages and not speaking languages.
Ratchet wrote:I just wanted to say that Rocket League uses the Unreal engine. And my God is it absolutely stunning visually. My PC plays that game on maximum settings far more smoothly than arma has.
Yes.
Post Reply