A Beginner's Question

[Boaz Ouriel]

Hi All,

Introduction

I am developing a 2d tower defense game using unity. A couple of weeks ago and though making nice progress, I felt that robustness of the design is lacking due to the tight dependencies between the various components of the game. So I decided to take a pause with the development and do some research on how to redesign the game. A short research led me to strange framework and after a few days of reading the documentation and going over various examples I feel that I understand the concepts and their value in making the game design better. However, I still am unsure about how to project my game into the strange components (i.e. what are my commands, signals, views, models and controllers) and was hoping to get some guidance from folks here in the forum with a more experience in using strange for their games. I thought that perhaps getting a direction check on an example might help me in moving forward with my new design.

Moving Creeps along a path example

Not surprisingly, the creeps in a tower defense game are walking along a spline path. I have an editor extension that allows me to visually create the spline from unity and to generate an array of way points that get injected to the path game object. Creeps hold a reference to the path object and follow the way point when spawned.

Since the game is a 2d game, I have 4 "RUN" animations per creep: up, down, left and right. Every time the creep reaches a way point I recalculate the direction the creep is pointing to and trigger the proper "RUN" animation via the Animator object. All of this is pretty simple, right?

Now, I am trying to figure out how to translate this code to strange. Here are my thoughts:

LevelModel: A model class that contains a the array of points in the path. For simplicity, let's assume there is a single path for now in each level.

CreepModel: A model class that tracks the currently assigned index in the path and the current RUN animation to use by the animator.

CreepView: The view class of the creep game object. Among many other things, the game object contains a unity Animator object that drives the 4 "RUN" animations. This component is accessible to the view.

CreepMediator: The creep mediator class.

And now comes the flow I had in mind:

1. Let's assume the creep is already running along the spline.
2. The CreepView MonoBehavior::Update() method drives the position of the creep game object towards the next assigned way point in the path.
3. When reaching the next assigned way point in the path. The CreepView sends a WayPointReached signal, which is a simple empty signal.
4. This signal is registered by its view (the CreepMediator). In response, the CreepMediator checks whether this is the last way point in the path and responds:
1. If this is not the last way point, sends a signal to move the creep to its next way point 
2. If this is the last way point, sends an end of path reached
5. Both signals described in #4 are mapped to equivalent commands that contain the logic. 
6. The AssignNextWayPoint command updates the creep model with the current index and "RUN" animation of the CreepModel.
7. The CreepModel updates these values and triggers WayPointUpdated signal which is registered by the CreepMediator object. 
8. The mediator injects that information to the CreepView.

And a few questions:

1. Does this seem like a sane approach when using strange MVCS approach? 
2. It is very tempting to let the CreepMediator do the calculations internally and shortcut the need for all the signals and controller commands, what do you think?
3. I can take step #4 even one step further and push the logic in the mediator into the CreepModel, so that the model is the one to send an end of path reached signal instead of a WayPointUpdated signal
4. Is this flow a big performance overhead (let's assume the commands & signals are all pooled)?

Thanks and sorry for this long post,

Boaz

[wcorwin]

Hi, Welcome!

This all sounds pretty straightforward, but is there any particular reason you're choosing to send a single waypoint at a time, as opposed to a path?

1. It sounds sane.

2. Remember to do your view work in your view. Doing it in the mediator is probably a mistake (it should be reserved for setup/teardown and communication, with minimal logic). Just because you're using strange doesn't mean you need to use it for *everything*. That would be a mistake. Moving stuff around? Playing sounds? Checking bounds and collision and raycasting? That's all legit view code! Don't be worried about putting it in the right place.

2a. Be careful of overmediation! You may only need to Mediate a parent class, and not each individual creep. Depends on your game and it's complexity, but always be looking for ways to simplify. Overmediation is the most common error across the board from big companies to newcomers.

3. It sounded like you were injecting the CreepModel in to the CreepMediator and checking after each waypoint there. I'd definitely recommend the logic in the model in this case. Creating superfluous code for commands can be tiring and difficult to follow months later. Pick a standard and go with it. 

4. Unless you're firing loads of commands every frame you'll be fine. Common sense and a profiler are all you need.

And you didn't ask, but a TD game maps pretty cleanly to an ECS, so if you're planning a full rewrite, you may consider it. I'm happy to help provide some examples of pairing a custom ECS I made with strange. Essentially the ECS does the heavy lifting, and strange does the view and underlying architecture.

[Boaz Ouriel]

Hi,

Thanks for the very quick response.

Yes, sending the entire path is definitely an option. This of course means that the CreepView needs to handle the movement along way points and also needs to identify the appropriate "RUN" animation. Are these considered legit View roles? Does it even need to be mediated?

My current design is ECS based, for example: creep entities are a composition of capabilities (MonoBehaviours), Damageable class represents the health, Moveable class takes care of moving the creep along the spline, and a Detector class detects units to attack and the Assigner class assigns a target weapons, etc...

However, the different components described above hold references to each other for various reasons. I was hoping to break these dependencies by using strange strange signals making the dependencies lest stringent. 

What do you think? Is this what you meant with your last comment? 

I would be very happy if you could share some ECS with strange examples, I am really interested in this.

Again thank you for the feedback, it is extremely useful for me

[wcorwin]

Re: Pathing, yes that's totally legit for a view to do! Don't overthink it. If you're moving stuff around on the screen and manipulating visible objects thats view work.

Re:  ECS You shouldn't have components referencing one another. That's what the services are for. Entities can know what their components are (mostly for performance and convenience sake), but components really shouldn't.

Happy to share some examples, but I've been sharing a private repo individually with interested parties lately and I need a way that scales better. I didn't want to release it as a full example because it's hardly complete. But maybe I should devote a little time. What little strange time I can find tends to go in to bug fixes, PRs and getting things ready for 1.0 release.

[Boaz Ouriel]

Ok, based on your response I am beginning to understand the issues with my current design. The design is not really ECS (even though I tried achieving this), the main reason is that components should contain the data and the System/Services should be the ones driving the logic. My design mixes them both together.

Thanks for the guidance - it is extremely valuable, and I do hope to see strange 1.0 and examples of ECS with strange.