Game Platform Discussion, Mod Direction

This has been a discussion over the past few days in the age series development Discord server; we've been trying to decide what we want in a platform for the game. I want to formalize that conversation so other people can share their ideas in one place.

@Baughn had voiced that he'd be willing to help in spare time with writing network primitives or implementing fun circuit features in the game. He also mentioned that making our own 3D game might be a pain in the arse.

@Caeleron is more interested in writing our own engine that can do whatever we want and not depend on Minecraft's release cycles

So I kinda want to have a more general conversation about this because we're not sure if we want to stick with Minecraft, or make our own game.

I do have a hard restriction in that I don't want to write mods for any games that require payment besides Minecraft (and maybe Vintage Story with a strong enough argument), since I want to make sure that people can enjoy our game/mod without needing to pay to play. I'm willing to make exceptions for Minecraft because it's literally one of the most bought games, and development mode can be run without needing to own the game (although I encourage everyone to stay legal and pay for the game if they play it). Vintage Story.. only because I said that we might mod for it.

I'm open to writing this game for more than one platform, but I think that we need to focus on writing it for one platform first.

I'm going to add some pro's and con's for each platform.

Minecraft

Pros

Established modding community
Kotlin/Java - easy to bring people on who know Java, which is a very common language.
Lots of existing mods to provide interop and reduce development time if we can leverage some of their features until we can make our own

Cons

6 month release cycle of Forge/Minecraft that often becomes a major porting effort because Minecraft is not a rolling release but a static release.
Modding an existing game that may not have features we want; crafting needs a revamp/replacement

Vintage Story

Pros

Established community
Realistic ore generation out the door
First-class modding API
Very nice biomes and rock formations

Cons

Engine is closed source (unlike Minecraft where everything is at least visible source)
Modding community is mostly based around plugins (which are decently powerful but not sufficient for complex mods)
Modding API may not be stable, might not have required features
People have to buy a new game to dev/play

Our own (3D) game!

Pros

Can add whatever features we want
Can be whatever language(s) we please

Cons

Many edges that we need to re-learn and wouldn't already have from an existing game
It will take a long time and might not really be worth it (current developers have only ~10hrs/week of time at best)
World generation
If it's not Java (or C#? - is that really popular among modders/gamers?), might not have many people familiar with the language

Similar Games

There are various similar games out there that I want to look to for some ideas, but there are some things we like/don't like about certain games

Satisfactory

Very pretty - incredible 3D graphics and per-generated world
Relatively well designed crafting system
Resource nodes as opposed to mining makes worlds less.. cheesy.

Stationeers

Powerful atmospheric system
Decent crafting system based around realistic (ish) machines
Interesting world generation pattern; not a voxel game
Poor ore generation, virtually no biomes (somewhat by design)

Factorio

Does a lot for being 2D
Fantastic crafting/automation systems
Lua modding is cool
Strong community and modding

I'm sure there are some other similar games out there, these are just the ones on the top of my mind.

Sorry if this is a bit of a ramble. Please feel free to share your thoughts and other pros/cons; you don't need to be a developer to provide feedback, I want to make sure that we head the right direction and would love any input.

I would say stick with Minecraft. I honestly think Minecraft is just the perfect platform for something like this mod, and the freedom for us to mix other mods makes perfect for us to have fun. It is a bit hard to keep it in speed with actual MC versions, but given that still, even today the better technical-based modpacks exist for the 1.12.2 versions. There are still plenty of mods which aren't ported to higher versions. A Custom Game sounds fun but (I mean even with almost no expeirence in development of one) it sounds pretty hard.

One thing I will add.. The Minecraft option is only for 1.16 or 1.18+. Minecraft development for 1.7.10/1.12 is off the table due to Gradle issues and other problems that are fixed in newer Minecraft versions that are far too much effort for us to backport (eg, newer Gradle versions in Forge, support for new Java 17, etc.)

I would opt for our own 3d game. I can imagine a survival / sandbox tech game where the player doesn't have anything infinite. Maybe we could use marching cubes for terrain.

