PROPOSAL: Game Development Base

[ShadMOrdre]

After I posted that last one, I realized, perhaps this project from the beginning, should be not just a game dev base, but a coherent dev base in general. MT actually has far greater usage outside of the context of a game engine. Just sayin' :)

runs,

I'm working, within my lib_mat / lib_eco mods to integrate farming, as well as, australia, aoteara, and xocean. Essentially a content compete natural world media pack, but complete with all nodes and functionality. Also, in the greater context of this project, as part of a game world building system.

v-rob,

I'd like to hear some more input, hopefully from others who've I name who have yet to respond. But yes, we should also start discussing structure and other formalities. Perhaps that part might draw others who might still be skeptical. I am fully aware of the history of other projects that have tried and not succeeded or created friction or division. I fully hope to avoid both of those directly, and presumptively. We are mostly all hobbyist and gamers, so that mentality is I think what will guide this and motivate us. ;)

Several of you who've responded already have made contributions to this community and some even to MT. Some of those contributions have inspired this very project, and my mentality towards initiating it. May the core be with us!

Shad

[Wuzzy]

The idea of this project is flawed.

If there is a missing feature that needs to be shared by all games, it should be moved into the engine or builtin. This is for stuff that requires the engine to do things right. Things like “rendering text on a surface”. This will simplify game development a lot. Anything mod-based is doomed to be hacky and bloaty.
Forcing core features in a “base game” means that you're basically just asking all game devs to add tons of boilerplate before they can even start.

If the feature is not essential to all or almost all games, it should be a mod instead. I don't think just throwing a bunch of random unrelated mods together will make a “good” base. Different games need different features so they would rarely use all components. You did not even specify the scope of the project, so you clearly did not put much thought into it.

There are also some problems where there just isn't one correct solution. Games often want their own unique mechanics and it's a flawed idea to try to make a one-size-fits-it-all solution. Sure, you can try to make a massively overblown mod aiming to cover everyone's use cases. But it will be bloated as hell and a pain to maintain. Complexity is the enemy. We should write less code, not more.

Making a collection implies forcing one particular solution/implementation while ignoring the others. That's not going to work.

What we need instead is a curated list of tried-and-tested non-broken actually-working actually-useful API mods so game makers can pick and choose. We already sorta kinda have such a list: https://dev.minetest.net/Mod_interoperability

Entities, especially mobs: This should not just be for a single thing, like monsters. It must work for NPCs, monsters, animals, non-living objects, and things of those sorts.

The problem is that in Minetest, entities suck badly. There are so inefficient in great numbers. They have so many bugs, especially their collision system is so broken as they manage to sneak through solid nodes. The only physics you can do to them is setting the raw speed and acceleration. There is no way to apply a simple force like for knockback. And no, “hacking a proper knockback/force system in Lua” does not count. Before we can have actually good mobs in Minetest, we first need entities that do not suck.

If entities would actually work, many problems that most mob mods have would disappear. Not all problems, however, because our current mob mods, frankly, suck in their own right. I would not vote for including any of them into any collection at this point.

Mapgen features: This might be things like villages, luscious (the mod), cave stuff, etc.

Again, not everyone will need everything. So this smells like bloat alert.

Safe Inventories: This would be an API for making inventories, like chests and bookshelves, without having to define safety functions yourself. This should also cover thing like creative inventories, sfinv, etc.

You have uncovered a missing feature in the Lua API. “Safe inventories” are so essential they should be in engine or builtin.

Protection: Covering a wide range of possible protection methods via different functions

Bloat alert!

Automation: Like pipeworks, mesecons, hoppers, etc but less specialized, so no blocks included, but just raw transfer functions.

There is no single correct approach. For the wires, there are at least two competing rule sets:
1) Signal travels infinitely far
2) Signal dies off after N nodes and you need repeaters of some kind

Key events

Physics

No idea what you want.

[Hume2]

I thought another API which might be handy: An API which generates dungeons using a defined set of rules.

[Pyrollo]

Wuzzy, I mostly agree on what you said but I "feel" there could be another way to dispatch code than engine / mods.

