My project is becoming kinda large. It's far from a structural sprawl but I feel the need for method. How do you organize your game projects in a clear, coherent and maintainable way? My project will probably consist of 25 to 50 mods, many of them written from scratch. The project need to be structured in a clear manner not only for myself but for collaborators as well.
Currently I'm using a mod directory structure inspired by MCL2, made up by pseudo modpacks like so:
API
AUDIO
ENTITY
HUD
ITEM
PLAYER
WORLD
_DEV
_TESTING
I put a mod in the directory that seems like the closest fit, but with 3rd-party mods it's not always easy to choose.
Aside from simple directory-based mod sorting, structuring my own mods internally is also an issue. What approach do different makers here recommend?
All nodes in one mod called "nodes" or
concept-based mods similar to MTG?
All media files such as sounds and textures in one place for easy access or
spread out across mods?
And so on.
I'd especially appreciate feedback from the makers of Inside the Box, MineClone 2 and Infinite IKEA, as those stand out as well-structured projects.
Last edited by texmex on Sun Sep 29, 2019 20:32, edited 1 time in total.
The way IKEA is structured is mostly concept based, where chunks of things are split up into related mods. Anything IKEA-specific has the "ikea_" prefix attached to it's name, while the more generic mods have more generic names (both have generic item names though, like "chairs:vedbo"). For example, the "ikea_furniture" and "ikea_time" mods both set up functions and APIs related to their respective domains (furniture registration and time/day-night cycle respectively), while the mods "player" and "music" are both generic enough to have widely-applicable APIs suitable for any game, even if the implementation is IKEA-specific.
lib_base: Basic mods that affect the system, like areas, chat_bubbles. Optional mods.
lib_geology: lib_materials, lib_ecology, all world building, node defining and node behavior type mods.
lib_interface: sfinv, and doc
lib_player: player_api, armor, appearance, monoids, sneak_glitch, and all other player related mods.
lib_develop: mods that are useful for dev. worldedit, commander, lib_tool_schematics, listitems, and others.
lib_additions: display_lib, lib_towns
lib_items: mods that are neither tech or tool, but provide useful content.
lib_life: all mobs
lib_technology: digilines, pipeworks, mesesons, advtrains, waterworks, hoppers
lib_tools: lib_handtools, lighttool, torch, lib_chest, lib_forge, lib_climbing, lib_lighting, lib_armor, lib_trm
I am consolidating most of these at the moment. Most of the player related mods will get integrated into a single lib_player mod. The develop mods are useful, but since they provide no "game" content or functionality, this gets used as needed. The other categories are, again, in the process of, or a storehouse for mods to be consolidated, refactored, or otherwise utilized. I have no plans to modify any of the "technology" mods.
I'll try to get some of this posted before the weekend, as it is an almost playable game. Now to just decide which kind of game, RTS, RPG, 4S or a combo of all of them. Really, it's getting this far along rather quickly.
Turns out, for anything decent, content is King! Content, content, and oh yeah, don't forget the kitchen sink content. For all those that have complained about the uselessness of some item, just remember, there needs to be stuff for modders to still use, without overloading the few items available. And useless game content is preferred to a static, empty world, where only those things needed for game completion are the only items in world. Most games are not like this. GTA, Elder Scrolls, Fallout. Tons of useless items, and tons of depth and game RE-playability! Don't forget the content.
The trick, is to then whip the content into shape. This is easily done by organizing all the data, as a DB would, into tables of info, that can make finding details and references far easier. A data set that ultimately is the entire game.