I think the "own game" is a HUGE scope increase from making a mod. How long has it been for Elooram? She done with RedPower, the game? People find it exciting, but underestimate the scope of making a game.
Unless you guys are thinking of a 2D top electrical "cad" kind of app.
As for the "similar games" I think a lot of electrical age would lose it's purpose in these games. Stationeers, Satisfactory already have equivalent machines.
Factorios already has "electricity" so it be more of a "total convertion" than an addon.
In Minecraft/Vintage story, it adds to the progression of survival, so I think that's where it finds it's purpose.

If you guys are so incline to "do maybe more than a mod" wouldn't basing it on Fabric instead of forge bring about a faster dev cycle? That would probably entail a scope increase, for sure, writing base library to duplicate forge functionalities, but the increase would be well bellow "making a new game".

I think, with the size of the possible "manpower" and the nature of most contributors going in amd out, I'm not sure a whole game is a good scope.

On the other hand, while fabric would mean maintenance of underlying libraries, it would be easier to stay on the "tip" of Minecraft. If the objective is to be more "agile" in the develpment, I would say that should be tue favored aproach.

If you don't care about being on tip, then forge and a more traditional dev method (like rational unified process, kinda) might work out better.

So, what do you guys wanna do, more libraries, but stay closer to the tip, and have more control (and responsabilities), or have a more rigid and complete development environment, that might not go the way you want, and releases slower?

It's not like there's been a lot of releases for multiple minecraft versions, so is the slow release cycle really a problem for this mod? Is "release early, release often" and staying on the tips of Minecrat versions a tying you want now? Are those requirements you want in the project?

Also, instead of "from scratch completely", basing it off something that exists, like infinyminer, would reduce the scope drastically.

As for the "similar games" I think a lot of electrical age would lose it's purpose in these games.

I probably should clarify that I listed those games because I thought they had attributes we liked, not necessarily that we could/should mod for them. We've talked about modding all of them at one point or another, but we determined that it would be infeasible/impractical. (I already mentioned about avoiding paid games so that's off the table anyways).

wouldn't basing it on Fabric instead of forge bring about a faster dev cycle

No, unfortunately.

writing base library to duplicate forge functionalities

This is sometimes called core-modding and it's far more difficult than just using Forge.

I think, with the size of the possible "manpower" and the nature of most contributors going in amd out, I'm not sure a whole game is a good scope.

I tend to agree with this sentiment; writing our own game is a bigger lift. But, potentially, it can introduce more interesting mechanics. There are both sides to this argument which is why I am looking for feedback.

It's not like there's been a lot of releases for multiple minecraft versions, so is the slow release cycle really a problem for this mod? Is "release early, release often" and staying on the tips of Minecrat versions a tying you want now? Are those requirements you want in the project?

I should explain the situation better -

Kotlin and Gradle are updated often. It usually brings with them very nice features. Forge has had a history (until recently) to not update these dependencies in a reasonable period of time. But more importantly, every time that there's a new Minecraft release, Forge changes their MDK to make the best use of those new features. Fabric does the same; having a stable API is not really possible/feasible with Minecraft's release model. But, what we really need for a good mod (ie, focus on features over porting) is to have such a stable API. If we were to make our own game, we would have complete control over the cadence that we update the codebase and we would not need to worry about making sure that our modification works on the latest version of Minecraft, and instead focus efforts on more important functionality.

BUT.. this comes with a con - not using an existing platform like Minecraft means that we do not get updates for free. ie, we don't need to spend time implementing cool features that are not really aligned with our plans such as improved world generation, more textures/mobs/blocks, advances in rendering pipelines, etc... also, using an existing platform means that we get to use the learning of their mistakes or edge cases as part of our code; we don't have to learn weird edge cases in video drivers or other stuff that Minecraft has already done (as an example).

