next »

[eigenbom]

This looks like a very powerful and adaptable system! I wonder if it could be made to parse external files for modding purposes.

Yeah you certainly could. One of the major decisions I made early on was to not directly support modding --- so I could focus just on the game itself. But after seeing things like DFHack and Minecraft modding, I realised that people figure out a way to mod the game even if it doesn't directly support it.

[bacon]

This looks like a very powerful and adaptable system! I wonder if it could be made to parse external files for modding purposes.

Yeah you certainly could. One of the major decisions I made early on was to not directly support modding --- so I could focus just on the game itself. But after seeing things like DFHack and Minecraft modding, I realised that people figure out a way to mod the game even if it doesn't directly support it.

That's actually kind of surprising - what made you not want to open it up to modding from the get go?

[cow_trix]

This looks like a very powerful and adaptable system! I wonder if it could be made to parse external files for modding purposes.

Yeah you certainly could. One of the major decisions I made early on was to not directly support modding --- so I could focus just on the game itself. But after seeing things like DFHack and Minecraft modding, I realised that people figure out a way to mod the game even if it doesn't directly support it.

That's actually kind of surprising - what made you not want to open it up to modding from the get go?

As someone currently working from the other end of the spectrum - opening Hurtworld up to modding luturally uvurythung - I totally get this. It's a lot less work when your tools only have to work for you!

[kamac]

Friendly reminder that this game has been under development for nearly exactly 5 years now. I kinda grew up with it.

Nice  

Brings a tear to my eye.

[bacon]

This looks like a very powerful and adaptable system! I wonder if it could be made to parse external files for modding purposes.

Yeah you certainly could. One of the major decisions I made early on was to not directly support modding --- so I could focus just on the game itself. But after seeing things like DFHack and Minecraft modding, I realised that people figure out a way to mod the game even if it doesn't directly support it.

That's actually kind of surprising - what made you not want to open it up to modding from the get go?

As someone currently working from the other end of the spectrum - opening Hurtworld up to modding luturally uvurythung - I totally get this. It's a lot less work when your tools only have to work for you!

Haha I totally hear that. I'm making my game moddable from the start and having to dive into like, System.Reflection instead of getting to actually program gameplay sucks, but it's also nice knowing that I'm opening it up to make it super easy for people to mod if they want to.

But I'm actually stoked you're here because I was looking into Oxide - do you provide the API for this stuff or is that all done by the community? And does the support there exist only because of you? Also if you have any hot tips for designing Unity games for modding LET ME KNOW. Feel like I'm pulling together strings.

[eigenbom]

That's actually kind of surprising - what made you not want to open it up to modding from the get go?

Originally had modding support planned, if you go back to the first 20 pages or so I started to build a basic Lua API. Ultimately it would have been a lot more work -- now every feature of your game needs twice as much work: the main engine implementation and the modding hooks/testing/etc. (The same goes for online multiplayer, you basically double the amount of work for each feature.)

One big reason was that other games, such as Crea, were heavily supporting modding (which has been a double-edged sword for the dev), and because I was trying to find my own niche I decided to make it single-player, non-moddable, and non-sandboxy.

As someone currently working from the other end of the spectrum - opening Hurtworld up to modding luturally uvurythung - I totally get this. It's a lot less work when your tools only have to work for you!

Yeah man, it all depends on what your game is. For me, if the core game wasn't fun then supporting modding would be all pointless work. For games like Garry's Mod they (literally) are fun because they support modding.

Two things I learnt from various sources from when I started this game:

1. strongly supporting modding through a scripting engine is just a whole tonne of work, from making the API, running the actual interpreter, and debugging community scripts.

2. if people love your game then they will find a way to mod it.

Friendly reminder that this game has been under development for nearly exactly 5 years now. I kinda grew up with it.

Brings a tear to my eye.

Aww you're OG moonman. Thanks for being part of this thread, I love TIGs. I hope to release before 1000000 views.

Haha I totally hear that. I'm making my game moddable from the start and having to dive into like, System.Reflection instead of getting to actually program gameplay sucks, but it's also nice knowing that I'm opening it up to make it super easy for people to mod if they want to.

