I love mods, and people are talking a lot about mods, so let's do more talking about mods.
A lot of people are annoyed that Unity and Unreal don't make modding easy... but modding has never been "easy".
Flash, CryEngine, IdTech, RPGMaker... none of them are "moddable" right from the ground up. Modding has always been something the devs decide to include.
With that in mind, we can talk about mods in two ways. From the perspective of the person installing the mod ("player"), and from the perspective of the person making the mod ("creator").
---
From the player's perspective, there are probably three kinds of mods:
1) Piecemeal Content
This is content that will almost never conflict with other piecemeal content, except in the most trivial ways. Piecemeal content is probably the most popular kind of mod, including things like recruiting other players' characters, sharing messages about sun-praising, downloading vehicles from the workshop, adding new skins, etc.
2) Local Content
This is content which will conflict with any other content in the same locale. For example, if you install a mod to turn you into Bayonetta and a mod to turn you into Link, they won't get along. Similarly, you can't be in two levels at once, two missions at once, etc.
Local content can be turned into piecemeal content if you add a tool to help the player manage this kind of conflict - for example, Bayonetta and Link can both be "skin options" instead of simply overriding your appearance.
3) Core/Process
Some mods change fundamental rules of the game. For example, Skyrim mods that make character progression different, or change how weather works, or make you need to eat and sleep, or make the shaders work better.
Sometimes the mods are completely invisible, such as mods which allow other mods to work, or mods that clean up memory usage.
Frequently, core/process mods are part of a chain of required mods, like 'install the event mod, then the silent talking mod, then the progression revamped mod, and only then you can install the custom skill pack'.
---
The reason to think of mods like this is simple: it helps us to think about how mods work within our game. Can our game support piecemeal content additions? If the gameplay allows for certain kinds of piecemeal content, what is required to surface that and allow the players to load it in? If the game can support local content, can we change the way our game presents it to turn that into piecemeal content?
Can our gameplay support core/process mods? Can our game architecture? Can we revamp it? Can we create a tagging system so that we can have mods say what other mods they require, at what version?
The answer is rarely a flat yes. This kind of thing is a bit difficult to engineer, and it may damage your core gameplay. But even a small amount of moddability is a good thing, and you can leverage it to either make your game more appealing or make your game stickier.
For example, in Guacamelee, the only kind of moddable content is custom skins. However, they sent out custom skins to popular YouTubers, enticing them to play the game and be more positive about the experience. The modding made for great outreach.
---
The other half of the equation is how the creator of the mod thinks about the mod. This is equally important.
1) Diegetic assembly
When the creator never leaves the game to create the content. In the best case, the content is created simply by playing the game, but nearly all of the time this is an in-game editor. For example, you create your character, build your ship, assemble your house - all using an in-game editor.
The key here is that diegetic assembly happens in the course of normal play. A character builder counts because every player will use it at least once and consider it part of their playthrough, their experience. A mission editor generally doesn't count, because it's never used in the course of playing the game.
There is a challenge to keep the editor simple enough for everyone to use but powerful enough to let players create complex or nuanced results. There is also a challenge to leverage the editor: a character editor for a game where you only create one character is not as well-leveraged as a game where you create multiple characters over the course of the game.
Compare The Sims' character editing to Fallout 4's.
2) Tool-assisted assembly
The creator uses a separate tool to assemble the content. This tool may be in-game, such as a mission editor. It may be out-of-game, such as photoshop or visual studio or even just notepad. Either way, this is a thing the player has to go and do, separate from playing the game.
This is quite a hurdle. Few players will go and use a tool that is not required over the course of play. Because of this, it's usually ideal if you can leverage a tool in both the main gameplay and as an asset creator. Normally this is done by using the same tool, but having a creative mode where the player's specific play constraints are relaxed.
Done well enough, this turns into diegetic assembly.
Core/process mods are a good example of mods that are almost always created with tool assists. It is exceedingly rare for a game to allow its own rules and progressions to be overwritten in the course of play. Normally these mods are created with visual studio or notepad, the code then injected back into the game.
3) Hacked assembly
If the creator has no way to add their mod to the game, they may hack the game to force it to accept the new content.
You might consider this similar to a tool-assisted mod at first glance, but a tool-assisted assembly uses an injection method the developers intended for modders. That text you edited, that DLL you compiled, the game goes out to look in that directory for those things because the dev decided to support those kinds of mods in that way.
Hacked mods usually take advantage of things the dev accidentally left available instead of intended for mods. For example, they might be "trainers", hacking the game's memory space to give you infinite health or cash. Or they might overwrite the game's core assets with new assets.
As a game dev, hacked assembly is something to avoid. Mods assembled via hacking almost always conflict with other mods just due to how they work, so it's best to try and create a proper interface for mod injection.
---
When I think about mods, that is how I think.
What kinds of content can be injected? What kinds of tools can I use to make that injection easier, more useful, more potent?
What methods of creating content are there? What kinds of interfaces can I create to help modders create mod packs and chains of mods that don't conflict?
Unfortunately, no game engine natively supports this kind of thinking, because it's part of every individual game's unique design. There's not really any low-hanging fruit here: you have to design your game to be modded.
Showing posts with label modding. Show all posts
Showing posts with label modding. Show all posts
Friday, April 19, 2019
Monday, June 29, 2015
Abusing the Pipeline
One of the things I've done a lot of work on is allowing player content - whether through mods or in-game creation tools. More and more, I've come to think that in-game creation tools are not an efficient way to do it. I mean, if you can manage it, sure, but there are a lot of reasons to avoid in-game creation tools.
First, they are effectively duplicating tools. If you use Unity or Unreal, those come with powerful content and scene editors. Creating an in-game editor literally duplicates that functionality. It's far more efficient to allow players to create their content in Unity or Unreal, and then distribute those packages. Giving your players a subset of the game that they can open in Unity or Unreal is a powerful idea.
You have to adjust your pipeline, teach modders to pipe output to an import-friendly asset pack. Unity makes that pretty easy. Not sure about Unreal. But compared to recreating the entire editor and save system, creating a runtime compiler, bugtesting... well, it's much easier to teach a modder to create asset packs than all that!
But that got me to thinking. Once you think about using Unity or Unreal as a mod creation platform, you start thinking about the asset pipeline into them. And out from them.
There's a lot of potential here, I'm just starting to wrap my head around it. Let's start with the basic act of creation.
We're creating star ships. We create them in the Unity editor. As a player, we use the Unity editor. We find the various prefab starship components we want - engines, generators, chairs, beds, landing gear. We put them in the scene, tie them together as a new prefab, maybe rig the system to point to itself in various ways so that, for example, the turrets can't turn on if the landing gear is down.
Export the resulting prefab (or pack of prefabs, maybe you built a fleet) into an asset pack. Share the asset pack with whomever you like, and suddenly it's in our game, Space Ranger Example Game 2000. Your ship is in the game, performing quite well. The turrets only turn on when the landing gear is up, the engines draw power from the reactors and push the ship around, it's all great.
This allows players to build starships without a grid. They use Unity's powerful tools (including optional grid-snap or vert-snap) to lay their ship out with incredible freedom. Collision boxes are automatically computed.
This allows players to build custom variants. New materials. Different animations. Just swap that stuff out and the custom variants will get included in your asset pack, free from any chance of collision with other animations and materials from other star ships.
It also allows players to build custom code or UI, easily packing it into the asset pack. If you want to use AntiSpaceRanger's Cool-Ass-Holographic-Ship-UI, just throw it in and it'll be included into the prefab, whether or not the next player down the line downloaded ASR's CAHS-UI on their own. Create your own UI, if you like.
But... this is not the limit. Not even vaguely.
See, since you're using Unity or Unreal, you can import new assets. A new Blender file. New sounds. New video clips. New textures. Let's focus on Blender.
Your starship can be any shape using the prefab starship components. You can scale them, tilt them, place them in any way you like. But there's no reason to limit yourself to those prefabs, especially when it comes to interiors or complex, smoothed hull shapes.
Why not take to Blender (or Maya or whatever)? Use the library file included with the modder package, and you can import those prefabs into a new Blender file, arrange them in Blender, scale them in Blender. Save it, and in Unity, a finished ship will pop up. A minimal amount of processing can match the Blender objects to their identically-named prefabs and swap them out in the ship prefab - essentially translating your Blender file into the exact same ship you would have gotten by dragging and dropping Unity prefabs.
Except...
You can add more things in Blender. A hull that is any shape and texture you please. New animations. Skeletons. Unity understands all these things, and we can process some of them into game logic - for example, our custom hull elements can be correctly classified and prepared for damage effects.
How far the modder wants to go is up to them. A new animation controller. A ship that flexes and ripples like an organic creature. A ship that grows or shrinks on command. There's a lot of possibilities, limited only by how well the game code copes with weird-but-valid Unity objects.
The ability to shape your own hull really can't be overstated. Passive elements such as rails, running lights, steps, windows, and simple smoothed hull elements are incredibly valuable to the average person. Voxel-based approaches give you some freedom, but there is absolutely nothing like being able to arrange them freely. That requires us to be able to distort and reshape them - something that is easy in Blender and extremely annoying in Unity.
A long, curving hand rail is easy in Blender. Import the hand rail object, stretch it, and curve it. Fit it to your ship perfectly. Unity imports it and it's in your ship! Bang!
More than that, assuming your naming convention is good, Unity understands that it is a hand rail, and will use IK to have nearby astronauts automatically slide their hands along it. That's super-easy, I've done adaptive animations like that a lot. You just need to have the object properly tagged!
(Making custom spaces feel real is incredibly important - I would pay special attention to making adaptive character animations, including things like turning sideways to move through tight areas or stepping easily to the side as you approach furniture.)
Pretty neat, right?! RIGHT!?! yeah.
...
Oh, right, I forgot the other half.
It's possible to make game assets viable to import into any similar game. SREG2000 assets could be imported into Shooty-VR-Game-Ultra. The only limit are class and library dependencies built into the asset package.
It is possible to minimize library and class dependencies by having the ship focus internally. While it's unlikely the same asset pack would load up in both SREG2000 and SVRGU, it would be relatively easy to import SREG2000 content into the SVRGU mod editor (both Unity projects), then winnow out the dependency errors and re-rig the ship for SVRGU use. The core - the meshes, materials, animations, etc - would be the same.
It is possible to create a database of, say, complex space ships. Not simply models: high-functioning ships that contain dozens of internal logic objects. For example, a class that opens and closes a hatch when triggered. A class that runs a specific trigger name on someone's mecanim animator if activated by them. A class that displays the state of that hatch. Because these classes are internal to the ship, there's no real chance of them colliding with game logic. Therefore, these classes can be packaged with the prefab, or packaged with the core idea of the mod editing system for both games.
Sounds interesting!
And, more importantly, sounds viable. Even if you remove all of the advanced features, simply allowing players to create new prefabs out of stock prefabs is incredibly powerful, especially if you can wire components together with references and events and delegates.
First, they are effectively duplicating tools. If you use Unity or Unreal, those come with powerful content and scene editors. Creating an in-game editor literally duplicates that functionality. It's far more efficient to allow players to create their content in Unity or Unreal, and then distribute those packages. Giving your players a subset of the game that they can open in Unity or Unreal is a powerful idea.
You have to adjust your pipeline, teach modders to pipe output to an import-friendly asset pack. Unity makes that pretty easy. Not sure about Unreal. But compared to recreating the entire editor and save system, creating a runtime compiler, bugtesting... well, it's much easier to teach a modder to create asset packs than all that!
But that got me to thinking. Once you think about using Unity or Unreal as a mod creation platform, you start thinking about the asset pipeline into them. And out from them.
There's a lot of potential here, I'm just starting to wrap my head around it. Let's start with the basic act of creation.
We're creating star ships. We create them in the Unity editor. As a player, we use the Unity editor. We find the various prefab starship components we want - engines, generators, chairs, beds, landing gear. We put them in the scene, tie them together as a new prefab, maybe rig the system to point to itself in various ways so that, for example, the turrets can't turn on if the landing gear is down.
Export the resulting prefab (or pack of prefabs, maybe you built a fleet) into an asset pack. Share the asset pack with whomever you like, and suddenly it's in our game, Space Ranger Example Game 2000. Your ship is in the game, performing quite well. The turrets only turn on when the landing gear is up, the engines draw power from the reactors and push the ship around, it's all great.
This allows players to build starships without a grid. They use Unity's powerful tools (including optional grid-snap or vert-snap) to lay their ship out with incredible freedom. Collision boxes are automatically computed.
This allows players to build custom variants. New materials. Different animations. Just swap that stuff out and the custom variants will get included in your asset pack, free from any chance of collision with other animations and materials from other star ships.
It also allows players to build custom code or UI, easily packing it into the asset pack. If you want to use AntiSpaceRanger's Cool-Ass-Holographic-Ship-UI, just throw it in and it'll be included into the prefab, whether or not the next player down the line downloaded ASR's CAHS-UI on their own. Create your own UI, if you like.
But... this is not the limit. Not even vaguely.
See, since you're using Unity or Unreal, you can import new assets. A new Blender file. New sounds. New video clips. New textures. Let's focus on Blender.
Your starship can be any shape using the prefab starship components. You can scale them, tilt them, place them in any way you like. But there's no reason to limit yourself to those prefabs, especially when it comes to interiors or complex, smoothed hull shapes.
Why not take to Blender (or Maya or whatever)? Use the library file included with the modder package, and you can import those prefabs into a new Blender file, arrange them in Blender, scale them in Blender. Save it, and in Unity, a finished ship will pop up. A minimal amount of processing can match the Blender objects to their identically-named prefabs and swap them out in the ship prefab - essentially translating your Blender file into the exact same ship you would have gotten by dragging and dropping Unity prefabs.
Except...
You can add more things in Blender. A hull that is any shape and texture you please. New animations. Skeletons. Unity understands all these things, and we can process some of them into game logic - for example, our custom hull elements can be correctly classified and prepared for damage effects.
How far the modder wants to go is up to them. A new animation controller. A ship that flexes and ripples like an organic creature. A ship that grows or shrinks on command. There's a lot of possibilities, limited only by how well the game code copes with weird-but-valid Unity objects.
The ability to shape your own hull really can't be overstated. Passive elements such as rails, running lights, steps, windows, and simple smoothed hull elements are incredibly valuable to the average person. Voxel-based approaches give you some freedom, but there is absolutely nothing like being able to arrange them freely. That requires us to be able to distort and reshape them - something that is easy in Blender and extremely annoying in Unity.
A long, curving hand rail is easy in Blender. Import the hand rail object, stretch it, and curve it. Fit it to your ship perfectly. Unity imports it and it's in your ship! Bang!
More than that, assuming your naming convention is good, Unity understands that it is a hand rail, and will use IK to have nearby astronauts automatically slide their hands along it. That's super-easy, I've done adaptive animations like that a lot. You just need to have the object properly tagged!
(Making custom spaces feel real is incredibly important - I would pay special attention to making adaptive character animations, including things like turning sideways to move through tight areas or stepping easily to the side as you approach furniture.)
Pretty neat, right?! RIGHT!?! yeah.
...
Oh, right, I forgot the other half.
It's possible to make game assets viable to import into any similar game. SREG2000 assets could be imported into Shooty-VR-Game-Ultra. The only limit are class and library dependencies built into the asset package.
It is possible to minimize library and class dependencies by having the ship focus internally. While it's unlikely the same asset pack would load up in both SREG2000 and SVRGU, it would be relatively easy to import SREG2000 content into the SVRGU mod editor (both Unity projects), then winnow out the dependency errors and re-rig the ship for SVRGU use. The core - the meshes, materials, animations, etc - would be the same.
It is possible to create a database of, say, complex space ships. Not simply models: high-functioning ships that contain dozens of internal logic objects. For example, a class that opens and closes a hatch when triggered. A class that runs a specific trigger name on someone's mecanim animator if activated by them. A class that displays the state of that hatch. Because these classes are internal to the ship, there's no real chance of them colliding with game logic. Therefore, these classes can be packaged with the prefab, or packaged with the core idea of the mod editing system for both games.
Sounds interesting!
And, more importantly, sounds viable. Even if you remove all of the advanced features, simply allowing players to create new prefabs out of stock prefabs is incredibly powerful, especially if you can wire components together with references and events and delegates.
Wednesday, March 04, 2015
Best Laid Plans of Mice and Mods
I'm finally wading into the guts of the new modding system. Anyone who's made space for mods understands the tradeoffs: where do you leave space for modders? What is hardcoded, what is "softcoded" so modders can interject?
But this project is a bit different. It's intended to be open source, so nothing is truly hard-coded: the players can always edit the core code. Similarly, mods are created in the Unity project and exported from that space. It's not simply open source, it's a project where every modder is going to have the source code, even if they never really interact with it.
During this experiment, I've found myself developing in a strange way as a thought experiment. I've been trying to make absolutely every part of the gameplay a mod.
Some things are largely hardcoded. The way construction is handled, the way the basic menuing works, the light of the sun, the core existence of FacilityObjects and FacilityMOBs. In theory, these could be overridden, but they lay outside the modding infrastructure. A mod would need to aggressively intervene into the core systems in order to change those things. But... that's what most mods actually do in other games. The mod experiment has changed what I would consider "acceptable".
This morning I wrote electrical systems into the game. Power is a critical component of base management, so you can consider this a core feature. The vehicles you drive up in have solar panels attached to them, and can also generate electricity through their chemcell engines using some kind of liquid fuel. They have a specific amount of energy storage. These resources will last you some time, hopefully long enough to establish your base as an energy source instead of an energy sink. This is critical because it takes energy to build some things (for example, sintering sand requires energy, welding requires energy, etc). The more vehicles you build and take with you to your next location, the better off you'll be at the start.
There are a number of things the electrical system play requires. When you mouse over a car or a solar panel or whatever, the context popup needs to tell you how much energy is available/generated there. When you look at the facility overview, you need to know how much total energy is available, how much you're producing, how much you're using with standing facilities, how much you're using for construction or one-off activities. Moreover, it needs to continually update every time you build something new, do something new, toggle the behavior of an energy producing facility object, etc.
Sounds kinda... complicated and core, right? I mean, not complex in the grand scheme of things, but wired into a lot of the core game systems.
It's a mod.
Literally. "Core Electricity mod. Requires: Core Facility View mod. Priority 99"
A flip of a toggle, and the mod turns off. Nothing costs any energy. All the things that produce or consume energy stop caring about energy. Maybe some of them will stop being added to the list of available objects, when I care to bother dividing that stuff up.
Now, in a few small ways this is a cheat. Most of the core content is "integrated" with it, in terms of having an electrical cost to build. If you turn the mod off, that electrical cost stops mattering, but it's still part of the content. Similarly, most additional content later will probably also be integrated with the electrical mod. You can't really "not install" the mod, because it would involve not installing nearly every piece of content.
But you can "disable" the mod - all the content stays, but you are no longer limited by electricity and no longer receive reports about it.
All the reporting - the context popup, the facility overview, the build limitations - is part of the mod.
And this is how I've begun to think about my game systems.
Everything is core. Nothing is core. The systems are all stitched into the framework in the same way.
"Isn't that kind of a nightmare to develop?"
Well, I programmed the heart of the electrical systems before work this morning. In half an hour.
The key is the easy combination of ScriptableObject mod definition, the two GameObjects you specify as the overview menu item and the context menu item, and the UnityEvents that hook in automatically. It gives you an extremely easy "in" for hooking into the game world and running calculations.
"Isn't it painfully limited?"
Well, it's basically an API. The mod itself is fundamentally a way to interface with the game framework. But unlike a rigid mod API, this happens inside the Unity framework. In addition to the ease of integrating with UnityEvents and the inspector, you can use Unity's debugging capabilities and interact with the rest of the systems using actual code.
I've found that it produces extremely crisp results. Game systems tend to get complex and inter-related very fast and in very convoluted ways, at least when I program them. This keeps the systems so crisp you can actually turn them off.
This probably wouldn't work for every game. But in games which are largely statistical, this seems very powerful.
I'm sure I'll encounter drawbacks soon, because otherwise everyone would develop this way already. I'll keep everyone posted.
But this project is a bit different. It's intended to be open source, so nothing is truly hard-coded: the players can always edit the core code. Similarly, mods are created in the Unity project and exported from that space. It's not simply open source, it's a project where every modder is going to have the source code, even if they never really interact with it.
During this experiment, I've found myself developing in a strange way as a thought experiment. I've been trying to make absolutely every part of the gameplay a mod.
Some things are largely hardcoded. The way construction is handled, the way the basic menuing works, the light of the sun, the core existence of FacilityObjects and FacilityMOBs. In theory, these could be overridden, but they lay outside the modding infrastructure. A mod would need to aggressively intervene into the core systems in order to change those things. But... that's what most mods actually do in other games. The mod experiment has changed what I would consider "acceptable".
This morning I wrote electrical systems into the game. Power is a critical component of base management, so you can consider this a core feature. The vehicles you drive up in have solar panels attached to them, and can also generate electricity through their chemcell engines using some kind of liquid fuel. They have a specific amount of energy storage. These resources will last you some time, hopefully long enough to establish your base as an energy source instead of an energy sink. This is critical because it takes energy to build some things (for example, sintering sand requires energy, welding requires energy, etc). The more vehicles you build and take with you to your next location, the better off you'll be at the start.
There are a number of things the electrical system play requires. When you mouse over a car or a solar panel or whatever, the context popup needs to tell you how much energy is available/generated there. When you look at the facility overview, you need to know how much total energy is available, how much you're producing, how much you're using with standing facilities, how much you're using for construction or one-off activities. Moreover, it needs to continually update every time you build something new, do something new, toggle the behavior of an energy producing facility object, etc.
Sounds kinda... complicated and core, right? I mean, not complex in the grand scheme of things, but wired into a lot of the core game systems.
It's a mod.
Literally. "Core Electricity mod. Requires: Core Facility View mod. Priority 99"
A flip of a toggle, and the mod turns off. Nothing costs any energy. All the things that produce or consume energy stop caring about energy. Maybe some of them will stop being added to the list of available objects, when I care to bother dividing that stuff up.
Now, in a few small ways this is a cheat. Most of the core content is "integrated" with it, in terms of having an electrical cost to build. If you turn the mod off, that electrical cost stops mattering, but it's still part of the content. Similarly, most additional content later will probably also be integrated with the electrical mod. You can't really "not install" the mod, because it would involve not installing nearly every piece of content.
But you can "disable" the mod - all the content stays, but you are no longer limited by electricity and no longer receive reports about it.
All the reporting - the context popup, the facility overview, the build limitations - is part of the mod.
And this is how I've begun to think about my game systems.
Everything is core. Nothing is core. The systems are all stitched into the framework in the same way.
"Isn't that kind of a nightmare to develop?"
Well, I programmed the heart of the electrical systems before work this morning. In half an hour.
The key is the easy combination of ScriptableObject mod definition, the two GameObjects you specify as the overview menu item and the context menu item, and the UnityEvents that hook in automatically. It gives you an extremely easy "in" for hooking into the game world and running calculations.
"Isn't it painfully limited?"
Well, it's basically an API. The mod itself is fundamentally a way to interface with the game framework. But unlike a rigid mod API, this happens inside the Unity framework. In addition to the ease of integrating with UnityEvents and the inspector, you can use Unity's debugging capabilities and interact with the rest of the systems using actual code.
I've found that it produces extremely crisp results. Game systems tend to get complex and inter-related very fast and in very convoluted ways, at least when I program them. This keeps the systems so crisp you can actually turn them off.
This probably wouldn't work for every game. But in games which are largely statistical, this seems very powerful.
I'm sure I'll encounter drawbacks soon, because otherwise everyone would develop this way already. I'll keep everyone posted.
Monday, March 02, 2015
Mod Integration
So, it's one thing to talk about easily integrating mods into your game's content. But there is a more complex question: how do you integrate mods into the player experience?
Most mods simply add some content. No biggie. It shows up in the same lists as all the other content, the player experiences it the same way as any other content.
But many mods go further.
For example, in Kerbal there are mods which change how aerodynamics work. In Skyrim there are mods that change how you manage and use your NPC followers. In RimWorld there are mods which overhaul the nature of combat entirely.
In terms of code, all of these mods work. That is, they are coded and the code executes and the game simulation runs properly. But from a player perspective, these mods are clumsy and difficult to use. Even smaller mods such as adding in a new kind of stealth attack or a new kind of thermal simulation are often difficult for a player to understand, difficult to see running.
In Skyrim, this is solved via menus. Some of them are solved via conversation menus - talk to someone and you get a five-deep branching tree of options and possible commands. Others are solved via the mod menu mod, which lets mods put their parameters in a menu for tweaking. But neither of these options tells you how things work - it's just an interface for tweaking the mod. When you're done, the mod goes back to silently doing whatever it was doing.
In Kerbal it is also usually solved by a menu as well, but the menu is displayed right on the main game screen. The problem is that the menu is always in the way, and if you have eight mods, you have eight floating windows. There have been attempts to consolidate using a toolbar mod, but that has issues of its own.
In RimWorld mods really have no say in the interface at all, as far as I can tell. So all mods run silently, not even allowing for option tweaking.
I'm taking the opposite approach.
In my game, there are several spaces the player looks to find information.
One is the contextual popup. When you mouseover a tile or person, it reads out the details of what that is, whether it is navigable, whether it's friendly, what the temperature is, how much electricity it uses, etc. If you click on them, these contextual readouts become solid and interactable - perhaps giving out tooltips, perhaps becoming a button you can click to open a more powerful menu.
The key here is that a mod may, if it wishes, add a line to this context menu. In fact, the core features mentioned - electricity, nagivation, friendliness, etc - are all handled using the same methods as the mods use. So if you want to add a mod for sorted cabinet inventories, it's considered as "core" as the concept of electricity. You can even plant advanced functionality in your widget to draw on the game world for things like radius, heat mapping, etc.
This allows a player to see what the mod is "thinking" about the various objects in the game, and also provides an on-hand way to tweak the tweakable elements of the mod.
The other place a mod might want to talk to the player is in the facility overview tab. The electricity mod shows you total kWh available, total generated, total on-demand, etc. Friendliness might show you how many people of various factions are visiting. Etc. Moreover, these can be interactive. You can tweak things by clicking on the panel or, if there are too many options, you can even have a button which pops up a full-screen menu.
I'm not overselling this: Unity's core functionality is available, and both the context widget and the overview widget are simply considered GameObjects and spawned into the scene. There are a bunch of default hooks - onMenuOpen, onMenuClosed, etc - but you can also add in UI buttons and widgets of your own choosing and code them to do anything you want.
Not all mods need this. A mod that adds a new gun or a new person doesn't need a menu item. The basic mod management screen is plenty for that kind of mod - just allow the player to turn it on and off, no need for ongoing management as you play.
But I want players to build overhaul mods. I want players to turn off my shitty core electricity mod and replace it with their custom mod that does things better. I want players to create a mod to make the NPCs behave very differently, with a variety of context commands and AI cues. I'm happy if a player adds a new gun, but I want them to feel the urge to change the game as well.
That's what I'm working on these days.
Most mods simply add some content. No biggie. It shows up in the same lists as all the other content, the player experiences it the same way as any other content.
But many mods go further.
For example, in Kerbal there are mods which change how aerodynamics work. In Skyrim there are mods that change how you manage and use your NPC followers. In RimWorld there are mods which overhaul the nature of combat entirely.
In terms of code, all of these mods work. That is, they are coded and the code executes and the game simulation runs properly. But from a player perspective, these mods are clumsy and difficult to use. Even smaller mods such as adding in a new kind of stealth attack or a new kind of thermal simulation are often difficult for a player to understand, difficult to see running.
In Skyrim, this is solved via menus. Some of them are solved via conversation menus - talk to someone and you get a five-deep branching tree of options and possible commands. Others are solved via the mod menu mod, which lets mods put their parameters in a menu for tweaking. But neither of these options tells you how things work - it's just an interface for tweaking the mod. When you're done, the mod goes back to silently doing whatever it was doing.
In Kerbal it is also usually solved by a menu as well, but the menu is displayed right on the main game screen. The problem is that the menu is always in the way, and if you have eight mods, you have eight floating windows. There have been attempts to consolidate using a toolbar mod, but that has issues of its own.
In RimWorld mods really have no say in the interface at all, as far as I can tell. So all mods run silently, not even allowing for option tweaking.
I'm taking the opposite approach.
In my game, there are several spaces the player looks to find information.
One is the contextual popup. When you mouseover a tile or person, it reads out the details of what that is, whether it is navigable, whether it's friendly, what the temperature is, how much electricity it uses, etc. If you click on them, these contextual readouts become solid and interactable - perhaps giving out tooltips, perhaps becoming a button you can click to open a more powerful menu.
The key here is that a mod may, if it wishes, add a line to this context menu. In fact, the core features mentioned - electricity, nagivation, friendliness, etc - are all handled using the same methods as the mods use. So if you want to add a mod for sorted cabinet inventories, it's considered as "core" as the concept of electricity. You can even plant advanced functionality in your widget to draw on the game world for things like radius, heat mapping, etc.
This allows a player to see what the mod is "thinking" about the various objects in the game, and also provides an on-hand way to tweak the tweakable elements of the mod.
The other place a mod might want to talk to the player is in the facility overview tab. The electricity mod shows you total kWh available, total generated, total on-demand, etc. Friendliness might show you how many people of various factions are visiting. Etc. Moreover, these can be interactive. You can tweak things by clicking on the panel or, if there are too many options, you can even have a button which pops up a full-screen menu.
I'm not overselling this: Unity's core functionality is available, and both the context widget and the overview widget are simply considered GameObjects and spawned into the scene. There are a bunch of default hooks - onMenuOpen, onMenuClosed, etc - but you can also add in UI buttons and widgets of your own choosing and code them to do anything you want.
Not all mods need this. A mod that adds a new gun or a new person doesn't need a menu item. The basic mod management screen is plenty for that kind of mod - just allow the player to turn it on and off, no need for ongoing management as you play.
But I want players to build overhaul mods. I want players to turn off my shitty core electricity mod and replace it with their custom mod that does things better. I want players to create a mod to make the NPCs behave very differently, with a variety of context commands and AI cues. I'm happy if a player adds a new gun, but I want them to feel the urge to change the game as well.
That's what I'm working on these days.
Monday, August 11, 2014
These are a few of my favorite things (to mod in)
Last year, my gaming preferences underwent a massive shift. Whatever the reason, it's nearly impossible for me to get excited about games these days. It doesn't matter the genre, the target audience, the technical specs - nothing interests me.
For a while, the only two games I would play at all were Skyrim and Kerbal. Now I find myself suddenly playing Space Engineers, even though I had tried it and stopped in boredom. Why did I want to play it again?
Mods. They just introduced mod support.
Ugh, it's kind of obvious in retrospect. Skyrim and Kerbal both have massive levels of mod support and swarms of mods. Space Engineers has started to join in the fray with a truly amazing mod management system, although the mods themselves are still primitive due to lack of scripting support.
So the first thing I did was download a bevy of mods to make me think harder. A ventilation mod, a wiring mod, and interior walls mod... none of them do anything, technically-speaking, but they let me build more complex, immersive stations. And I'm really enjoying it.
...
Why do I only like mods?
I think it boils down to authorship.
Games have a specific team or a specific person creating them. In some cases that authorship is really effective, such as in Papers, Please or Gone Home. But nearly all of the time, the game isn't an attempt to say something meaningful. It's just an attempt to build a cool game.
But I'm not impressed by cool games any more.
When I can twist and reshape a game as I see fit, the game becomes much more interesting to me. When I can take the twists and reshapings of other players, that's when the game really takes off.
Simple logic: if your game allows mods, it has hundreds or thousands of developers. I can pick and choose which ones I want to hear from, which ones seem to have the most interesting ideas. I can include their thoughts into my game at any level. If the system is particularly agile, I can put down my thoughts and then hear their responses.
This is not the same as playing together with people. I have no interest in massively multiplayer games, because those aren't about taking the works of those other players into my own game. We're all stuck in the same game that plays the same way - we're in a place together, instead of building a new place as we like.
On the other end of things, this isn't a sketch jam. Each of these games has a strong underlying scaffold we build on. A mod for Kerbal doesn't make any sense for Skyrim, and visa-versa. Even putting aside technical differences, the concept of the mods doesn't make any sense in the other game. The shared scaffold guides our discussion... but it also makes our discussions compatible.
See, the real strength of a moddable game is not any one mod. It's combining several compatible mods into an interesting result that is flavored just how you want it. I combine Universal Storage, Karbonite, and Spaceplane 1.3 - and all the sudden I have a space program none of them could have accomplished on their own.
Even just aesthetically, in Space Engineers I have a wiring mod, a ventilation mod, a grated-floor mod, and an interior walls mod. The four work together superbly, while each alone is visually incompatible with vanilla.
Because we are all "talking 'space station'", we each have our own ideas as to what space stations need. Combine the best and you get a very dense, deep discussion on the topic of space stations. In the form of digital LEGO bricks.
This is the secret of moddable games.
I have grown tired of what devs think. That's not their fault, but it does mean I have zero interest in their game. It's like listening to someone explain their dream: some people have amazingly interesting dreams, but 99% of people do not.
You will have more than 100 players. At least one of them will have an interesting take on your dream.
For a while, the only two games I would play at all were Skyrim and Kerbal. Now I find myself suddenly playing Space Engineers, even though I had tried it and stopped in boredom. Why did I want to play it again?
Mods. They just introduced mod support.
Ugh, it's kind of obvious in retrospect. Skyrim and Kerbal both have massive levels of mod support and swarms of mods. Space Engineers has started to join in the fray with a truly amazing mod management system, although the mods themselves are still primitive due to lack of scripting support.
So the first thing I did was download a bevy of mods to make me think harder. A ventilation mod, a wiring mod, and interior walls mod... none of them do anything, technically-speaking, but they let me build more complex, immersive stations. And I'm really enjoying it.
...
Why do I only like mods?
I think it boils down to authorship.
Games have a specific team or a specific person creating them. In some cases that authorship is really effective, such as in Papers, Please or Gone Home. But nearly all of the time, the game isn't an attempt to say something meaningful. It's just an attempt to build a cool game.
But I'm not impressed by cool games any more.
When I can twist and reshape a game as I see fit, the game becomes much more interesting to me. When I can take the twists and reshapings of other players, that's when the game really takes off.
Simple logic: if your game allows mods, it has hundreds or thousands of developers. I can pick and choose which ones I want to hear from, which ones seem to have the most interesting ideas. I can include their thoughts into my game at any level. If the system is particularly agile, I can put down my thoughts and then hear their responses.
This is not the same as playing together with people. I have no interest in massively multiplayer games, because those aren't about taking the works of those other players into my own game. We're all stuck in the same game that plays the same way - we're in a place together, instead of building a new place as we like.
On the other end of things, this isn't a sketch jam. Each of these games has a strong underlying scaffold we build on. A mod for Kerbal doesn't make any sense for Skyrim, and visa-versa. Even putting aside technical differences, the concept of the mods doesn't make any sense in the other game. The shared scaffold guides our discussion... but it also makes our discussions compatible.
See, the real strength of a moddable game is not any one mod. It's combining several compatible mods into an interesting result that is flavored just how you want it. I combine Universal Storage, Karbonite, and Spaceplane 1.3 - and all the sudden I have a space program none of them could have accomplished on their own.
Even just aesthetically, in Space Engineers I have a wiring mod, a ventilation mod, a grated-floor mod, and an interior walls mod. The four work together superbly, while each alone is visually incompatible with vanilla.
Because we are all "talking 'space station'", we each have our own ideas as to what space stations need. Combine the best and you get a very dense, deep discussion on the topic of space stations. In the form of digital LEGO bricks.
This is the secret of moddable games.
I have grown tired of what devs think. That's not their fault, but it does mean I have zero interest in their game. It's like listening to someone explain their dream: some people have amazingly interesting dreams, but 99% of people do not.
You will have more than 100 players. At least one of them will have an interesting take on your dream.
Tuesday, June 10, 2014
The Moddable Game
Since I first played my first computer game on the Apple II, I've always wanted to tweak what I'm playing. I am in favor of tweaking to the point where every game I've ever made was about letting the players tweak the game.
So it's an understatement to say that I'm in favor of mods.
I'd like to talk about what makes a game moddable.
First off, there's the engine's capacity to be modded. Some games are built to import mods freely, like Kerbal and Skyrim. Others can be forced into it, like World of Warcraft. Others are nearly impossible to mod, either due to technical constraints or anti-mod policing.
Next there is the popularity of the game. The more popular a game is, the more people will want to mod it. There are some super mod-friendly indie games out there that nobody has really heard of, and in turn they have few mods. Skyrim isn't actually hugely mod-friendly on its own, but it was so popular that the mod community built tools to MAKE it mod-friendly.
Lastly, there's also the fundamental design of the game.
I was thinking about this the other day. I was wishing for a version of Mass Effect that had a mod library as large as the one for Skyrim.
To make it clear, I've got 50+ mods for Skyrim downloaded, around 2 dozen installed, and there are hundreds more that I never bothered with. This is about the same numbers as Kerbal, although recently Kerbal's modding community has been gutted. In both cases, there are mod managers which make installing and uninstalling mods as simple as a double-click. And the mods are often very deep, such as changing out the entire animation system, or making combat work completely differently... or adding 30+ fully voiced new NPCs, or 100+ new locations.
The Mass Effect games do have some mods, but nowhere near that volume or depth. Mostly they're about making Mass Effect look better, or tweaking costumes. As far as I know, there are no mods to completely change the combat system, or let you play as a new species, or replace the Normandy with a Spanish galleon.
This is a shame. I really am looking for a moddable personal science fiction game.
There are loads of moddable impersonal scifi games, starting with Kerbal. But I want the close-in RPG experience, where you live in a world and you can mod the things that are in that world. Mass Effect is one of the few that seems like it'd qualify.
Why aren't Mass Effect games very moddable? Well, partly it's due to the technical and cultural constraints. But I think a bigger part of it is the fundamental design of the game. Mass Effect's basic design has two major flaws that make it difficult to mod.
The first is that the statistical and character growth side of things are too basic. A lot of mods in other games make extensive use of "peripheral" skill sets, but Mass Effect is laser-focused on pitched combat and solely pitched combat. Everything else isn't simply mediocre, it's missing entirely. Nobody feels annoyed by the mediocre crafting system in Mass Effect because there isn't one. Nobody is annoyed by the stealth system because there isn't one. Gameplay-wise, Mass Effect is very small and tight, which makes it hard to mod.
In addition, the world is also designed a bit annoyingly.
In theory, a sci fi game should be dirt-easy to add new content into. You can just stick a whole new planet in, it'll just appear on the star map easy as you please. No scuffling needed.
Unfortunately, Mass Effect isn't a game where you can freely wander the universe. It just feels that way because of the atmosphere.
Mass Effect feels very open and immersive, but it isn't. You are on rails the whole time, it just lets you take a few of the stops in a different order if you like. The world is very tightly designed so that nothing really distracts you from your quest - occasional sidequests have the exact same gameplay and do not affect how you approach later missions in the slightest.
Skyrim, on the other hand, lets you pretty much do whatever you want once you get past the epic(ally self-indulgent) opening sequence. You can pick flowers, hunt bears, map out lost ruins, raid dungeons, learn magic, craft weapons, enchant things, learn alchemy, go to college, find companions, buy a house, raise a family... the main quest will wait patiently.
A huge part of this is that Skyrim is full of STUFF.
I don't mean locations, although that's part of it. I mean STUFF. Every inch of Skyrim is crawling with pointlessness. Outside, there are harvestable plants, interesting gullies, ruins to track down, lakes to swim in, overlooks to look over... and inside, there are not only people (and children!) but also plates, apples, beds, cooking pots, complex dinners, crops, books, lamps, shops with stuff all over them - all interactive.
Contrast this to Mass Effect. Shepard has no interest in day-to-day life. She is physically incapable of showing any interest towards day-to-day life, because she literally cannot interact with day-to-day things. Every book and plate is part of the background, nobody ever eats. There are few things to interact with, and they are universally either text tidbits or guns. There are beautiful places to go, but Shepard cannot enjoy them: she physically cannot jump in the water or pluck a flower.
The Normandy makes this even worse. The Normandy is incapable of enjoying itself as you travel. Shepard can at least find a beautiful spot and gaze at it, or chat with a random NPC. But the Normandy glides through empty space without any variation or life.
What can a modder do to spruce up these experiences? A modder could create new locations, but they would be just as hollow. As with all locations in Mass Effect, they would exist solely as either combat zones or exposition zones. Shepard will always be a military captain with no other life. She physically cannot be a trader, a thief, a cook.
Hence, no mods.
Well, few mods.
I'm looking for that category of sci fi game - the close third- or first-person space RPG - that is as moddable as Skyrim. I would buy extra copies.
So it's an understatement to say that I'm in favor of mods.
I'd like to talk about what makes a game moddable.
First off, there's the engine's capacity to be modded. Some games are built to import mods freely, like Kerbal and Skyrim. Others can be forced into it, like World of Warcraft. Others are nearly impossible to mod, either due to technical constraints or anti-mod policing.
Next there is the popularity of the game. The more popular a game is, the more people will want to mod it. There are some super mod-friendly indie games out there that nobody has really heard of, and in turn they have few mods. Skyrim isn't actually hugely mod-friendly on its own, but it was so popular that the mod community built tools to MAKE it mod-friendly.
Lastly, there's also the fundamental design of the game.
I was thinking about this the other day. I was wishing for a version of Mass Effect that had a mod library as large as the one for Skyrim.
To make it clear, I've got 50+ mods for Skyrim downloaded, around 2 dozen installed, and there are hundreds more that I never bothered with. This is about the same numbers as Kerbal, although recently Kerbal's modding community has been gutted. In both cases, there are mod managers which make installing and uninstalling mods as simple as a double-click. And the mods are often very deep, such as changing out the entire animation system, or making combat work completely differently... or adding 30+ fully voiced new NPCs, or 100+ new locations.
The Mass Effect games do have some mods, but nowhere near that volume or depth. Mostly they're about making Mass Effect look better, or tweaking costumes. As far as I know, there are no mods to completely change the combat system, or let you play as a new species, or replace the Normandy with a Spanish galleon.
This is a shame. I really am looking for a moddable personal science fiction game.
There are loads of moddable impersonal scifi games, starting with Kerbal. But I want the close-in RPG experience, where you live in a world and you can mod the things that are in that world. Mass Effect is one of the few that seems like it'd qualify.
Why aren't Mass Effect games very moddable? Well, partly it's due to the technical and cultural constraints. But I think a bigger part of it is the fundamental design of the game. Mass Effect's basic design has two major flaws that make it difficult to mod.
The first is that the statistical and character growth side of things are too basic. A lot of mods in other games make extensive use of "peripheral" skill sets, but Mass Effect is laser-focused on pitched combat and solely pitched combat. Everything else isn't simply mediocre, it's missing entirely. Nobody feels annoyed by the mediocre crafting system in Mass Effect because there isn't one. Nobody is annoyed by the stealth system because there isn't one. Gameplay-wise, Mass Effect is very small and tight, which makes it hard to mod.
In addition, the world is also designed a bit annoyingly.
In theory, a sci fi game should be dirt-easy to add new content into. You can just stick a whole new planet in, it'll just appear on the star map easy as you please. No scuffling needed.
Unfortunately, Mass Effect isn't a game where you can freely wander the universe. It just feels that way because of the atmosphere.
Mass Effect feels very open and immersive, but it isn't. You are on rails the whole time, it just lets you take a few of the stops in a different order if you like. The world is very tightly designed so that nothing really distracts you from your quest - occasional sidequests have the exact same gameplay and do not affect how you approach later missions in the slightest.
Skyrim, on the other hand, lets you pretty much do whatever you want once you get past the epic(ally self-indulgent) opening sequence. You can pick flowers, hunt bears, map out lost ruins, raid dungeons, learn magic, craft weapons, enchant things, learn alchemy, go to college, find companions, buy a house, raise a family... the main quest will wait patiently.
A huge part of this is that Skyrim is full of STUFF.
I don't mean locations, although that's part of it. I mean STUFF. Every inch of Skyrim is crawling with pointlessness. Outside, there are harvestable plants, interesting gullies, ruins to track down, lakes to swim in, overlooks to look over... and inside, there are not only people (and children!) but also plates, apples, beds, cooking pots, complex dinners, crops, books, lamps, shops with stuff all over them - all interactive.
Contrast this to Mass Effect. Shepard has no interest in day-to-day life. She is physically incapable of showing any interest towards day-to-day life, because she literally cannot interact with day-to-day things. Every book and plate is part of the background, nobody ever eats. There are few things to interact with, and they are universally either text tidbits or guns. There are beautiful places to go, but Shepard cannot enjoy them: she physically cannot jump in the water or pluck a flower.
The Normandy makes this even worse. The Normandy is incapable of enjoying itself as you travel. Shepard can at least find a beautiful spot and gaze at it, or chat with a random NPC. But the Normandy glides through empty space without any variation or life.
What can a modder do to spruce up these experiences? A modder could create new locations, but they would be just as hollow. As with all locations in Mass Effect, they would exist solely as either combat zones or exposition zones. Shepard will always be a military captain with no other life. She physically cannot be a trader, a thief, a cook.
Hence, no mods.
Well, few mods.
I'm looking for that category of sci fi game - the close third- or first-person space RPG - that is as moddable as Skyrim. I would buy extra copies.
Subscribe to:
Posts (Atom)