What I was getting it is that, yes, while core modding is hard, it's scope is WAY lower than the one of a full game. So, if you want to break free frok Forge's update cycle, teaming up with a couple of like minded projects on Fabric, and pooling ressources doing core modding, might give a better flexibility and more rapid development cycle than usijg forge, while still keeping the scope WAY bellow that of a full game.
And, by trying as much as possible to limit the interface size to Minecraft, it might make the rest of the mod's code stable.
When you try to code to an interface that keeps changing, make an adapter in between your code and the interface, so you just have to change the adapter between versions.
Limiting what is being used in the interface, would make the adapter smaller, and thus easier to maintain.

I know this is supposed to be Forge's job, but it doesn't seem to be happenijg that much/well with it.

That's why I brought up fabric.
If you're willing to consider the scope of a whole game, surely tye cost of coremods would be smaller.
And you'd only have to deal with Minecraft's particularities, not everything that comes with making a whole game engine, and having it work on multiple platforms and os'es. And I don't think you'd have the same playerbase opportunity either, starting from scratch.

I would also have said "help forge out" as an alternative, but I don't think that's possible.

Something also to note is that Vintage Story was the result of TerraFirmaCraft asking the same question.

The reason why we are considering our own game is because we've thought of other features besides electrical simulation that MC would not be able to support nicely. We would end up ripping out major portions of MC to fit what we want. Also, mod interoperability was something we realized was not going to be feasible without doing a bunch of work to make sure they don't break everything. Oh, and Fabric isn't strong enough to make all of this work so we have to stay with Forge.

Take ore processing for example. We want for processing age the ability to process ores realistically rather than taking "X Ore" and roasting it in a tiny furnace with the capability of a wood stove into pure "X Ingots". We would first need to get rid of vanilla smelting (This breaks all other mods ever). Turns out there's not really such a thing as "X Ore", but a series of minerals that you could extract elements from. And they are mixed in with a bunch of other minerals that you don't want. So now we need to replace all of Minecraft's stone generation. A mod like this can combine with other mods to make the game impossible to play due to the fact that you don't get Cobblestone as easily as in vanilla. This also begs the question of where realistic ores come from in the first place. From geological evolution of the land, so the land has to be generated from deterministic methods rather than a bunch of noise that looks like real terrain with sprinkles of treasure throughout a flat rock type. This eventually leads us to concluding we have to toss the terrain generator entirely since now we have to build the whole thing from scratch to be realistic. So either way we're making that from scratch, but in MC we have to make sure we don't destroy the rest of Minecraft where in our own game there wouldn't be any additional systems to clash with.

tldr: Minecraft will require a lot of hacking stuff together to make work. Going from scratch means we have a blank slate and don't need to waste time fighting everything else.

@MrBigss -

So, if you want to break free frok Forge's update cycle, teaming up with a couple of like minded projects on Fabric, and pooling ressources doing core modding, might give a better flexibility and more rapid development cycle than usijg forge, while still keeping the scope WAY bellow that of a full game.

If you want to do that, you develop Forge. Because Fabric is literally just a stub of Forge. The development time of said coremods is literally the same as the development time of Forge. Fabric and Forge often both release at the same time and have the same bugs, the difference is that I don't want to invest the time or energy into making Fabric be Forge. Because that is just Forge.

Forge is not the problem, it's just part of a long list of considerations. Forge has been much better recently, but that also implies with it that you are bound to updating the mod as Minecraft updates; pinning Forge to a particular version because it has "everything you need" is not a growth mindset and eventually you'll be in the position we are in now.

And, by trying as much as possible to limit the interface size to Minecraft, it might make the rest of the mod's code stable.

THIS is the right idea. We totally intend to do this; that is why we have "age series" instead of Electrical Age, because we realized that we need to actually break things apart to be able to manage them and their dependent solvers/simulators, etc.

I know this is supposed to be Forge's job, but it doesn't seem to be happenijg that much/well with it.

Making Fabric into Forge to do Forge's job isn't particularly appealing.

If you're willing to consider the scope of a whole game, surely tye cost of coremods would be smaller.

This misses the point - Minecraft updating is the issue here, not the cadence that Forge releases. We would still need to update those coremods on Minecraft update releases... which duplicates effort Forge does.