I don't know what your game entails, but in general I'd recommend against adding modding support. Just make a really fun focused game, and then, if you survive, you can tackle something more engineered. It's a big gamble to do all that work so people 'can mod if they want to', especially if, as you say, the gameplay and all other bits are going to suffer from lack of attention.

[cow_trix]

This looks like a very powerful and adaptable system! I wonder if it could be made to parse external files for modding purposes.

Yeah you certainly could. One of the major decisions I made early on was to not directly support modding --- so I could focus just on the game itself. But after seeing things like DFHack and Minecraft modding, I realised that people figure out a way to mod the game even if it doesn't directly support it.

That's actually kind of surprising - what made you not want to open it up to modding from the get go?

As someone currently working from the other end of the spectrum - opening Hurtworld up to modding luturally uvurythung - I totally get this. It's a lot less work when your tools only have to work for you!

Haha I totally hear that. I'm making my game moddable from the start and having to dive into like, System.Reflection instead of getting to actually program gameplay sucks, but it's also nice knowing that I'm opening it up to make it super easy for people to mod if they want to.

But I'm actually stoked you're here because I was looking into Oxide - do you provide the API for this stuff or is that all done by the community? And does the support there exist only because of you? Also if you have any hot tips for designing Unity games for modding LET ME KNOW. Feel like I'm pulling together strings.

Oxide is completely community driven and completely awesome. Sometimes they ask for small changes in code to make injecting their hooks easier but apart from that they do their own thing.

For designing moddable Unity games: make everything modular AssetBundles. Consider that all you need for things to serialize across AssetBundles is the same class name and field names, so you don't have to distribute source code for people to be able to create Monobehaviours and ScriptableObjects that your game can understand. There's a whole article to write about it one day, I can go into more detail over PM.

Sorry for hijacking the thread eigenbom!

[eigenbom]

> Sorry for hijacking the thread eigenbom!

No worries, interesting to hear about this stuff. I just read up on Oxide, looks pretty cool

[eigenbom]

Update: Super busy week and weekend, only finishing up now - late on a Sunday evening. Work was mainly refactoring all the world generators to be compatible with the new game planner code. I've modified at least 10,000 lines of code this week, which gives you an idea of the scale. It's very tedious: adapting old code to use new code, changing locations of structs, etc.

All this work is so that I can specify game properties at the level of the Planner. Here's some code for the Planner on the left ... all it's doing is saying it wants a Skeleton and Furnace at a certain location in a level. The generator then takes this info and figures out exactly where to place those things. The generator is then also free to add extra enemies and objects. This frees the Planner up to focus on just important game-wide elements.



In addition to the NPCs, some other game-wide elements include World Objects (like the furnace above), Features (which include simple things like spawn points to more complex structures like Houses), and Internal Doors (which connect up the different regions).

Related to this refactor I've moved all the crafting recipes into a huge spreadsheet. They were split amongst several files before, so it's great to have them all centralised. Each entry is basically a series of [RECIPE LIST, VERB, ITEM, INGREDIENTS] rows.

I decided to generalise the concept of CRAFTER to that of a RECIPE LIST. In the game I can now give a recipe list to an NPC or a world object, and it gains the ability to craft items from that list. Typically a World Object will correspond to just one recipe list (e.g., a Toolbox will always have the Toolbox recipe list (below)). But more generally, it means we can customise other crafters. E.g., for Boney's Furnace above, we could attach a different recipe list to give it a customised set of items. Likewise for NPCs, I could design a set of different recipe lists for merchants and then assign one randomly and/or dynamically.



See you next week!

[bacon]

This looks like a very powerful and adaptable system! I wonder if it could be made to parse external files for modding purposes.

Yeah you certainly could. One of the major decisions I made early on was to not directly support modding --- so I could focus just on the game itself. But after seeing things like DFHack and Minecraft modding, I realised that people figure out a way to mod the game even if it doesn't directly support it.

That's actually kind of surprising - what made you not want to open it up to modding from the get go?

As someone currently working from the other end of the spectrum - opening Hurtworld up to modding luturally uvurythung - I totally get this. It's a lot less work when your tools only have to work for you!