Something like three stage rocket :
- Engine which should provide non specific things (we are far from that) not codable in Lua (for performance or technical reasons);
- Lua standard API : all non specific routines (today : builtin, but it's poor)
- Lua mods : game specific stuff.

Without changing the current architecture, we can yet thing how to separate mods from API and how to gather these API in a consistent set.

[Pyrollo]

A useful missing API is something to manage multiple node objects.

[Xudo]

Another "lets get together and do some cools game" topic.
It is great to see realistic point from Wuzzy about it.

In order to make a usable base upon which games can be developed, and perhaps mods to be created against, I propose a community led effort, hosted on github, to create LGPL2.1 or some other compatible OS licensed collection of APIs and mods to provide game developers, modders, and even players, a method to compose the game of their choice.

Minetest itself provides such API. Game developers, modders and players are able to use it to make game of their choice. It requires some programming skills though. I assume you just want more abstract API. Such layer will increase complexity of the development and you'll possibly spend more time to make some trivial thing comparing with current architecture.

All voices should be heard, because ideas come from everywhere, but the technicalities and realities of software development necessitate that not all voices will be able to contribute in meaningful ways.

Define "meaningful way of contributing", please.

[Red_King_Cyclops]

Regardless of APIs and bloat, I would like to see a collaboration for a game or at least some plans for one.

[voxelproof]

Regardless of APIs and bloat, I would like to see a collaboration for a game or at least some plans for one.

My hint: voxel sandbox genre originated by Minecraft from the very beginning tends to rely on survival mechanics. My proposal is to make a game which might be played either in singleplayer or in cooperative mode, with clearly defined objective, with more mature target group than 8-years old. Actually, to make it really interesting and original it should be a real challenge, difficult but passable, offering a reward of achievement.

Tresspassing difficult, treacherous mountainous terrain (or featuring any other kind of obstacles and dangers, like swamps, quicksands or dense jungle with numerous deep crevices, cold creeks etc.) with a few survival mods enabled (Hunger, Thirst, Temperature, Beware the Dark) with long daytime (to provide time deficiency factor) would combine well known mechanics of simple survival with the more stressful elements pressuring player for rush, jumping game as well as exploration and a bit of horror. The goal would be to traverse whole world (of course with damage irrevocably enabled and apples or other food not so abundant as to make gameplay trivial), escape a massive cave (or the world itself) or reach certain destination. Such maps should significantly limit areas of sea water.

Because it would appeal more to hardcore gamers looking for more weird and original gaming experiences, I guess it would be rather an offer for older players, who don't find endless grinding very compelling or appealing.

[duane]

I think that the problems you're trying to deal with, Shad, might be better solved by a different approach.

Step 1: Put together a modpack of the accepted standard mods -- mobs redo, 3d armor, mesecons, etc. Immediately change the mods' names; they are forks, and should not be associated with the original.

At this point, I recommend a rule that the original creators of a mod NOT be allowed to work on it. You have their input already; it's time for someone else to contribute. Encourage them to work on something else -- they might welcome a change.

Step 2: (This is the hard one.) Document everything. Document it until you can't document any more. Learn things about the code that the creators don't know and write it down. Along the way, make notes on how to improve it -- make it more open, more modular, more general and flexible, with more user-selectable options, easier to replace.

Step 3: Add to the existing code, and continue documenting.

I'm sure every programmer who's read this far is rolling his eyes by now. This project could go off the rails faster than a minetest cart, but I'd rather see it go nuts than see people get bored and abandon it. The whole time, the least you will have is a good modpack that everyone can point new players to and say, "Get that first." You might generate more interest that way.

I know, that's not what you have in mind, but it MIGHT work better.

[ShadMOrdre]

duane,

This is just dead on!!! Quality advise, and well, obviously experience that could benefit a project of this undertaking.

For a quick a dirty look at some of what I have in mind, head over to WIP Games, or Maps, you'll see my dev game concept available there. Yes, a collection of mods, organized into a sensible set of modpacks, each targeting specific areas. Player, World gen, Technologies. There is certainly room for better organization. I've only been able to hash through some of them.

Yes, completely renamed "forks". Forks they are not, but rewritten to separate functionality into APIs or librarys, and others to provide the content. This is the direction.

Sorry, Wuzzy, but most of your points are not valid here. It's not that I disagree that the engine needs work. I disagree, however, that just because something gets done in Lua, that it is hacky. It is code. I don't really advocate hacky solutions either, but I'm not an engine dev. If hacks weren't allowed anywhere, we'd not have Windows, Linux, or any other technology. You think the first apes immediately knew how to make and control fire. They hacked their way through life, getting fire where lightning struck, until some monkey figured out how to click two rocks together. Life is full of hacks......but I digress.

Most of what I've tried to envision for THIS project is that there simply needs to be a single base upon which writing games and mobs is just simpler. This is not about using the built in Lua API, it is about consolidating the various mod APIs into a coherent system. This is NOT a single game. This is NOT to hack at engine deficiencies. It IS to provide what the core devs have asked for, which is more games, much less, better games. The only way this can happen is to gather content and functionality into a set of components that are more easily found, configured and used. Please don't read any more into what you might think this project is or should be. If you want to contribute to the community in positive constructive ways, please join us. If you feel that we are destined to fail, well.... Not sure where you're from or what you've experienced, but when I make up MY mind, SHIT GIT DONE!!!

Shad

[ShadMOrdre]

To expound on the concept a little better.

Mods, IMHO, should either provide functionality or content, but not both.

I do not expect that this becomes some unwieldy project where players have to download some insanely large download to play a game that includes unused content. That is bloat.

Instead, a central git repository, where APIs, libraries, and content can be centrally stored, documented, and accessed. (The forums are not even remotely comparable to a well organized database!) Game devs and modders should be able to cherry pick the parts they need or want for the games and mods they are developing.

Most development, IMHO, will simply be the writing or rewriting of those APIs and libraries to take advantage of new engine features, consolidate duplicated code, and reconsidering some logic. This is, IMHO, simpler than it seems. Why? Because, again, a lot of code is already written. I've been recoding when and where I can, but as many of us have already realized, there is probably more work that one individual can manage within a given time. I certainly don't want to finally have my game ready about the time the MT dries up. I want to make something good, to help keep MTs heart beating for as long as possilbe. When tied with the appropriate other parts, the bigger picture can become more easily envisioned. All it takes is to look at the parts, and try to see how they CAN fit together in a more efficient and cohesive way. I am certainly not the only one who can see a bigger picture, as evidenced by all the projects to make mods and games, all in an effort to make MT more compelling than MTG or MC.

Shad

[Xudo]

Instead, a central git repository, where APIs, libraries, and content can be centrally stored, documented, and accessed. (The forums are not even remotely comparable to a well organized database!) Game devs and modders should be able to cherry pick the parts they need or want for the games and mods they are developing.

https://content.minetest.net/

[Pyrollo]

https://content.minetest.net/

Mmm... I feel like one of the core problems is the poor mod management system.

No centralized name management. This allows several mods to have the same name, creating confusion and leading to mistakes.

No good dependency management. It's up to players to find needed mods with almost no guide (except content db). When developing something it could be much better to have it properly separated with libs in a mod, content in another mod, optional stuff in some other mods. But doing so increase the difficulty for player to install what you developped. The bad solution is to put all things in one, non flexible, big mod.

The "good" solution is to put everything in a modpack. But there is still a question about dependencies, should I put them also in the modpack ? Or should I let the user find the mods by itself ? Also, using a modpack increases the maintenance effort.

I have no "out of the box" solution for that. At the moment I have these missing things in mind:

- Mods and versions (or branches) clearly identified, uniquely named (ok, that's done by contentdb);
- A good mod dependency tree that allow to install a mod and all its dependencies by just selecting the wanted mod;
- Quality check on mods, like "mod release" and "wip mod" in forum but maybe more community based than author based;

[ShadMOrdre]

@Xudo,

If only it were that simple. By your very naive logic, this would imply that all mods available via the CDB in fact work together, there are no dependencies for users to track down, and there are no conflicts or bugs amonst any of the projects hosted there. Sorry. If this is the solution, then I must have overenvisioned something. You miss the point entirely. And honestly, not many people really offer to recreate wheels for the sake of recreating wheels. Obviously, someone somewhere has had an original idea to attempt to fix very noticeable and well voiced issues.

I can only reiterate this point. If you wish to positively and constructively contribute, please do, your ideas and contributions will be welcome. However, concerns regarding one's personal opinions of the usefulness of this project, condemnation of this project because it attempts to address issues in which one may also have strong, if irrelevant or erroneous, opinions, bold predictions of the future of this project, or any other form of non constructive negativity are really not necessary or helpful to this or any other project, nor to the Minetest community as a whole.

Pyrollo,

I'm going to work on some basic code ideas this week. You previously mentioned a dialog system. Have you had a chance to look at AIML, and would you be interested in pursuing something along that line?

Shad

[Pyrollo]

You previously mentioned a dialog system.

No, it was Runs

[Xudo]

I think that implementation of own dependency management system is irrelevant to minetest development.
What about integrating to existing DMS?
Choose from:
luarocks.org
luadist.org
I'm pretty sure, that it is possible to set up standalone repository for these instruments.

[texmex]

I think that implementation of own dependency management system is irrelevant to minetest development.
What about integrating to existing DMS?
Choose from:
luarocks.org
luadist.org
I'm pretty sure, that it is possible to set up standalone repository for these instruments.

If only MT could use Lua packages. They all require an insecure environment in MT to work. That’s not to say that MT can’t use its infrastructure, but I doubt that the people running LuaRocks would be ecstatic about serving media files (textures, sound, other binaries).

[ShadMOrdre]

So I've just posted this Game Dev Proof of Concept over on github. This is not definitive but it works. Modules could be chosen in settingtypes. This really extends possibilities and solves many issues.

Not so much a recreated dependency management system but rather a development framework, built upon and expanding the built in Lua API to provide the functionality needed by games and mods. This is both a code style and framework. Somewhere between a make system for MT, and just another mod, albeit, more of a mod with managment capabilities. In any case, mods would need to be rewritten to work within this highly modularized and customizable system.

Many will argue this is bloat. Well, it may well be. IMHO, I think most users would prefer to download a 100 - 200MB package that has all, or a significant amount of the available quality content in a fully functional state. This is certainly easier to get most users to do, than to get them to search either the forum or the CDB for enough content and all associated dependencies, that is fully compatible, still working for or updated to use the current MT engines best features....

In a sense, this is the sum of my experience in the MT community, combined with general life experience, consolidated into a single usable working, package. Ideally bug free. At least, that is always the goal.

My thinking is along the lines of this analogy; (I don't always use the media player or notepad or calculator on my computer, of for that matter the office package de jour, but I'm glad they are there, providing some additional functionality to an otherwise lifeless and limited OS system. While most Linux distros do not expect you to install the entirety of the contents of the distribution mechanism, either cd/dvd or web based, the distros still provide installable content on their distribution discs. For convenience, as well as, to give folks content, software, something to actually do, a reason to use the distro.)

Shad

[Xudo]

So I've just posted this Game Dev Proof of Concept over on github. This is not definitive but it works. Modules could be chosen in settingtypes. This really extends possibilities and solves many issues.

Could you name exact possibilities and problems what do you keep in mind?
Who is this concept is designed for? Is it for clueless users without coding skills or for programmers who want to make their own game?

[PolySaken]

So I've just posted this Game Dev Proof of Concept over on github. This is not definitive but it works. Modules could be chosen in settingtypes. This really extends possibilities and solves many issues.

Could you name exact possibilities and problems what do you keep in mind?
Who is this concept is designed for? Is it for clueless users without coding skills or for programmers who want to make their own game?

Actually, you bring up a good point. I would really like to create a system with which a person who has no programming experience can create simple blocks, items and mobs.

[ShadMOrdre]

I've been expanding the code that I previously posted. I'd like to include a library of common functionality, code that I've seen in several mods. Not necessarily a specific code sample, but more, the logic of how to accomplish something. And in looking through some of the mods that I think include what should be "core" functionality, I'm also beginning to see just how much depth can be made easily available by following the examples of the code. I'll post my updates as soon as I can tomorrow.

I'd like to ask some sincere assistance in a couple of key areas, from anyone interested in tackling these areas. The first, is to provide a single object interface to the player, the hud, to the map, and to inventories. I'm not sure the specific set of mods, as some overlap, or are forks, or are perhaps even obsolete.

For the player object, 3darmor, clothing, skins, multiskin, skinsdb, wardrobe, appearance/character_creator, player_monoids, player_api, late, awards, quests, skills_framework, and a few others that are relevant and specific to a player.

For the HUD object, hudbars and it's derivatives, hud_wheel, hud logic from Sys4_Quests, and some additional functionality.

The map object should provide world generation functionality, customization and presets, as well as defining all nodes, ores, liquids, and other basic nodes that are available or are generated at worldgen. This should also provide simple methods to get biome/heat/altitude/pos data, as well as simple methods like mapfix, mapping, and other world changing methods.

Safe inventories were mentioned. Player, detached, and meta inventories should maybe be wrapped in methods within an object, and detached from formspecs in general.

One key decision that I've made, regarding node registration, is to centralize registration at the game level, and to register ALL nodes, entities, craftitems, and all other inworld items to the game object. This essentially means that all nodes will be registered as "game:new_node". This will simplify identification of node name and craft recipe conflicts, as well as simply removing the code necessary in every mod to separate the node name from the mod name. Items will be referenced simply through their name.

Please, if you are still willing to contribute, if you'd list your skills and interests, we can organize ourselves into projects easier. Let me know what you think.

Shad

[ShadMOrdre]

Hello all,

I've posted an update in the dev branch to the Game project page on github. I am going through some of the mods that I use, extracting what I consider to be core functionality.

Please let me know if this is a good direction. I know some will contain of bloat, but I can say that code is rather small in comparison to the media that is downloaded. If the code can be provided in an easy to use manner, almost self-explanatory code style, I do believe that game creation can be more easily achieved.

Shad

[voxelproof]

Hello all,

I've posted an update in the dev branch to the Game project page on github. I am going through some of the mods that I use, extracting what I consider to be core functionality.

Please let me know if this is a good direction. I know some will contain of bloat, but I can say that code is rather small in comparison to the media that is downloaded. If the code can be provided in an easy to use manner, almost self-explanatory code style, I do believe that game creation can be more easily achieved.

Shad

Sounds like a good idea to me. I think that in the longer term effective usability of mods can be achieved only by making them as simple as possible, and as modules which could be assembled into larger wholes.

[texmex]

Sounds like a good idea to me. I think that in the longer term effective usability of mods can be achieved only by making them as simple as possible, and as modules which could be assembled into larger wholes.

This would be ideal, but such ecosystem would require much more guidelines on how to write mods in a way that’s also modular and dependent.

[ShadMOrdre]

texmex,

This is where I think the involvement of others is critical. I must concede, that I may not be the best person to lead the technical aspects of this project, simply because there is most likely someone out there who is just better skilled than I at Lua, software dev, API dev, or any other aspect of this project.

I would like to essentially see all inworld items get centrally registered under a single object. This does not just apply to my previous statement regarding node defs, but in a larger context. Here, I mean that the APIs and libraries that are being used should at least be accessible from a globally defined game object.

In my view, this amounts to assembling the pieces into a coherent system. Broad, generic statement, I know. Think, Linux, or your particular distro of it, is composed of many different parts that make up the whole system. Programming for it is a .... to say the least. Windows, in its earliest iterations was also painful. MS largely addressed this with the .NET framework, essentially combining the parts into a singly unified structure. Granted, .NET is a ..... to program against, but it is far better than earlier days.

So this project is an attempt to create that framework. Assembling the key components of gameplay mechanics, player management, and general functionality, and then providing that within a centralized framework. There are parts of MT I haven't even begun to play with, but I know others have deep understanding and experience in those areas. One of those is your own item_drop mod and its modifications to builtin. You've also contributed some other mods I find in my collection, so would want to have that experience. There are others who've done the same, and I can only surmise, due to my own limited modding, that maybe others might be better experienced for aspects of this project. Duanes' excellent advise a few posts back reflects another individual who has perhaps better experiences than I in areas where your intial question could be better answered.

texmex, I can really only share the small part of the vision I see, the same vision that I think others have also seen. However, there is only so much that can be conveyed through this medium. Online collaborations all seem to suffer from the lack of shared space; when trying to work together, this really impedes things. But hey, we're still here!!!

Shad