And you'd only have to deal with Minecraft's particularities, not everything that comes with making a whole game engine, and having it work on multiple platforms and os'es.

This is why I don't want to abandon Minecraft so quickly for a custom engine.

I would also have said "help forge out" as an alternative, but I don't think that's possible.

Hundreds of people have done it; I'm not cut out for this work but it's defintely something we could pull request against.. besides Minecraft, we can do pull requests into any of our dependencies with features/bugfixes we need... and Minecraft.. well, we just need to hope that Mojang prioritizes the issues we report on their bugtracker.

@Caeleron -

We would end up ripping out major portions of MC to fit what we want.

You and I talked in depth about my vision here, but I don't think that we need to start by ripping up Minecraft to achieve our goals. The two can coexist. We just build on top.

Also, mod interoperability was something we realized was not going to be feasible without doing a bunch of work to make sure they don't break everything.

I have some ideas around this.. we effectively turn it into a social game. We have a website and we say "Works well with XYZ mods" and audit frequently if we think they are realistic enough. If so, they get "Jared's Seal Of Approval!" and the satisfaction that what they are doing is realistic enough that I think they would pair well with our mod... at least in theory.

A bit less egotistical method would be just for me to provide a modpack that has a very nice configuration; if other mods want to break our mod, other people are welcome to have that poor experience with that modpack and decide that they want to try something more challenging.. the point here (and to which we talked about in person) is that people have choice to do what they want to do that is fun, and I can help them get there if they want to be more realistic with it.

In the end, it's going to have to be that we offer to mods that they can interop with us but expect that they do things a particular way if they want to have our recommendation. Anyone can interop with us and there's no point to blocking someone creating a billion trillion kilowat survival voltage source from the bodies of zombies if they want.. I am mostly indifferent. But, it wouldn't be the way I want to play.

Take ore processing for example. We want for processing age the ability to process ores realistically rather than taking "X Ore" and roasting it in a tiny furnace with the capability of a wood stove into pure "X Ingots". We would first need to get rid of vanilla smelting (This breaks all other mods ever). Turns out there's not really such a thing as "X Ore", but a series of minerals that you could extract elements from. And they are mixed in with a bunch of other minerals that you don't want. So now we need to replace all of Minecraft's stone generation. A mod like this can combine with other mods to make the game impossible to play due to the fact that you don't get Cobblestone as easily as in vanilla. This also begs the question of where realistic ores come from in the first place. From geological evolution of the land, so the land has to be generated from deterministic methods rather than a bunch of noise that looks like real terrain with sprinkles of treasure throughout a flat rock type. This eventually leads us to concluding we have to toss the terrain generator entirely since now we have to build the whole thing from scratch to be realistic. So either way we're making that from scratch, but in MC we have to make sure we don't destroy the rest of Minecraft where in our own game there wouldn't be any additional systems to clash with.

I'm going to address this with a single point.

When we get to the stage where we offer different ore generation and different smelting and stuff; yes, we will need to modify that behavior. And yes, we will need to provide some backportability into making your normal stuff.

BUT

We won't be there for a while, and I don't want to make TerraFirmacraft where you can only have our world gen. If someone wants Vanilla Minecraft gen, we could always go with a more GregTech-ish ore vein model with the search tool, or we could go more of a Satisfactory resource node model, based on a 2D (or 3D) virtual ore map.

I think that we've got a decent amount of input so far but I still want to hear what other people's thoughts are on the subject.

That said -

I am currently thinking that targeting for Minecraft 1.18 is the best option, and for us to try and get up to speed with something that we can present once some of the other mods are finished porting so that we can have some interesting features (even if minimal) that start to lay out the path where we are going and the fact that we exist. Once we have that, we can decide that nothing worked and we're back at square 1, or we see that people start wanting to develop the mod and start making it something, to eventually be moved into it's own game with a set of loving developers (more than we have now so it's actually achievable).

Otherwise, we have entered the world of unfunded indie games.

Let's aim for the achievable, with the sights on the moon.

I think this discussion has come to a conclusion.

age-series / ElectricalAge2