New engine please

For developmental things relating to the graphics of the game.
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 »

aP|Nelg wrote:I don't know about all that, but I hope you realize he means programming languages and not speaking languages.
Some scientists actually studied this. They had programmers hooked up to fMRI machines and scanned their brains while they were programming. The same centers of the brain used for human languages were activated while programming.

The suggestion is that if you're good at learning programming languages, you're probably good at learning human languages, but I haven't seen any followup research in that area. Anecdotally, I learn human languages quickly, I just don't have many opportunities to practice them, so whenever I start, I usually wind up stopping before achieving fluency due to lack of practice. But after three years of French in high school, I was conversational, and it took a full five years before I finally lost 90% of it, and that was without practicing. But I was able to pick it up enough to read Pascal documentation that was written only in French for a compiler for PalmOS a few years back (never got around to writing anything, though). I'm actually in an environment where I can practice Spanish right now, so I'm trying to learn that one while I have the chance. I've made several goes at it over the years, so I'm reasonably hopeful I'll finally get it, and hope I'll have opportunities to keep in practice after I leave this environment.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
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 »

Dunno, I find that no matter what language I code in, the dominant effect is that I get better at coding as a whole. It's not the coding in a different language that lets skills in another deteriorate, it's the lack of practice. Anyway, Godot Script is so easy and inoffensive that I doubt it makes anyone unlearn anything.

Regarding Unreal, yeah, no doubt it's the technically most advanced solution available without forking over huge amounts of cache, probably even without that qualifier. This comes with a bunch of prices, however:
- System requirements for development are prohibitive (Just about what I have).
- Minimum download size of the end product is huge (some 100 MB).
- The renderer does not scale back well at all to weaker hardware.
And the fact that it's not really considered open source means that nothing made with it will ever find its way onto Linux installation disks, historically a big source of users for us.

I finished my week-and-a-bit with Godot experiment. Here's what I got, a proof of concept Tron game with one cycle, not even AI enemies and very, very rough all around. My favorite thing is that you can still control the orientation of the explosion. Yeah, I said I wanted to do a different primitive game first, but I've been using lightcycles to learn new programming environments for almost 30 years now, I'm too old to stop :)

Source is here: https://code.launchpad.net/~z-man/+junk/godot_tron_test
Latest builds here: http://vps-zman.armagetronad.org/~manue ... _tron_test
Mac build untested. Android version has reduced visual quality so it can run with 60 FPS on my devices.
screenshot.png
Evidently, it's only got the bare minimum stuff. I wanted to find out how hard the engine is to use, and the answer to that is: not hard at all. Simple things can usually be done in a single line of script. Clobbering together the main menu (layout possibilities, even just the positioning, far from exhausted): click together buttons, click on button press event, click OK, fill in code that should execute. Moving the cycle forward is literally just "cycle.translate(Vector3(0,0,step))". Yeah, like everyone else, they put the y axis up... Oh well. Scripts are all short, pretty much all single pagers. The raycast that checks for collision of the cycle with walls is an object in the scene that gets polled automatically every frame, the cycle code or anyone else interested can just fetch the results. The explosion effect is entirely done without code, just the animation system. The signal system allows for great modularization. In a full game, for example, the cycle would emit a signal when it is destroyed. The game mode code would listen to that and trigger a respawn or check win conditions, on a win, it would emit a 'round end' signal. The match management code would listen to that, etc. Here, I abuse it :) The explosion animation end signal is what triggers the return to the main menu, and I extended the animation over the natural length to get an extra delay. Bad Z-Man.
It's fun to work with. It's extremely tempting to add just one more thing. For example, I wanted to leave out the collisions and just check the graphics, but it was just so easy... and then, of course, I had to add the explosions. And the primitive control flow. The documentation is good; it's been used enough so that, for example, entering "screen width in Godot" in Google gives you meaningful results.

There was a magic moment. A scipt was referencing a scene tree node via some relative path. I moved the node around, then wanted to adapt the path to the new location.... only to find that had already happened automatically.

Performance of the script is all right. I did a primitive benchmark, it came in between 100% Python speed (just int calculations) to 50% python speed (function calls dominate). C++ on the same problem has 50000% Python speed, of course. Its fine as long as you keep all per-frame actions in C++. Which I have not done here, I wanted easily publishable builds with the pre-built templates.

