Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Unity is RPG Maker

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,180
Location
Poland
Strap Yourselves In Codex Year of the Donut
The fully-fledged "game engines" such as Unity or Godot are the devil. See how I came to this realization. See the spoiler.

I was looking for something to prototype with, i.e. have a quick display for any new code or functionality without writing contrived scenarios in code. Saw a video on how a guy did this-and-that in Godot. So I read more about it.

Turns out, a game developer using Godot (or Unity, for that matter) is limited to what that particular "game engine" provides in its clickable user interface. They don't create the executable themselves, the "engine" does it for them.

There were few elementary things missing in the renderer (forward rendering only, incomplete baked global illumination). The last option left was to hack at the engine's rendering parts. Actually it had few separate renderers implemented for various APIs. Each possible implementation had a fuckton of lines to implement the clickable options for artists. Chances of writing a working renderer without turning it into a multi-week project? None.

So it came to me–these lousy shovelware cocksuckers aren't even programmers! They're RPG Maker tards reborn! At least with RPG Maker games it's clear what it is. It's not only that any idiot can share their pseudo-"games", these common tools are useless for actually competent developers.

For instance, in a prototype I was able to reuse Fallout assets. I couldn't write code to reuse Fallout assets from the .dat files in the Godot editor. I'd have to add a ton of code to the "game engine" itself to handle .dat files.

The "rendering engine" category is less intrusive. They force a certain way of things but some of them are (may) be pretty sane. I'd definitely not want to write skeletal animation code. Too many formulae to get right.

In the end, let's use prebaked sprite animations and fuck it.
 

J_C

One Bit Studio
Patron
Developer
Joined
Dec 28, 2010
Messages
16,947
Location
Pannonia
Project: Eternity Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 Steve gets a Kidney but I don't even get a tag. Pathfinder: Wrath
:hmmm:
these common tools are useless for actually competent developers.

Do you want me to list all the high profile developers who use Unity or are you gonna do your homework for yourself?
 

nobre

Cipher
Joined
Apr 27, 2016
Messages
674
Location
Pays-Bas
True Artistic Brilliance (tm) shines only more brightly not despite, but because of severe limitations, like in poetry.
 

Agesilaus

Antiquity Studio
Patron
Developer
Joined
Aug 24, 2013
Messages
4,454
Grab the Codex by the pussy Codex USB, 2014 Steve gets a Kidney but I don't even get a tag.
N-n-no... I am a real programmer... gamemaker studio 2 makes me type codes and I u-use the s-sq-squiggly brackets and everything
 

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,180
Location
Poland
Strap Yourselves In Codex Year of the Donut
these common tools are useless for actually competent developers.

Do you want me to list all the high profile developers who use Unity or are you gonna do your homework for yourself?

I overreached when speaking of "game engine" devs being all incompetent. I'm still pissed at "game engines" being a dead end for rapid prototyping. I can't make a particular kind of game with Godot or Unity because they won't allow it.

Let me go through an only slightly contrived example.

1. Game developer uses a closed-source "game engine".
2. Engine only allows for hard shadows.
3. Developer wants soft shadows by any implementation.
4. The "engine" has no way to do shadow map postpocessing, no way to replace the renderer, etc.
5. It has to be hard shadows or bust.

Before I wondered why the AOD team was so pissed at Torque3D. This explains it.

This is how using Godot Engine looks like



This is how getting familiar with a Quake 2 source port looks like. I was wondering if the vertical FOV formula was correct.

ejN1AdD.png
 

J_C

One Bit Studio
Patron
Developer
Joined
Dec 28, 2010
Messages
16,947
Location
Pannonia
Project: Eternity Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 Steve gets a Kidney but I don't even get a tag. Pathfinder: Wrath
these common tools are useless for actually competent developers.

Do you want me to list all the high profile developers who use Unity or are you gonna do your homework for yourself?

I overreached when speaking of "game engine" devs being all incompetent. I'm still pissed at "game engines" being a dead end for rapid prototyping. I can't make a particular kind of game with Godot or Unity because they won't allow it.

Let me go through an only slightly contrived example.

1. Game developer uses a closed-source "game engine".
2. Engine only allows for hard shadows.
3. Developer wants soft shadows by any implementation.
4. The "engine" has no way to do shadow map postpocessing, no way to replace the renderer, etc.
5. It has to be hard shadows or bust.

Before I wondered why the AOD team was so pissed at Torque3D. This explains it.

This is how using Godot Engine looks like



This is how getting familiar with a Quake 2 source port looks like. I was wondering if the vertical FOV formula was correct.

ejN1AdD.png

Then don't use Unity or Godot for fucks sake. Use Unreal. Every engine has a potential use and very well suited for certain kind of games.
 

Aiff((AimpliesA)ImpliesA)

Artist Formerly Known as Prosper
Übermensch
Joined
Oct 21, 2016
Messages
287
code's an issue right?
i almost never work on my Redacted MK2. but i do plan to switch over to godot 3 before its release. i suggest you build most/all your game without any popular engine. use only what you need. then switch your shit over later.