Haha I totally hear that. I'm making my game moddable from the start and having to dive into like, System.Reflection instead of getting to actually program gameplay sucks, but it's also nice knowing that I'm opening it up to make it super easy for people to mod if they want to.

But I'm actually stoked you're here because I was looking into Oxide - do you provide the API for this stuff or is that all done by the community? And does the support there exist only because of you? Also if you have any hot tips for designing Unity games for modding LET ME KNOW. Feel like I'm pulling together strings.

Oxide is completely community driven and completely awesome. Sometimes they ask for small changes in code to make injecting their hooks easier but apart from that they do their own thing.

For designing moddable Unity games: make everything modular AssetBundles. Consider that all you need for things to serialize across AssetBundles is the same class name and field names, so you don't have to distribute source code for people to be able to create Monobehaviours and ScriptableObjects that your game can understand. There's a whole article to write about it one day, I can go into more detail over PM.

Sorry for hijacking the thread eigenbom!

Sent you a message — eager to discuss this more with you! And thanks for allowing a diversion eigenbom!

To go back on topic — how do you plan to use the planner? Is it a script backend for what you do in an editor or is it the main way you "design" the game?

[eigenbom]

> To go back on topic — how do you plan to use the planner? Is it a script backend for what you do in an editor or is it the main way you "design" the game?

The planner is a separate module in the system that is responsible for creating a game -- from deciding what the areas contain and how they are connected to deciding the types of enemies and NPCs. The first release will have a simple planner but I hope to greatly expand it so that each game feels different.

[eigenbom]

Update: Continuing on the Planner code, I've shifted more things up a level. Things like the Stone Cove, Ruins, Hive, etc., can all be specified by the planner. So theoretically you could make a forest with many ruins or none, lots of hives or just one, and eventually I'll add more control over the placement of these.

I also put the Planner into action, and the game now can now generate a full set of connected areas. You can walk from Solomon's house, go through the tunnel, come out into the forest, then up to the surface to a sign post, across a small transition area to the mountain, then into a tomb via a door (for instance). The Planner has a lot of flexibility with how it connects all these areas up, and I look forward to trying out different global layouts. For example, I can imagine finding a ruins in the forest, walking through it, coming out in a hidden room in the cathedral, then surfacing up in the volcano level.

Although all this may sound abstract, I'm using it to make big strides in the actual development. The planner can now add pre-built little areas (hidden around the forest and other areas) and specify the contents of containers. For instance, it might want to add a special set of armour in this little area:



Other attributes, like whether an area is snowing, or what theme it has, are also specified at the planner level. Each region will have a few themes which primarily affect what it looks like. Here's the default theme for the forest and a 'dusk' theme. In this case the theme changes some of the plants and the distribution of basic blocks. Other attributes, like terrain_type, will be used to modify the actual structure of the areas.

[jctwood]

Beautiful as ever. Really interesting to hear about the planner system I can imagine it would be useful in any kind of procedural level.

[eigenbom]

Beautiful as ever. Really interesting to hear about the planner system I can imagine it would be useful in any kind of procedural level.

Thanks! Yeah I'm already considering my next game which will really push this whole idea much further. Moonman is like a big pile of stuff with some basic game planning, but my next game will be all about the planner and less about lots of stuff. But there's another year or two before I even start it.

Update: Well it's my last week of work this year then I'm off until the 9th of Jan. It's been a very busy year, thanks for hanging out in this devlog and keeping up with the progress of the project! Your support means a lot to both Alex and I, and we're both very excited about the final sprint next year leading up to the Beta release in March.

This week was a short one and was mostly just a big tidy up before the break. We've organised the Trello, and tried to narrow it down to the minimum tasks required for the Beta. In addition to that I've decided on a company name (TBA) to release the game under, and have written a EULA and other related boring documents.

Actual programming was a minimum, but I did finally implement alternative skins in the character select. A few characters have alternative skins, some of which are there at the start and some which will be hidden. To start there will be the 4 main characters (moonman, elemental, human male, human female) and the humans each have 3 different skin tones. Other character skins, like Moomman, will probably be unlockable through game actions, in a similar way to the unlockable characters. The alternative skins are just selected by pushing up or down in the character select screen.



This is my last post for 2016, thanks again for all your helpful comments this year. Have a safe holiday break!

[eigenbom]

Update: Welcome to the devlog for 2017!

A local sound guy named Andrew is now making some of the effects for the beta. While he's been composing I've been adding hooks for most of the sound effects and cleaning up old sfx code. I've also been adding more sound features, like an underwater sound mode which lowers the pitch of all sound effects while playing a looping underwater ambience. There are around 100 or so basic sounds, which are played with different pitches, etc., sometimes in loops, sometimes alongside another sound, and so on. The final game will have about twice that, but for the beta we're just doing the core sounds. Here's part of the spreadsheet we're using to coordinate and organise the sfx.



I then have a super simple system where you just say play(SFX_BOINK) or whatever, choosing from a big list of enumerated sounds. I decided to hard code all these in because I need to get this done quickly and move on to the next task.



I also added a SFX menu to my devmode in the game which lets me play sounds (with an optional position) in the game and search through them etc, in the same way that I can search the objects, items, blocks, etc.



Alex is back at work too! He's been working on the title and promotional images, and has also been experimenting with some designs for the website, and itch.io page, and so on. I'm super exhausted so it's a short devlog today.

[Mixer]

Awesome work Ben. Always love seeing the updates even if I don't post much. Keep up the awesome work :D

[eigenbom]

Cheers mate!

[eigenbom]

Update: Moved onto the game planner this week and I've made some decent progress with designing how the whole thing might work. I've coded up a rough prototype in Python (about 1000 lines) to pry apart the model and see if there are any major issues with it. It roughly works as follows:

Choose regions, layouts, and basic features
These create various hard and soft constraints (e.g., a Rock Wall requires SMASH 1 tool)
Trace the network of regions from the start, if you encounter a constraint:
  Search through all mechanisms and implement one (this may require a chain of mechanisms)

A mechanism in this model is a building block of the game and will include a number of elements. For example there might be a basic smashy mechanism that includes: trees, sharpstone, grindstone, and workbench. Implementing the mechanism is a matter of ensuring all elements (e.g., a group of trees) appear in the game, somewhere before the mechanism is required. By designing a whole bunch of mechanisms and chaining them together I hope to have a flexible system for generating different kinds of areas and experiences. There are a lot of little questions which have arisen through the prototyping, and for now I'm mostly choosing the simplest answers. The thing that interests me the most about this method is that it can be improved over time, by decomposing mechanisms into smaller pieces, and adding more rules about how mechanisms interact or are chosen.

Here's a little snap shot of a network my prototype was operating on. The features like "stone slug" and "iron ore" are selected by the planner, as a result of reacting to the "Clay Seam" constraint that requires DIG 2 to get through. This first pass, over the hard constraints, ensures that the player will always have the available materials they need. Further passes satisfy soft constraints, independently random elements, and so on.



Finally, here's the system operating on a quest for an imaginary game that isn't moonman. As the system steps through the nodes, it encounters a constraint called [letter], indicating that the player needs a letter to get through the city walls. A mechanism called mayor has [letter] as it's output, and implementing it places the mayor feature in a suitable location. This is a very high-level of abstraction, where the planner only sees flavourless concepts like letter, miner, etc. In this imaginary game, the low-level system would need to understand these concepts at the gameplay level, by e.g., actually implementing a guard that stops the player and adding a mayor npc that gives the player a letter of passage. The constraints in Moonman will be simpler and more resource and combat-focussed than this example, but it's interesting to see the flexibility of the approach.

[Smerik]

First time poster here, but have been lurking for a long time. Awesome stuff.



This looks really interesting. And its a clever way of going back and forth, is there a possibility of unsolvable layouts? And how do you prevent these? You probably know these already, but i still find these videos pretty interesting. They are called Boss Keys and done by Mark Brown, really good breakdown of zelda dungeons that could inspire you.

[eigenbom]

Hey thanks, it's on my watchlist! Yeah for the general problem you'd have to be careful about the order in which the world is laid out, and if you want ultimate freedom then you could use a proper constraint solver to ensure that it all works properly. For Moonman I'm using a very simplified version of this idea, but I'm interested in the general implementation too (possibly for a future game).