Graphical effects: It's got bloom and HDR. The bloom looks a bit aliasy to me, maybe it's done on a lower resolution buffer. With tweaked art, it'll be fine. The cycle shadow is real (shadow mapping); it'll look better in Godot 2.2, I already verified that from current GIT sources. Maybe good enough to enable trail shadows. The headlight tests dynamic lights, they work well. I could not find the right parameters to make it cast proper shadows, though.
All in all, it's not stellar, does not come close to Unreal or Unity. It would suffice, however. Much better than what we have now, at least it would support proper materials with emission and diffuse components, so cycles with pretty glowing lines. And we could get rid of code driven graphics. There's a bit left here, the trail is done with hardcoded immediate mode geometry. Better would be to take a template wall and stretch it to the right length.

Oh, null checks are done automatically in debug mode, they cause breaks. In release mode, the script tries to hobble on and just does nothing. Probably all right for games.

It's not all sunshine. The editor is also basically a Godot game, it runs in a single window only, making it hard to make good use of a multi-monitor setup, You can't view the scene and edit scripts at the same time. It's possible to start the game fixed on a monitor of your choice, at least. The editor has a quirk I find hard to get used to: When you open a vector for editing, edit a couple of values, then click outside, it counts as undo and the entered values are lost. You really have to press enter to commit. File dialogs often open in directories that make no sense. Import formats are limited. The right mouse button does nothing in the 3D view, it could be used for panning, for example.

But yeah, overall, it's quite good. Certainly the best single open source game creation tool I've ever seen.
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 »

I smell Armagetron Advanced 0.5 on the way ;)
User avatar
Light
Reverse Outside Corner Grinder
Posts: 1667
Joined: Thu Oct 20, 2011 2:11 pm

Re: New engine please

Post by Light »

aP|Nelg wrote:I smell Armagetron Advanced 0.5 on the way ;)
Starting from a new engine, maybe we'll make it to version 1.0. lol
User avatar
sinewav
Graphic Artist
Posts: 6413
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: New engine please

Post by sinewav »

Neat. I'm surprised it ran on my business class laptop from 2008. Funny that "Craptron" still looks and plays better than some legit lightcycle games I've downloaded.
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 »

sinewav: That's indeed surprising. What kind of FPS do you reckon you get there? My outdated one, which I'd bet is newer, but dunno, gets only about 20, similar to my android devices with all the effects of the Windows/Linux builds activated.

About actually using Godot, more musings. I've been taking stock. Assuming we want to make the switch, in the long run, which systems we currently have will still be there?

- Graphics, sound and music: Duh, gone.

- User file management: Godot handles user files as well.

- Collision (eGrid, eGameObject etc): Those are essential, they need to stay. IMHO, it's one of the essential features of AA that walls have zero width and that you can always squeeze between any two walls. No stock collision system I know of can do that. However, it's due for a replacement. It has a couple of limitations, like the fact that modifications to existing geometry are impossible and that it does extra subdivisions where a better algorithm could avoid them (you only need subdivisions if actual walls cross). And it's confined to a plane. A fully 3d system with all the essential properties (zero wall width, good guards against cycles slipping through infinitesimal gaps between wall segments) isn't all that hard to do... So one way or another, I want it replaced.

- Player management (ePlayer, eTeam, eVoter): Not performance critical; that's something bound to be redone in script entirely so that game modes have an easier time modifying them.

- UI, Settings: Yeah, script. The core properties and functions can still be in C++, but managing them sounds like script work.

- Maps and Cockpits: Should be editable in the Godot editor. It'll be easier to just save them as scenes and load them in than to write an XML importer.
Security caveat here: The scene format allows embedded scripts. So if we don't do anything, servers with custom maps can execute arbitrary script code on the clients. We're in full control of the engine and therefore in full control what script can do, so that may not be that horrible. At least, we can prevent those scripts from accessing files outside of the game data and game specific user data directories.

- Networking: Godot has probably acceptable network transport functions, it also offers reliable UDP packets that get auto-resent when they get lost. Dunno about the higher level functions; I'll have to check how RPCs get encoded (Guess: JSON, but they do have some binary packing format, so maybe that). Also an open question: How would we handle different versions of the game talking to each other? So that one can go one way or the other.

- Authentication: Godot gives us coroutines and https, both make the job of managing a multi-step process where you occasionally have to wait on some input event much easier. Replace it with script.
Security caveat: if we allow arbitrary scripts, how do we prevent those scripts from faking a login dialog? Or reading stored authentication data from the user data directory? Well, if the real login is C++, it coulds store that data in a file we don't give access to from script. And the password entry from could be frontloaded at program start when no user code has been loaded. Scripts could still open a fake "Login expired, reenter your password" screen, though.
Meh. It's probably best to block downloaded script code from executing at all. We could still allow manually installed code mods, of course.