YOUR ANGER will not be less. for your great code will become slower as you make shit work

. just watchout for major resource handling classes you dream up. keep those lightweight . good news? you can be more straightforward since you have no delusions of muh engine.
 

Viata

Arcane
Joined
Nov 11, 2014
Messages
9,885
Location
Water Play Catarinense
Man, you need to do your own engine. That is how it should be.
You want to make a rpg? Do an engine for it first. You want to make a fps? Do an engine for it first.
An engine that works for every genre is shit, simple as that.
That is why I'm studing graphical programming on my free time. Tbh, I think creating my own engine to be more fun than making my own game.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
OP sounds like a graphics whore.

Also seems to be completely unaware that Godot is open source, so you can add a new renderer if you have the skills to do so.

Also unaware that Torque is open source.
 
Last edited:

Irata

Scholar
Joined
Mar 14, 2018
Messages
304
At least Unity has been used for a few fun games. I don't think you can say that about RPGMaker <rimshot>.
 

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,180
Location
Poland
Strap Yourselves In Codex Year of the Donut
i suggest you build most/all your game without any popular engine. use only what you need. then switch your shit over later.

Godot hijacks stuff that's normally the developer's control flow. Skim chapter names. The user can provide his own main loop but it can't control the program flow either. All of logic, rendering, physics happens in a single opaque function outside user's control.

Why the fuck are you concerned with hard shadows vs soft shadows in a rapid prototype.

I didn't state the point clearly enough, sorry. Replace "hard shadows" with any feature "engine" author didn't consider. Needn't be graphics-related. It's not always as simple as implementing it, often there are architectural issues. In case of closed-source "engine" you're so outta luck.

Man, you need to do your own engine. That is how it should be.
You want to make a rpg? Do an engine for it first.

[rant on='semantics']
The "engine" term is thrown around blindly by the Kotaku spawn. In case of Unity or Godot it's a whole workflow tooling, but it's used all the same for ad-hoc code in only a particular title. So "Fallout engine", "Arcanum engine"? What the fuck. Any game code is an "engine" now? I'd prefer to call it what it is–spatial representation code, drawing code, declarative syntax for assets, blah blah.

This is nerd rage but why not say "code" instead of "engine" when not talking specifically about projects like Godot with full workflow replacement.
[/rant]

I can store the basic representation of a same-tileset block with few bytes. Tileset transitions are another few bytes[2]. For storing tile contents (think Fallout scenery, walls, NPCs on hexes, etc.) one can choose a memory-efficient[1] representation. Even if it's meant to be swapped to disk (and it is), storing a dense representation for each tile is overkill. Then I'll store the video representation of static geometry for each 64x64 block in-memory to avoid drawing a large amount of small tiles each frame.

Also unaware that Torque is open source.

If a corporation wanted to fork Linux, how much would it cost it to familiarize programmers with existing code? Take a guess.

Also seems to be completely unaware that Godot is open source, so you can add a new renderer if you have the skills to do so.

Take a look at one of Godot's renderers. It shouldn't be THAT long. Then look at their renderer abstraction. The components know too much about each other if the renderer needs to implement all this crap. These components are separate in theory and they should be. Designing proper abstractions is an craft of its own, see Kiczales' "Art of Metaobject Protocol".

Then don't use Unity or Godot for fucks sake. Use Unreal. Every engine has a potential use and very well suited for certain kind of games.

I never said they have no potential use. Though I certainly overreached flaming Godot's and Unity's users. The software probably works for 90% use-cases. It's just too much though to allow a single library to handle everything from spatial representation, shaders, scene graph, drawing, some AI, program flow, and netcode. Selling the soul to the devil?

Anything forcing a particular spatial representation, on-disk gameworld layout, and other hardcoded premise doesn't work in the project. The project is applying Falcon 4.0's mission generation aspects to a procedurally-generated isometric game. The former had tenths of kilometers visible range. RPG-ish makes for way less, but keeping state for each tile is a problem on its own, even if most of them aren't processed at all. Consider Arcanum if each NPC across all cities had autonomous tasks at all times, processed for even most distant areas. In Falcon 4.0 lingo distant units get "aggregated", in this semi-RPG case the equivalent is pathfinding caching. Another project inspired by Falcon 4.0 is/was Rogue System. In a modern maintained Falcon variant the aggregated units don't make any CPU spikes.

excavator is useless. It allows only to dig holes of specific shape. It is not very accurate and might not work in every environment. Actually competent workers use shovels.

The cheapest excavator model costs 50k USD and the on-site deployment cost is ~500k USD. The device can't be repaired cost-effectively–its planned obsolescence engineering makes it a heap of junk once it breaks within 2-6 months. It's not suited for mining precious metals.

[1] Binary search over Hilbert curve indexing looks more memory-efficient than a tree structure, and is suitable when updates are rare. For higher-degree Hilbert indices can be had from a LUT.
[2] PRNG for both individual tile contents and tileset transitions.
 

Galdred

