Knights of Grumthorr - Steam Keys

Started by Matty, November 09, 2020, 07:32:06

Previous topic - Next topic

Matty

I've contacted Valve about changing my game from paid to free.

In 60 days I failed to earn sufficient for the minimum payout $100 usd so I may as well change it from saleable to free.

One less hurdle for anyone who might have wanted to play it removed.

Valve takes about a week per their documentation to make such a change.

So....could be a nice Christmas gift for anyone who enjoys such games.

Matty

KoG became $0/free 11 hours ago.  Currently over 400 downloads since then.

That's very good since on launch it sold 6 copies in 7 days.

Matty

After 500 downloads in 15 hrs - I could be living quite comfortably were I earning $1 per download.  Instead it's free of charge!

Derron

You know that 1$ is about 10000000000000000000000000% (I might have an error here :D) more than 0$ ?
Ok ... better say it is on 100% discount now.

More important is where they come from - as said people post about games "now free" or on "100% discount". And then the collector users just "collect" without even playing.

As you have metrics it will be more interesting to see how many new users are playing it - compare this to your download count (now ... and when only paying users were downloading).



bye
Ron

Matty

Haha yes Derron.  I'm not all that surprised.

One thing I enjoy is that I like playing it myself.  My better games often have me coming back over and over to muck around in them for years after their first creation, and this is one of them.

Scaremonger

Is it worth adding adverts into games?

I don't know what the rates are like, but the Android play store it's full of them so it's got to generate something?

Matty

Not in this case.

Derron will laugh:
800+ downloads while free, but only 3 have launched the game.
Collectors I suppose.

Matty

Oh.ps here is an optimisation tip for any who wish to make their own rts or similar game, you may already know this.

Assuming 1000s of units in game:

Each unit is in a sequential array and carries an id number which is unique and merely a sequential index.

Rather than checking various things, eg targeting, orders etc, every frame for every unit you can stagger it.

For example I do this:

If (game.framenumber + unit id number mod checkframe)==0 then do action 'x'

If the framerate is 60fps, and you want the action to be checked once per second then checkframe should be set to 60.  Higher numbers mean check less often.

This means if there are 60 units in game then each frame only 1 unit is checked, and the next frame another unit is checked and so on.

If there are 120 units in game then each frame 2 units are checked, if 1200 units then 20 are checked.

If you then separate the animations and movement which occurs every single frame from things like checking targets, attack damage and so on you can have a smooth game where the outcomes occur from combat etc based on frame time.

A further optimisation, if the game begins to take longer than desired for an update segment over say 10 seconds of gameplay then you can begin gradually increasing 'checkframe' to higher values which reduces the number of units being checked per frame and the update loop should start to become faster and hopefully within your desired frametime for it.

My game handles 2,000 units on a map at a time and if the game starts to chug then it increases checkframe from 60 to 80 and then 110 to keep the update loop running nicely.

This is pretty much invisible to the user as in the heat of combat few notice that eg an Elven warrior takes a couple of extra seconds to dispatch an enemy - especially when there might be dozens or hundreds on screen at that time.

Derron

Ok ... so you have an array full of units.

if a unit dies this spot is taken over by a new unit later on ... so "arr[0] - arr[59]" are full of units, it won't become more and more full of "holes" right?
Then you guarantee that each unit is updated.

But how often is it updated? You only update it once every second.
How often per second can you click? How fast can you "think"?

I would say that 1 second per "update" is a bit too little.


I know -- this is less predicable, but couldn't you have multiple things:
- react on "events" (onReceiveDamage(), onFinishTask(), ...)
- have individual "update speeds" (nextUpdateFrame = currentUpdateFrame + mySpeed)

That way units could be made "slow/dumb" by not thinking so often - or eg units can "sleep" and while they sleep they do not update at all, or only "randomly" ...
... except when they are attacked or sensing something.



bye
Ron

Matty

Derron, before you say it is too little....why not play it and feel for yourself, it is free after all ;-) ?

Derron

it is too little.

Assume unit is "fleeing" (so not attacking, defending)
Now you attack this unit 10 milliseconds after their update ... you will be able to hit them for 990 further milliseconds until the unit decides on what to do next.

I fully understand your idea of lowering cpu usage this way - but dunno ... think there will be more suitable ones (like events).


bye
Ron

Matty

Some statistics that surprised me:

The top 4 download countries were China with 1000 downloads, Russia, US and Germany with 200 each (give or take 10% with each number there).

I was surprised by the massive chunk China has of the downloads.  About a third of all my downloads are from there overall.

Matty

Oh Derron re events.  I reread your earlier post above - my game does that as well.

Some unit decisions take place instantly as situations arise but some are based on a staggered  once per second update.

So for example when a unit is damaged a flee check is made.

But when scanning for targets this happens less frequently.

It works very well.

Derron

Yes ... you can do these "lazy checks" ("hmm what could I do") less often.
Of course you could just "randomly" (every second :D) emit an "do lazy updates" event so the unit thinks about doing something ... idling, searching for boogers, ..

So as long your units get informed "without delay" everything is OK :)

bye
Ron

iWasAdam

you should address your draw code so that 'popping' doesn't occur and also watch your map checking as units can go through walls!