Post by LazyKitty in Might is Right comments

Viewing post in Might is Right comments

Hey,

You're completely right about the defense. Right now you can only get lvl 1 mercenaries, these are too weak to defend against most enemies. I'm working on a feature that will allow you to train your troops to a higher level for money. It will be ready sometime next week.

With respect to analytics, I collect some event data, but not enough to draw solid conclusions. I'm having trouble figuring out what type of metrics to collects that would be helpful. I have win/loss metrics for the player in general, for each unit specifically, talent learning metrics, item usage metrics, button clicks metrics. But it's hard to draw conclusions as the metrics engine (Google Analytics) doesn't let you transform the data (for free that is). I have learned a bit from these metrics, but not a huge amount. Do you have some ideas?

myffril5 years ago (2 edits)

I have no strong recommendations about the analytics, it's a problem I've butted up against once in a while but I am not well versed in the options for rich logging, and without some detailed knowledge of your game's architecture I would probably just lead you astray. I tend to just review the relevant packages in NPM and see which one most closely aligns with my style and intent.

In the work I've done before I liked a paradigm called event-sourced architecture. I am not sure that it is relevant to your game, but the basic idea is that all user interactions and sources of random data are logged to a single table in a database with a timestamp, so you can rewind and replay events to reconstruct application state for testing / debugging. Although it is done for performance reasons too.

It's a bit of a watch and it is more targeted to large web applications, but if you are interested:

https://www.youtube.com/watch?v=8JKjvY4etTY&t=1s

I would suggest you try out "feature flags". For example, if I was working with the codebase right now, I might put the ability for wandering parties to attack garrisons behind a feature flag until garrison defense was implemented, maybe as a cookie or session storage item. I would also have a special development flag for 'turn everything on'. Then when the feature is complete, just delete the if-check that determines whether or not the feature should be available, and keep it on all the time. This would allow you to not have to manage testing and release branches and make it relatively easy for you to enter the test mode on most setups.

Although that particular example might be moot considering your upcoming release, in general it's a good way to keep features merged in to your main codebase and up to date, while keeping the rest of your app (game) well-oiled.

I am starting to feel like I am clogging up your page with comments, is there a way we can DM?

Edit: I just now realized I discombobulated some paragraphs here. The event sourcing stuff was in relation to analytics.

LazyKitty5 years ago

Haha, Even Sourcing is an interesting thing. I never seen that particular name for it, I used to just think of it as Operation Log. My engine is written with a lot of that in place, many things are written as small virtual machines with very small instruction set. I do record some of that, but I haven't found it very useful with Google Analytics. Having complete traced in a somewhat managed way would be super nice, I might get to writing such a management system one day or find a good enough fit.

I work with git branches for features, seems to be fine. The project is so small that there's barely 2 people working on it, and I'm the only developer. So there's very little "process" in place.

Feature flags are an interesting concept too, I will give it more thought, right now I'm not sure it's a good fit for a few technical reasons specific to how the engine is implemented.

Thanks for the suggestions :)

itch.io

Viewing post in Might is Right comments