personally would hate to see BYOND waste time trying to hamfist in 3D support. BYOND is a 2D engine and excels at being a 2D engine. There's no real purpose in trying to compete with the likes of Unreal or Unity.


Improved raycasting support would be nice, so that making classic Doom / Wolfenstein style games would be more feasible. But I don't think BYOND should ever try to implement genuine 3D.

That's fair. I see where you're coming from. It just seems like it'd be a pretty big undertaking.

(nice to see you btw! hope you've been well.)

Why fork the Blender Game Engine when you can fork Godot? What advantages could the Blender Game Engine possibly have over Godot? It's a discontinued component of Blender. Blender is a tool made for the creation of high-quality 3D assets and renders, not performant 3D games. The interpreted scripting of Blender held back the potential of the Blender Game Engine, so the results are mediocre at best. It has nothing on modern game engines.

In my opinion, the open-source Godot engine represents the uncontested bleeding edge of game engines. As much as they would like you to believe otherwise, it competes directly with all of the most powerful proprietary engines, and actually surpasses them, by being inherently open by design, and allowing you to export your game to literally ALL relevant platforms or operating systems, whether it's PCs, mobile devices, game consoles, or even web browsers.

If BYOND ever reaches the point where 3D support would make sense, then it might be a good idea to learn and borrow from the best, and the best is Godot!

uncontested bleeding edge of game engines.

Contested. The power, scalability, and developer marketshare are objective metrics that make this statement an arbitrary attempt to use force of phrasing to elevate an opinion beyond its station.

If your only criteria is: "free". Absolutely, you have a point. Sort of, because most of the major engines have moved toward a royalty model.

I've used godot, GM2, Unity, and UE3/4. They've all kinda got their own merits. Personally, I didn't like godot's workflow. I really liked working in Unity, but UE4's free source access and customizable workflow sucked me in. I don't love the engine's propensity to turn into a CPU/GPU/Memory hog in no time, but that's fixable if you are willing to get in under the hood and stop using the "easy" methods that the engines try to incentivize.

Also, I mostly work in blender for 3D modeling work and level blockouts. I love blender. I can see the attraction for people obsessed with an all-in-one workflow, which would help explain their proclivity for using BYOND as well. BYOND has a similar almost-all-in-one-ness to blender's game engine.

Audio freak XD wrote:

-Python is setup same way as Dream Maker Language, although it's not the same. Everyone already knows you would be using tabs and colons instead of brackets, so it would work similar to Dream Maker.

Godot gives you the option to use GDScript, which was inspired by Python, so it's also very similar in that way. If you absolutely must use Python, you can just use godot-python for that.

Audio freak XD wrote:

-It would give all tools needed for the games, unlike Godot. Modeling, texturing, programming, etc. can all be done in blender.

Ter13 wrote:

I mostly work in blender for 3D modeling work and level blockouts. I love blender. I can see the attraction for people obsessed with an all-in-one workflow, which would help explain their proclivity for using BYOND as well. BYOND has a similar almost-all-in-one-ness to blender's game engine.

Audio freak XD wrote:

Yes, I am very attracted to the all-in-one package.

I see why you would make that comparison, but I don't think BYOND has ever really been an all-in-one package. It provides no way to produce sound or music assets. Should Audacity and SunVox be merged into BYOND? I don't think so. Should the simple icon editor be replaced with something more complete, like GIMP or Krita? Should the map editor be replaced with Tiled? No to all of those. BYOND provides just enough extra tools to help you get started. Where developers go from there is up to them. Developers who use BYOND should always be using the third-party tools that they feel most comfortable with, or are best suited for the job. If BYOND fully provided everything needed to make games, it would become unmaintainable nightmare fuel. It shouldn't need to include Blender, just like it shouldn't need to include any of those other open-source programs I mentioned. BYOND might as well be an operating system at that point. Just imagine how big of a download it would be. What happens if there is a crash? The whole thing might go down, potentially causing you to lose all kinds of work in many different areas of game design.

Personally, I think some aspects of Blender's interface are poorly designed, with far too much reliance on hotkeys. The 3D modeling tools in particular, are not very intuitive, and they just leave a lot to be desired. Many proprietary alternatives are just far easier to use.

Even if you did want to haphazardly integrate Blender into BYOND, that still doesn't mean the Blender Game Engine should be thrown in there with it. Supporting that engine is kind of like supporting Internet Explorer. It's just outdated and obsolete. Switching to Godot was even recommended in Blender's 2.80 release notes. There's no reason you couldn't integrate Blender with Godot. Here are some projects that may help you do that:

Godot Blender Exporter
"Better" Collada Exporter for Blender 2.9
Godot Game Tools
Blender2Godot

Audio freak XD wrote:

-Since Blender Game Engine uses python, BYOND could easily make a host tool to synchronized the networking, which means you wouldn't need the game to be opened to be able to host it. While Godot you would have to have the game open to host it, and because of this, you will not be able to buy a shell server and host your Godot game the same way you could by just running a Python script.

Godot has a headless server build for Linux servers, so that's not really an issue. Also, BYOND already has its own networking, so it wouldn't really have to rely on the networking of a different engine. If anything, BYOND's own system would be improved rather than replaced.

Audio freak XD wrote:

-BYOND doesn't work on all platforms anyways. It only supports Windows to play games. It wouldn't be wise to choose Godot just for the purpose of multi-operating systems.

Sure it would! BYOND could learn a lot from such a portable engine, and it could even be integrated with the webclient. The potential for mobile apps is just too good to pass up.

Ter13 wrote:

Contested. The power, scalability, and developer marketshare are objective metrics that make this statement an arbitrary attempt to use force of phrasing to elevate an opinion beyond its station.

If your only criteria is: "free". Absolutely, you have a point. Sort of, because most of the major engines have moved toward a royalty model.

I said "uncontested" because I believe Godot has been positioned to become the Chromium of game engines. The game engine war is still very much ongoing, and anything could happen, but I do believe Godot will prevail. Once the proprietary engine developers realize what they are up against, they will start making custom versions of Godot just to compete with it, unless of course a new contender steps up to the plate. Being free and open source is a very big deal, especially for a game engine that already has around 80% of the features of the top proprietary competitors, and Godot seems to be growing a lot faster than they are. It may even overtake them, even though it might be a decade or more before that happens. When you factor in the power, cost, portability, extensibility, and overall potential, I think Godot currently takes the win, especially when it comes to indie game development.

Ter13 wrote:

I've used godot, GM2, Unity, and UE3/4. They've all kinda got their own merits. Personally, I didn't like godot's workflow. I really liked working in Unity, but UE4's free source access and customizable workflow sucked me in. I don't love the engine's propensity to turn into a CPU/GPU/Memory hog in no time, but that's fixable if you are willing to get in under the hood and stop using the "easy" methods that the engines try to incentivize.

What is it that you don't like about Godot's workflow? Unity isn't bad, but Unreal is just better in a lot of ways. GameMaker doesn't really compare to any of these powerful engines. CryEngine is a meme of an engine that never lives up to its hype. The original Source engine was good for its time, and it aged quite well, but it has become outdated.

I apologize for my deleted comment. It was contributing to a trend that would have resulted in an argument further derailing the thread.

OP, keep doing what you do, but be aware that BYOND will never be a 3D engine. If that's what you want to make, avoid inheriting the design compromises BYOND is stuck with forever. Make something better.

3D BYOND Games should be confined to the feverdreams of adolescent weebs who unironically think narto running makes you faster.


Jokes aside, I do think better support for pseudo-3D stuff like classic Doom or eve original starfox would be pretty awesome. I think BYOND excels at "retro revival" types of games, and it'd be a perfect engine to make some classic old school first person shooters in, if it could handle it better. It's currently possible to do, as Kozuma and others have demonstrated. It's just horribly inefficient and not feasible for multiplayer play currently. But golly, could you imagine?

Audio freak XD wrote:

I respect your opinion, maybe Godot wouldn't be the worser trait of them all. Anyways, the community still updates the BGE called UPBGE so it's weird they would suggest Godot.

Anyways, my question is, what would you think about 3D BYOND games? (Not to have a debate about what is the best Game Engine ever. IT's all bias opinions at that point)

If you really like using the Blender Game Engine, then by all means, keep using it. I just didn't want anyone to think that it was the only real option to consider for something like this. There are plenty of promising open source game engines other than Blender Game Engine or Godot, such as PlayCanvas, Open 3D Engine, Stride, Defold, and OGRE, just to name a few. Some of those support Python and/or Lua.

What we would think of 3D BYOND games is a good refinement of the true purpose of this thread. The idea is usually never considered seriously, but I will attempt to do so.

Ter13 wrote:

I apologize for my deleted comment. It was contributing to a trend that would have resulted in an argument further derailing the thread.

That really is unfortunate, but I have to respect your decision and sacrifice, if you felt that this thread was starting to derail. I blame the limitations of the thread technology. Genuine discussions are naturally nonlinear.

=== BEGIN Hypothetical ===

I think some existing BYOND games could benefit from a parallel projection, such as orthographic or oblique, which could allow for 3D atoms to be rendered at specific locations on an existing map, right alongside the icons, with a matching pixel density, following all of the usual layering, offset, transform, and visibility rules. For example, you might have a game that has 2D terrain and structures, but has 3D movables. Game developers could choose how best to compromise for efficiency. Similarly, it would also make sense if 3D atoms could be shown on a client's screen, but there would still be no perspective to them.

A first-person or third-person view, with or without true perspective projection, would be a MUCH bigger problem for BYOND. I suspect this would require an entirely new viewport control, separate from the map control, even if the actual map is still used for level design. Such a viewport control would still need to display client screen objects like maps do. If all locations correspond in some way, a normal map control could be made to work as a minimap, or it could be shown as a gameplay mechanic, whenever you want some kind of 2D level. A first-person or third-person view would be an entirely different way of interpreting 3D atoms and locations on the map. Of course, developers could just choose to completely ignore the classic tile grid and do their own thing. A major part of this whole problem is getting multiplayer interaction to work correctly when every player has a unique view. This means that BYOND's core network code might have to be expanded significantly just to handle this. This is a full-stack problem that would basically amount to developing an entirely new engine, even if it does tie into the existing one in some ways.

True perspective projection would be even more of a change, requiring a much more advanced graphics pipeline and more complex network code. Depending on how low-level the implementation would be, some code could be reused for both a true perspective projection and a less complex, limited perspective projection. For example, you could look at what old and modern games have in common, and implement modules based on that.

Efficiency would be extremely important for anything 3D in BYOND, so there might be a way to use a variety of different techniques or algorithms that are supposedly no longer relevant to modern games.

It would probably make sense to introduce a new LIGHT_SOURCE value for atom/appearance_flags, which could function similar to PLANE_MASTER, but it would make the atom act as a light source for any 3D atoms on the same plane. Additional vars would be needed to define the light, or maybe just one var set to a /light datum.

For basic 3D movement and collisions, the existing location and bounds systems could be expanded with a new a-axis or e-axis, as in altitude or elevation. The "z" var is already used to determine the z-level, and "w" would be too confusing, considering that "z" is being skipped, and pixel_w works horizontally rather than vertically. At least using "a" for "altitude" would stand out more, since it's not going to be in order with "x" and "y" anyway. This means the new vars would be "a", step_a, bound_a, and bound_depth, as well as the purely visual pixel_a and pixel_b. All atoms would be able to collide using 3D bounding boxes, with no distinction between atoms that display as 3D objects, 2D sprites, or don't display at all.

For precise collisions, a bound_shape or bound_mesh could be used instead of normal bounds, which would also be useful for strictly 2D games.

Higher precision numbers and arithmetic are prerequisites for effectively breaking out of the tile block grid.

Gravity would mostly be left up to developers to figure out, so by default, things could just float and fly around if they are sent upwards.

While BYOND currently uses DirectX, I think it would be best to have any new viewport control use OpenGL for rendering, as it's a well-tested, cross-platform standard. It should be possible to use both APIs at once, especially in separate windows, which would probably make it easier to migrate the rest of BYOND to OpenGL.

=== END Hypothetical ===

Mapping is not the issue. BYOND's evolutionary path has been radically different from any other game engine, ever. It started in the 90s, when it used to be known as DUNG (Dantom's Universal Network Game), which was built from the ground up as an engine for graphical MUDs. BYOND has evolved considerably over the years, but the core system behind it remains more or less the same. This means that in BYOND, all bytecode resulting from DM compilation is executed entirely on the server side. While there are procs that will help you do fancy things on the client, every single procedure must still pass through the server, even if it impacts only one player out of a hundred. The map control is built for displaying a highly interactive, multi-user grid of animated sprites, not the kind of rapidly changing, intense graphical rendering that can only reasonably be done on the client side.

Sure, you can force the map control to render something like DOOM, but it will struggle to run with even a single player. If you tried really hard, you could probably get a game like Quake to run within BYOND's browser control, but you would have to get really creative to make it work with multiplayer. I will say that the browser control will become far more useful and powerful once it gets switched over to Microsoft Edge, which would make something like that easier to do. Alternatively, you could use DirectX hacks to do just about whatever you want, but you couldn't really call it BYOND at that point. It would be far easier to just use another engine.

What I was talking about in my last post was some of the challenges that would be involved in implementing built-in 3D support in BYOND, which has nothing to do with how game developers might try to hack together a 3D game in an engine that isn't designed to run it.

While I suspect such hypothetical 3D BYOND games would look like nothing anyone has ever seen before, if DeviousMUD is anything to go by, then a lot of them might resemble RuneScape Classic, not to be confused with OSRS.

Audio freak XD wrote:

I don't think you understand how BYOND works...

Ask Lummox JR or Ter13 if you don't believe me. What I'm telling you about BYOND is true.

BYOND uses a client-server model, but all compiled DM code is executed by the server, not the client. Even in a single-player world, when you run a DMB file, Dream Seeker still runs a kind of invisible server and connects you to it. Both Dream Seeker and Dream Daemon are capable of hosting games, but Dream Seeker also runs the client. The client side is relatively thin, and Dream Seeker handles all that it does behind the scenes. DM's syntax may resemble Python, and compiles down to an executable DMB, but it's very much server-side, like PHP or Perl. Even the code you write under /client will be executed on the server side.