🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

strutinsky

2
Posts
2
Topics
A member registered 124 days ago

Recent community posts

It's me again. Working on some autonomous multi-binary and managed to break the game. The main base somehow built the turret even though there was not enough data to build it.

http://imgur.com/a/dxQB0 

The code that probably caused this weird bug(pretty messy but i'm currently working in "as long as it works" mode):

enum{
TARGET_BUILT_BY,
TARGET_RIGHT,
TARGET_BACK,
TARGET_LEFT,
TARGET_FWD,
TARGET_BUILDER,
TARGET_SCOUT,
TARGET_COMM,
TARGET_SCAN1,
TARGET_SCAN2,
TARGET_SCAN3,
TARGET_SCAN4,
TARGET_SCAN5,
TARGET_SCAN6,
TARGET_DEFENCES,
TARGET_ENEMIES_SEEN = 32
};
enum{
TURRET_DEFENCE_RATING = 15,
INTERIOR_DEFENCE_RATING = 5,
WALL_DEFENCE_RATING = 20
};
enum{
TEMP_BUILDER,
TEMP_MINER,
TEMP_BASE,
TEMP_SHIP1,
TEMP_SHIP2,
TEMP_SCOUT,
TEMP_TURRET,
TEMP_INNER,
TEMP_WALL
};
int empty_defence_slot;
int buffer;
int buffer2;
int defences_rating;
int largest_enemy_attack_size;
int perform_defence_scan;
//...
perform_defence_scan--;
//...
if(scan_for_threat(...))
//...
}else{
if(perform_defence_scan<0){
perform_defence_scan = 40;
defences_rating = 20;
//Base counts for 20 defence
for(buffer = TARGET_DEFENCES; buffer<TARGET_ENEMIES_SEEN; buffer++){
if(process[buffer].visible()){
switch(process[buffer].get_template()){
case TEMP_TURRET: defences_rating += TURRET_DEFENCE_RATING; break;
case TEMP_INNER: defences_rating += INTERIOR_DEFENCE_RATING; break;
case TEMP_WALL: defences_rating += WALL_DEFENCE_RATING; break;
}
}
}
}
auto_stability.set_stability(0);
auto_harvest.gather_data();
auto_allocate.allocate_data(2);
if(empty_defence_slot != -1)
if(defences_rating<largest_enemy_attack_size&&random(3)==2){
buffer = random(3) + TEMP_TURRET;
buffer2 = random(8000);
switch(buffer){
//The next line is, i bet, what caused the bug:
case TEMP_TURRET: build_process(buffer, cos(buffer2, 400), sin(buffer2, 400), buffer2, empty_defence_slot);
//as we can see on the screenshot, the process that was just built is TEMP_TURRET
case TEMP_INNER: build_process(buffer, cos(buffer2, 200), sin(buffer2, 200), buffer2, empty_defence_slot);
case TEMP_WALL: build_process(buffer, cos(buffer2, 600), sin(buffer2, 600), buffer2, empty_defence_slot);
}
}
//Deploys a builder if none present, otherwise deploys a scout if none present
if(get_available_data()>1000){
//Deploys a random unit
}
}
//Other code, including the code that keeps targeting memory consistent by collapsing all the gaps between TARGET_DEFENCES
and TARGET_ENEMIES_SEEN, and also between TARGET_ENEMIES_SEEN and 64

This code is only partial, if you need the whole process, or even the whole pack of processes, tell me and i'll send you a .zip of all .c files + the seed & settings for this battle.

Although it doesn't seem like that outcome can be replicated, not sure how that is possible. Just tried to re-do that battle, no bug this time.

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.

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.

(Edited 1 time)

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.

enum{
//500-599 REQUEST
MSG_REQUEST_ESCORT = 500,
MSG_REQUEST_BUILDER = 501,
//600-699 FOUND
MSG_WELL_FOUND = 600,
MSG_ENEMY_FOUND = 601
};

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.