- Camera: The current system only works for planar gameplay. We can keep it around, even if we would support multiple layers and driving on walls and whatnot, I recon most games would still be played on a plane. The default camera would need to be something new, though.

- Zones: Script em. No need for complicated trigger/target/effect systems if you can just do

Code: Select all

function _on_enter(cycle):
  if cycle.team != team:
    cycle.die()
Godot already has a system that would handle the detection of when players are inside zones as part of their collision systems.

- Network model: I don't like our current network model any more. By that I mean the game logic that handles commands sent from the client to the server and that interprets syncs from the server to the clients. It simply requires way too much code. What it tries to do is make server and client agree on a single world history governed by the same rules for everyone. That's all right in principle, but the implementation boils down to lots of explicit code trying to maintain that common world history. It can go two ways: Implement a system that properly keeps a consistent history, which requires both server and clients to have the capacity to roll back the entire world to a previous state, apply user input that just appeared over the net, then re-simulate to the current time. The individual game object code would then just be regular simulation code that doesn't have to care one bit about network peculiarities. Or we could go the other way and adopt the view of the modern shooty games: it does not matter if two players see different game states as long as they agree on the score and each worldview is plausible. That's a topic for a whole new thread, though.

In summary: That's a whole lot of systems we'd ideally be replacing sometime. Far more going out than staying in. I think we'd be better off starting with a clean slate, build minimal vertical slices of every system, see what we get of them, and if we see that we really could use one of the old mechanisms (transitionally or permanently), pull that in selectively.
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:I think we'd be better off starting with a clean slate, build minimal vertical slices of every system, see what we get of them, and if we see that we really could use one of the old mechanisms (transitionally or permanently), pull that in selectively.
Sounds sensible to me.

Despite some initial negativity, I'm actually excited about all this because not only has Z-Man's internal lightcycle flame been reignited but also we actually have a decent open source game engine at our disposal. :) The downsides to Godot seem mostly improvable too.

One question I have is what is going to happen to 0.4?
Playing since December 2006
User avatar
Light
Reverse Outside Corner Grinder
Posts: 1667
Joined: Thu Oct 20, 2011 2:11 pm

Re: New engine please

Post by Light »

Monkey wrote:One question I have is what is going to happen to 0.4?
I would question if we're going to keep the new build compatible with the current servers, or if it would make sense to separate them with improved networking, among other things that may be possible with the new engine. Especially if his comment about having an actual 3D environment, rather than playing on a single plane comes to be .. When he mentioned riding on the walls, I pictured a new map shaped like a cube, and when you go onto a wall, the camera shifts so it's now your floor. Maybe an alternative would be missing two of the walls so it's like a ring and you can fall off or something. :P
User avatar
sinewav
Graphic Artist
Posts: 6413
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: New engine please

Post by sinewav »

Light wrote:When he mentioned riding on the walls, I pictured a new map shaped like a cube, and when you go onto a wall, the camera shifts so it's now your floor.
In 2008, "Bugfarm Cubed" was created as a practical joke. It didn't actually exist, but it would be funny to see it become a reality 10 years later, heh.
User avatar
Light
Reverse Outside Corner Grinder
Posts: 1667
Joined: Thu Oct 20, 2011 2:11 pm

Re: New engine please

Post by Light »

sinewav wrote:
Light wrote:When he mentioned riding on the walls, I pictured a new map shaped like a cube, and when you go onto a wall, the camera shifts so it's now your floor.
In 2008, "Bugfarm Cubed" was created as a practical joke. It didn't actually exist, but it would be funny to see it become a reality 10 years later, heh.
I think it would be awesome. Also, racing maps could get a hell of a lot cooler if you raced down tunnels and stuff like the "live as long as you can" games.
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 »

