Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Some suggestions for the compiler

A topic by strutinsky created Jun 20, 2017 Views: 129 Replies: 4
Viewing posts 1 to 4
(1 edit)

I've been playing this game occasionally for like two months by now, recently beat the normal difficulty and am working on a decent multi-binary to go into the normal(autonomous) difficulty.

I do love the game, but the code editor/compiler has several albeit small issues. Probably the most annoying one is that you cannot assign values to enum entries, which means that if you want to keep your message protocols consistent, you gotta have the same message type enum in every process, even if this process only uses one type of message. So it ends up as a waste of space(2048? lines max), + a waste of time since you gotta go into every process and update the enum.

//500-599 REQUEST
//600-699 FOUND

Something like that would be awesome.

Now that i think about it, you could use variables to hold stuff like that, yes, but that's a waste of memory and a waste of instructions, since assigning a variable does use up several instructions.

Also i was thinking, maybe create lookup tables for math operations like sin/cos and possibly even atan2? There are only ~8k possible angles in-game, so a lookup table for a sin operation would be around 32 kilobytes(float(4 bytes)*8k angles) which isn't that bad, but with such a lookup table loaded sin and cos operations are just wrapping the angle + looking up the result + some multiplication. Not sure if this applies to atan2 though - the amount of possible inputs is infinite, and even for the visible area(900 pixels*900 pixels) is quite big(~1.6 megabytes for a lookup table). But in the end it ends up as a single operation against 16 that atan2 currently uses.

If you somehow manage to set up the atan2 lookup table to take arguments and convert it into an index in the lookup table we do end up with 32 kilobytes yet again, not sure if that's possible in less than 16 operations tho.

Not sure if that's worth the trouble though, because you'd rarely use more than one atan2 call in a process. 

(edit)Another thing i forgot to suggest, while not really related to the compiler, it would be great to have more options in the Custom Game screen. Ideally a map editor, of course, but adding some simple settings is enough. Like, Spawn Distance From Wells. At the start of a custom game, green and purple bases fail to spawn their defense processes because they're too close to a well, which prevents them from participating in the battle properly. Also please add fields like Well Replenish, Well Reserve 1 and Well Reserve 2 for better control over custom game wells, with an option for endless wells.


Thanks for your comments! It's always good to hear about people trying out autonomous mode :)

It should be possible to assign values to enums, and when I typed in the enum in your post it worked correctly (MSG_REQUEST_ESCORT was 500, etc.). Are you using the latest version (v1.3)? I don't remember there being a problem with enums in the earlier versions but it's possible that there was and I fixed it.

The game does use look-up tables for trig functions, although they're not as efficient as they could be. But the in-game instruction cost of calling these functions is just an arbitrary number; it doesn't map directly on to the performance cost of the game itself doing the calculations and I think if it was more accurate the trig functions would probably be much more expensive (especially atan2, which is quite complicated).

I agree that custom games could be improved - the problem, as always, is time! I'd like to get to it eventually, though.

lel nevermind me then

I think i didn't even try that stuff out, which is a gg for me, i just kinda assumed that since you cannot assign values to variables on declaration, you cannot assign them to enums. Plus i don't think any designs in campaign use that feature, maybe i just didn't notice that tho.

Thanks for the response. Now i shall go continue working on my processes.

Well... it mostly works. switch() throws an error if the difference between cases is higher than 32, which isn't deadly, but surely can be improved.

But yeah, sorry for my stupidity, enum constants value assignment sure works.


Cool :)