nasoderemo

Cart File | Forum Post |

	More cartridges by PrinceD

More Cartridges [View All]

 

nasoderemo

by PrinceD

Cart #nasoderemo-0 | 2022-10-05 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

9

A simple real time strategy game. Drag and drop to send armies to conquer the world. Villages produce new soldiers, Towers shoot at enemies, Castles produce new soldiers twice as fast. This is an early playable version.

very lovely. some of the other guys keep dying for some reason? they get sent out and perish just past the castle. i was on easy with large map as humans if that helps. i can't wait to see where this goes. :)

Even in this stage of development, it's great how everything moves when there are a lot of troops marching back and forth across the screen. I like the detail of how the cursor changes depending on which side you're on. Gold star.

Similar to @Ummmm_ok I have seen units die for no apparent reason. I have seen this work both for and against me. I think it only happens when someone has a Tower, but it can happen far outside their range and I don't see projectiles flying.

For example, see the Orc corpses in the lower left here.

And the human corpses in the upper left here.

Also, in this game there seem to be two projectiles just hovering in the lower right. They stayed in place for several minutes until the game ended. (I was playing Humans here. It didn't end well.)

After further experimentation, I have only been able to get the mystery sniping behavior:

• On Large maps
• When there is an occupied Tower near one edge of the board
• Against troops near the opposite corner of the board

Here is an example. The tower is here...

...and the damage it does is here.

For a while the Humans had this Tower, and I (the Orcs) lost units near the southwest corner of the map. Then I captured the corner Tower, and the Humans were the ones losing units.

I see that Towers choose the closest target based on this function:

distance=(r.x-t.x)*(r.x-t.x)+(r.y-t.y)*(r.y-t.y)

Good optimisation to realise you don't need to take the square root to know which is the minimum distance.

However, if the X and Y values are in pixels, this will overflow a signed 16-bit integer on the Large map, resulting in negative distances. This may be affecting other distance-type calculations too. Various fixes are feasible, but will chew into your token count. You might prefer to choose a maximum map size where this is guaranteed not to happen (so about 180 pixels square).

This bug seems to happen because of integer overload when calculating distances - I'll fix it asap.

Really fun!