You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's Thanksgiving week, and I've been more fixated on gaming than usual. However, here are some things I got up to.
Unit Tests Added
I've been making slow and steady progress against our initial test coverage goal of 60%. There isn't much interesting to say here, but tests did uncover one bug (#33). I plan to continue this progress until I hit 60%, then return to feature work.
Some Things In The Incubator (AKA, my 🧠)
I've been brewing a couple of ideas this week. I'm not committed to moving in these directions, but they're exciting thought experiments.
Localized Rule System State
One takeaway from microservices architecture is the idea of a localized state. Rather than each system connecting to the same data store, the system listens for events and uses the events to build a local view of the game state. This is how the client already works. In this model, the event stream is the source of truth rather than a centralized game state object.
Why is this beneficial? The game state is a large object that we must mock to test rules systems. However, the rules systems often only need to know about a small slice of the game state. Furthermore, developers must remember to emit events describing their systems' actions on the game state. In this model, the rules systems only need to understand the events they care about and their effect on the world (see the next paragraph). They emit events to change the game state rather than as secondary actions after manipulating the game state. This leads to a simple, easy-to-use interface for building rules systems (listening for and emitting events).
Why haven't I jumped on this idea? The primary reason is that it will require a fair amount of refactoring to get away from the game state. It could also lead to many bloated systems rather than a single oversized state. The other reason is that state synchronization becomes a more significant problem- how do we guarantee that one plug-and-play system understands how an event from another system changed the world?
Nevertheless, it's an idea to keep pondering.
Designer UI vs. Builds
One of the coolest features of RPG Maker is that it provides a friendly interface for designers to edit the game. This build is then exported and run on top of the RPG Maker engine. I've been thinking about a similar system for URF that would allow designers to use the Unity interface to create content, then export that content as asset files. The actual build would be a core engine that loads the asset files and runs the game.
Of course, URF is open source, so developers can edit it as they see fit. However, I like the potential of creating a high-level interface for those starting in game dev. I haven't jumped on this idea because I'm not well-versed in Unity customization. It's something I expect to add to the roadmap eventually, though.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Devlog No2 -- Unit Testing
It's Thanksgiving week, and I've been more fixated on gaming than usual. However, here are some things I got up to.
Unit Tests Added
I've been making slow and steady progress against our initial test coverage goal of 60%. There isn't much interesting to say here, but tests did uncover one bug (#33). I plan to continue this progress until I hit 60%, then return to feature work.
Some Things In The Incubator (AKA, my 🧠)
I've been brewing a couple of ideas this week. I'm not committed to moving in these directions, but they're exciting thought experiments.
Localized Rule System State
One takeaway from microservices architecture is the idea of a localized state. Rather than each system connecting to the same data store, the system listens for events and uses the events to build a local view of the game state. This is how the client already works. In this model, the event stream is the source of truth rather than a centralized game state object.
Why is this beneficial? The game state is a large object that we must mock to test rules systems. However, the rules systems often only need to know about a small slice of the game state. Furthermore, developers must remember to emit events describing their systems' actions on the game state. In this model, the rules systems only need to understand the events they care about and their effect on the world (see the next paragraph). They emit events to change the game state rather than as secondary actions after manipulating the game state. This leads to a simple, easy-to-use interface for building rules systems (listening for and emitting events).
Why haven't I jumped on this idea? The primary reason is that it will require a fair amount of refactoring to get away from the game state. It could also lead to many bloated systems rather than a single oversized state. The other reason is that state synchronization becomes a more significant problem- how do we guarantee that one plug-and-play system understands how an event from another system changed the world?
Nevertheless, it's an idea to keep pondering.
Designer UI vs. Builds
One of the coolest features of RPG Maker is that it provides a friendly interface for designers to edit the game. This build is then exported and run on top of the RPG Maker engine. I've been thinking about a similar system for URF that would allow designers to use the Unity interface to create content, then export that content as asset files. The actual build would be a core engine that loads the asset files and runs the game.
Of course, URF is open source, so developers can edit it as they see fit. However, I like the potential of creating a high-level interface for those starting in game dev. I haven't jumped on this idea because I'm not well-versed in Unity customization. It's something I expect to add to the roadmap eventually, though.
Beta Was this translation helpful? Give feedback.
All reactions