Studio Draconis
Patron
Developer
Joined
May 6, 2011
Messages
4,338
Location
Middle Empire
Steve gets a Kidney but I don't even get a tag.
That is why I picked moai actually. It is open source, so you can tailor it to your needs, and it only takes care of the rendering. It doesn't force any gameworld abstraction on yourself. The problems are its barely existing documentation and very small user base.
 

Fedora Master

Arcane
Patron
Edgy
Joined
Jun 28, 2017
Messages
27,597
Seems to me that as the access to the tools needed for artistic expression starts to include the general public, the lower the quality of said expression overall becomes. Look at modern novels and the sheer amount of drivel that people churn out. The sad conclusion, then, is to deny easy access to things like game engines or book publishing to the majority of people.
 

Roguey

Codex Staff
Staff Member
Sawyerite
Joined
May 29, 2010
Messages
35,607
Seems to me that as the access to the tools needed for artistic expression starts to include the general public, the lower the quality of said expression overall becomes. Look at modern novels and the sheer amount of drivel that people churn out. The sad conclusion, then, is to deny easy access to things like game engines or book publishing to the majority of people.
Sturgeon's law scales.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,606
"These general tools that focus on platform games aren't designed to perfectly build my obscure flight simulator!" -Twiglard
 

Aiff((AimpliesA)ImpliesA)

Artist Formerly Known as Prosper
Übermensch
Joined
Oct 21, 2016
Messages
287
Godot hijacks stuff that's normally the developer's control flow. Skim chapter names. The user can provide his own main loop but it can't control the program flow either. All of logic, rendering, physics happens in a single opaque function outside user's control.



I didn't state the point clearly enough, sorry. Replace "hard shadows" with any feature "engine" author didn't consider. Needn't be graphics-related. It's not always as simple as implementing it, often there are architectural issues. In case of closed-source "engine" you're so outta luck.



[rant on='semantics']
The "engine" term is thrown around blindly by the Kotaku spawn. In case of Unity or Godot it's a whole workflow tooling, but it's used all the same for ad-hoc code in only a particular title. So "Fallout engine", "Arcanum engine"? What the fuck. Any game code is an "engine" now? I'd prefer to call it what it is–spatial representation code, drawing code, declarative syntax for assets, blah blah.

This is nerd rage but why not say "code" instead of "engine" when not talking specifically about projects like Godot with full workflow replacement.
[/rant]

I can store the basic representation of a same-tileset block with few bytes. Tileset transitions are another few bytes[2]. For storing tile contents (think Fallout scenery, walls, NPCs on hexes, etc.) one can choose a memory-efficient[1] representation. Even if it's meant to be swapped to disk (and it is), storing a dense representation for each tile is overkill. Then I'll store the video representation of static geometry for each 64x64 block in-memory to avoid drawing a large amount of small tiles each frame.



If a corporation wanted to fork Linux, how much would it cost it to familiarize programmers with existing code? Take a guess.



Take a look at one of Godot's renderers. It shouldn't be THAT long. Then look at their renderer abstraction. The components know too much about each other if the renderer needs to implement all this crap. These components are separate in theory and they should be. Designing proper abstractions is an craft of its own, see Kiczales' "Art of Metaobject Protocol".



I never said they have no potential use. Though I certainly overreached flaming Godot's and Unity's users. The software probably works for 90% use-cases. It's just too much though to allow a single library to handle everything from spatial representation, shaders, scene graph, drawing, some AI, program flow, and netcode. Selling the soul to the devil?

Anything forcing a particular spatial representation, on-disk gameworld layout, and other hardcoded premise doesn't work in the project. The project is applying Falcon 4.0's mission generation aspects to a procedurally-generated isometric game. The former had tenths of kilometers visible range. RPG-ish makes for way less, but keeping state for each tile is a problem on its own, even if most of them aren't processed at all. Consider Arcanum if each NPC across all cities had autonomous tasks at all times, processed for even most distant areas. In Falcon 4.0 lingo distant units get "aggregated", in this semi-RPG case the equivalent is pathfinding caching. Another project inspired by Falcon 4.0 is/was Rogue System. In a modern maintained Falcon variant the aggregated units don't make any CPU spikes.



The cheapest excavator model costs 50k USD and the on-site deployment cost is ~500k USD. The device can't be repaired cost-effectively–its planned obsolescence engineering makes it a heap of junk once it breaks within 2-6 months. It's not suited for mining precious metals.

[1] Binary search over Hilbert curve indexing looks more memory-efficient than a tree structure, and is suitable when updates are rare. For higher-degree Hilbert indices can be had from a LUT.
[2] PRNG for both individual tile contents and tileset transitions.


True that you aren't simply going to flip a few switches then copy & paste in your code. I figured as much. When looking through I don't the necessary modularity to do it.

However if we are talking about making a game, without an engine, there are available abstractions you can provide yourself to ignore the issue. That, men, remains true whatever your final engine selection is.

Unless you can prove to us the features of Godot are too far out of reach to most users following my advice building game outside of Godot
(muh common denominator), it's the best available (muh relativism), and saves me/us time creating them (muh numale workflow). Why is this possible? Because Godot probably is an engine.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom