- In preparation for this year’s birthday event, and to pave the way for Foraging, there’s a shiny, brand new web app interface now available in beta!
- To celebrate our technical upgrade, a new limited edition unbonded creature, Circuit coated Eletrixx, is available for a short time! They come in three coat variations with differing levels of rarity!
Krafties is getting a facelift!
A
brand new spin on our web app system is here! When opening up the App Selection url in your browser you’ll see a new option labeled “Try our new beta web app experience”. Clicking the option will reroute your browser to our brand new, redesigned web app. Things will look familiar, but everything should be cleaner, more convenient, and now use all available screen space! We’re working to minimize the number of actions players have to take to accomplish what they’re setting out to do, keep everything in one place, and make it easier for new players to see the full feature set of what our app system has to offer!
Now, you might be wondering why this area of the game was tackled in particular. As nice as we hope the new system is for you players, it’s equally as nice for the development side of Krafties! This new system is using modern web technologies, which (when fully implemented) makes the development of new features much faster, cleaner, and more reliable for Krafties internally. It was seen as a necessary investment so that the new features we’re building don’t get lost in the mess of all of our old systems. If you’re interested in the technical side of things check out the “A Note From The Developer” section below to see what feature development for Krafties is like, and to get an intimate sneak peek at Foraging!
Please remember that this is a beta release, so some things may look or act wonky as we’re testing the waters. Still, we’d love to hear feedback from our players! Please post your thoughts in chat and we’ll take notes and react accordingly.
Limited Edition Circuit coated Eletrixx creatures are available now, with three awesome new coat varieties! Attracted by our new tech upgrade, these robotic friends pulse and glow with the elemental energy they are imbued with.
You’ll find a vendor in front of the main store on Krafties Island with a limited edition Circuit coated Eletrixx! These unbonded, specially coated creatures are available for L$1,000 from now through July 20th. When purchased, players have a 45% chance of getting a BronzeCircuit coat, a 35% chance for a SilverCircuit coat, or a 20% chance for a GoldCircuit coat. All Circuit coated Eletrixx have a +5 for each natural stat along with an Adaptive elemental affinity. Their elemental affinity will change and adjust to any elemental soul you bond it with!
A Note From The Developer
Ever want to know what the technical side of Krafties is like? That’s what these dev notes are for!
Here are some entries from a small dev log centered around the upcoming Foraging feature (which I refer to as a MUD, or Multi-User Dungeon, in these logs). This will probably be very boring and complete nonsense if you’re not a developer, but someone might find it interesting! Without further ado:
Long ago, in a development environment far far away…
The Beginning
Dev Log Entry: I’ve created Classes/Models for a simple world simulation based around Actors in a World, Locations composed of Structures in said World, and Actions that Actors can take based on certain Structures they encounter paired with the Abilities of individual Actors. This one is a big one, and I’m really focused on the design of the code and how to best structure things. The use case for this is in a game where you own pets and can send them on Journies where they go out and collect items and have experiences, which allows players to utilize large collections of pets passively.
Work continues on the world simulation.
I’ve been trying to focus on “clean” code a lot lately, so with this project I’m starting off with some basic TDD and patterning, un-patterning, and then re-patterning (rinse repeat). I decided to build a mini solution for tests myself which was a fun exercise, then began implementing my first set of unit and integration tests. Things are progressing nicely!
I’ve got the basics of the world functional, but designing interactions has opened up a whole new world of considerations. I had initially designed my interaction framework around interfaces that fit together based on types of actions that could be taken, and types of objects that could respond to those specific actions. An example would be an ISwimAbility interface paired with an ISwimmable interface. This would have been a nice way to structure things if:
1) I wanted a lot of very specific logic centered around particular abilities interacting with particular receptors, with very specific outcomes from those interactions
2) I was willing to require content additions to this system requiring a programmer capable of modifying the codebase to add new interfaces and implementations for new abilities and interaction points.
Realistically, I usually try to avoid (2) if possible. In my case, I’d much rather to be able to create an endless slew of interaction combinations fed in from some dynamic data source, which allows content designers with a simple tool (like a spreadsheet) to build meaningful content with a low amount of friction.
Sooo, not only have I finished some of the things shown in the tests, but I’ve also reworked the interaction system to function based on generic IInteractionSource and IInteractionReceiver interfaces. Next up: a way to map a dynamic data source onto my domain models to allow the construction of meaningful interactions.
The final form of this mapping solution is still hazy for now, but I’m looking forward to seeing what it ends up becoming!
This will be very low on graphics to start off with. You can think of it pretty much like a MUD (https://en.wikipedia.org/wiki/MUD) that people are sending magical pet creatures into. The resulting items and effects will have some fun graphics, but it will mostly be menu-driven in v1.
I do, however, want to design it in a way that real-time graphics can be integrated into it at a later date. This is a nice start on world-building with some amount of narrative, all done procedurally, which could lead to a low-cost way to design an interesting world before investing a bunch of resources into assets. For now, simple text-based interactions are the goal.
I’ve restructured code in the MUD game and added a few new (failing) tests in anticipation of future stuff. My big issue right now is working out how I want to allow setting up interaction filters. Different species will have different Abilities, and thus will only be able to interact with certain types of Structures. I can feel an elegant solution on the tip of my brain, but nothing is solidifying just yet.
Not feeling at the top of my game, but getting happier with my architecture around Actor->Structure and Actor->Actor interactions. Looking through git, some interesting files in this area include an IEventReceiver interface and an abstract InteractionStrategy class.
InteractionStrategies are both IInteractionReceivers and IInteractionSources, which allow Actors and Structures to open up “interaction channels” (string labels) that an external IInteractionSource can then use to create Interactions using matching string labels. The thought now is that these Interactions will result in Events.
In a nutshell, I need a “Lake” to be able to be interacted with in different ways based on the abilities that different types of Actors who encounter it possess. One might swim in it, another might drink from it, another might use it for scrying, etc. This solution feels like it’s going to be flexible and modular enough. Time will tell.
I dreamed up a perfect google search for an issue I was facing, which led to an architecture shift I’m pretty happy with regarding InteractionStrategies and interaction channels. Actors and Structures now inherit from an abstract Interactor, which itself contains strategies for interacting.
Additionally, my interaction channels are functional, and I’ve moved on to using real data sources to build domain models! Right now these are all structured as key-value hash maps, but will most likely be drawn in from a database/cache setup in its final form. No matter how the data enters the system, this new addition will allow us to create a rich world of Locations, Structures, Actors, and Interactions that map to each other on predefined rules.
Now that I’ve seen this data mapping implemented it’s also giving me ideas on how to abstract our classes and interfaces to create even more shared logic. Most of these are already set up as Containers of some other type, but in my next session, I’ll hopefully be able to standardize these relationships even more.
My container realization proved fruitful! I’ve completely removed the concept of “Locations” in my current codebase and moved toward “Environments” as my abstraction.
My reasoning is that, if possible, I’d love for this to be re-usable for different types of semantic world simulations, and not only this specific implementation. In my previous version I had constricted myself to:
– Worlds composed of Locations
– Locations composed of Structures and Actors which can interact
This was fine for my current use-case where I’m planning to have a World full of biome type Locations, which then have specific interactable Structures in them. I can generate an interesting storyline with those pieces, but… what are the spatial components of an actual story?
As I thought more, I realized that the way we represent settings in stories changes from macro to micro in countless cascading levels, with Actors in stories able to “interact” on each of these levels.
You can sit on your bathtub while being in your bathroom, in your house, in your neighborhood, in your city, in your state, in your country, on your planet, in the universe. You can refer to an Actor’s existence on each of those levels at any point in a storyline, and interact accordingly. In order to emulate this multi-level inhabiting behavior, and make the engine more flexible, I shifted things slightly with Environments.
Environments contain both Actors and Structures, and (most importantly for this writeup) are Environment containers themselves. It’s Environments all the way down! Now, I’m not constricted to a simple World->Location relationship. Worlds are Environments, and the granularity chosen for the physical representations within that world are free to be as big or as small, as specific or as unspecific, and as few or as many as the particular simulation requires!
I cleaned up the new Environment code and added some of the helper classes needed, then got most of the old Location based tests moved over to Environments. Nothing exciting, but necessary nonetheless.
This session was all about the data mapping implementation: how to configure the types of Environments, Structures, Actors, and Interactions which make up a particular simulation and making it flexible enough to switch between vastly different simulations. This has to be easily configurable without having to dive deep into the code, and ideally will be flexible enough to support a wide variety of “semantic simulations”, narrative models, or whatever else you want to call it.
In a nutshell, I’m using rudimentary dependency injection to inject different DataPopulationMappers (this name is eh) into my Factories. I’ll break that down:
– DataPopulationMapper: These are objects which hold a big list of string keys that map to collections of other strings, which are then used to construct domain models. These collections hold the abstract relationships that will be constructed when the simulation is built. An example is an EnvironmentStructureMapper, which maps the different types of Structures that can exist in a particular type of Environment. This concept gets really neat when you look at the EnvironmentEnvironmentMapper, which maps Environment types to sub-Environments.
– Factories: Right now, there’s an EnvironmentFactory, a StructureFactory, and an ActorFactory. In their constructor, each of these factories require DataPopulationMappers to be passed into them in order for them to function. This means that I can (and will) have EnvironmentFactories that have wildly different creational behavior in the same simulation!
On TDD: My tests show that my Interactions have been broken by this refactor and that I have yet to fully test my data mapping solution. I think at this point all it really needs is some mock data to be input, but that will have to wait. All in all, on this small scale I’ve been enjoying TDD. At times it’s annoying going back and refactoring my tests, but at this stage, the benefits are outweighing the hassle.
I’m back to where I was a while ago, but now with much more flexible architecture. The next step is supplying Factories with data and beginning to start really simulating Actors moving around in Environments and interacting with Structures and each other.
I’ve set up the data to run a very simple simulation comprising a few levels of Environments, with different types of Actors and Structures corresponding to each. Additionally, this data holds types of InteractionChannels that correspond to said Actors and Structures. These will be used in more complex logic when running simulations.
I’ve also created some rudimentary logic to perform updates on Environments, which then cascade downwards into their sub-Environments, Actors, and Structures. I’m not sure if this top-down updating order is going to be acceptable in my final update tick implementation, but it was very simple to put in for the time being.
One big thing I want to take some time to figure out is how to make the data that’s input into the system more elegant and less repetitive. Some way to compose sets, or inherit from templates, will make designing these simulations manageable. But that’s a problem for another time.
Now that this basic structure is here, it’s time to make it do more interesting stuff!
https://prnt.sc/10kcez5
https://prnt.sc/10kcflr
Well, it happened. I’ve offered my project up as a sacrifice to the gods of scope creep and accepted that this codebase will be much larger than I initially planned. This is mostly because I’ve been enjoying the project so much, I think I can make the final product that I initially started creating for that much better by investing a bit more now, and I’m seeing more ways I’d like to use this architecture in the future. And so…
I’m implementing a component-based model structured around a loose Entity Component format, and restructuring my existing domain models to use this structure. I created the basics for composing entities from components, getting them from entities, calling methods on components and mutating state on them, updating entities with cascading updates across their components, and tested a simple HealthComponent.
I’ll now have to consider how to best restructure my most complex relationships, namely Environments and InteractionChannels, but I think I see a more or less clear path. Onward
Began a huge refactoring of an old, but incredibly important, codebase that my other MUD project will rely on for its frontend. This is an “app” system I began in 2013 using HTML, CSS, javascript, and jquery. This was before the modern era of web development had really taken hold. It doesn’t have any niceties like importing and bundling modules. I had to write my own importing framework which used http requests to pull in different scripts which provided dependencies across the global namespace…
Over the years, I’ve written around 30 “micro apps” in this framework that all tie into one overarching system. I’ve decided it’s time to pull the trigger and update the codebase to use webpack, as well as consolidating the user experience into one central experience before I introduce this new MUD gameplay element into the mix.
Wish me luck!
That entry then led to the push to completely restructure our app system, which is now being released into beta today!
– <3 Kris