Light wrote:
Monkey wrote:One question I have is what is going to happen to 0.4?
I would question if we're going to keep the new build compatible with the current servers, or if it would make sense to separate them with improved networking, among other things that may be possible with the new engine.
Maybe somehow have it with improved networking with the new 0.5 clients, but still retain compatibility with previous versions?
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:not only has Z-Man's internal lightcycle flame been reignited
Possibly. We'll see. Things have stabilized enough around here and I'm motivated enough to push myself into the night a couple of times a week for long enough to do meaningful work. Feels good to be in the saddle again, The horse must have fallen asleep or something, though.
Monkey wrote:One question I have is what is going to happen to 0.4?
Network compatibility wise, the right thing to do if we start from scratch would be to also drop compatibility with earlier versions. A restart is a lengthy process and we should focus on getting something good that can stand on its own out. Only then, it makes sense to think about re-adding compatibility, because then we'll have a better idea on the cost/benefit ratio. Especially the benefit side; how many people would care about BC at all?

As for finishing 0.4, I'm all for that. Restarts are also risky. Chances are that we'll all lose interest halfway through. If we finish 0.4 first or while we start working on the new thing, there would at least be something left. And also for the case that the new thing goes well, we'll have something for people to play and would be in less of a rush to marry ourselves to half-baked systems.
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:Network compatibility wise, the right thing to do if we start from scratch would be to also drop compatibility with earlier versions. A restart is a lengthy process and we should focus on getting something good that can stand on its own out. Only then, it makes sense to think about re-adding compatibility, because then we'll have a better idea on the cost/benefit ratio. Especially the benefit side; how many people would care about BC at all?
If it's reasonably possible, I'm going to want backwards compatibility, at least for a potential 0.6 release built from scratch. My specific thinking is that if we have to factor out the old network code and use that for backwards compatibility while using the new engine for the 0.6 protocol, that would be fine. We'd look at dropping backwards compatibility for pre-0.6 in the 0.8 series, then. That would be called "dropping legacy network support", though, not really dropping backwards compatibility since it's reasonable to expect 0.6 and 0.8 to be as compatible as possible.
As for finishing 0.4, I'm all for that. Restarts are also risky. Chances are that we'll all lose interest halfway through. If we finish 0.4 first or while we start working on the new thing, there would at least be something left. And also for the case that the new thing goes well, we'll have something for people to play and would be in less of a rush to marry ourselves to half-baked systems.
It's worth pointing out that we can't even have a vote on this. If Z-man wanted to go on his own, that's fine, of course, just like if I wanted to go on my own. But we can't have a vote until I find both time and motivation to fool with Godot enough to make an informed vote, which I anticipate will still go "Yes, let's do this shit", but I'm not willing to commit until I've done two things: 1) Find the time to work with Godot (which would also demonstrate I have time for arma work in general) and B) Do enough work with Godot to make a decision about it.

So far, it seems to have one major flaw: You have to use the Godot IDE. When/if I can figure out how to use Kate to do all the work I'd be doing, well, that would be nice.

So, long story short, we're still heading for 0.4 from the existing codebase and have absolutely no reason to deviate from that course.
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 »

Yeah that all makes sense. Also, 0.4 has had so much work put into it and it's not that far off completion from what I've gathered.
Playing since December 2006
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 »

Backwards compatibility: The thing I want to avoid by postponing the decision is that sticking with compatibility limits our design choices for the new thing. For example, compatibility with the old setting system with its flat organization would make it more difficult to distribute settings better over the whole scene tree with, for example, the possibility to make the cycles of one team faster, but those of the other team more maneuverable or with some other advantage.
Lucifer wrote:So far, it seems to have one major flaw: You have to use the Godot IDE. When/if I can figure out how to use Kate to do all the work I'd be doing, well, that would be nice.
While there are some things definitely best done in the Godot editor (editing the scene, managing assets), Gotot script files are just files in the project file system, you can edit them however you like. You can build and run the project from the command line, too. What you lose when you do that is the autocopletion, syntax highlighting (probably) and proper debugging, of course, unless someone writes plugins for that for your editor.
Writing C++ code is definitely only possible outside Godot's IDE. You're essentially extending the engine there. Debugging the C++ side would also happen in an external debugger. The real trouble starts if you have a bug where you need to investigate the interaction between script and C++. Then you need to lauch the debug session from Godot's editor and additionally connect to the running game process with your C++ debugger. Godot's debugger and the running game communicate over network sockets, I gather... I hope those connections don't time out if you take a bit longer to step through your C++ function. Aso, ideally, you need enough screen space for the two debuggers and the game. It should be technically possible to have just one debugger interface handle both (like Visual Studio does for C# interacting with C++), but nobody has done that yet.
And heh, one of the first things we need back would be debug recordings. I don't want to simultaneously debug client(s?!) and server that way.
Post Reply