nedjelja, 31. siječnja 2016.

Preparing space combat

On a way to implement space combat I have implemented conflict detection logic and unstubbed some parts of the game. Conflict detection is a mechanism for finding where and when space battle happens. Under the hood a fleet can have multiple waypoints and with advanced enough interstellar drive it can pass through multiple star systems in a same turn. If one of them happens to have an enemy presence, space battle happens and the fleet ends it's turn there. When the conflict begins is also important, it influences a turn limitation. If at the end of player's turn a fleet was 1 light year away from destination, traveled at the speed of 2 ly/turn and battle happened there then it would have 50% of maximum combat turns to resolve the fight. In case the battle doesn't end by then I plan to make persistent battles which can span multiple galaxy turns. I also thought about making a mechanism where a quick enough fleet can fight in multiple systems. For instance if a fleet finishes one battle quickly and is fast enough to travel to next star system it would be able to fight a few more turns there too. The problem is int that case conflicts wouldn't be isolated and players wouldn't be able to play each conflict to the end before moving on to the next one. It might work by making players play all space battles simultaneously, one turn at the time but that doesn't sound like fun. So I'll go with one battle per fleet per turn limitation and keep the idea in the drawer :). There is also a question of what to do with colony ships that retreated from the battle, do they try to reach a marked planet or do they go home and do what exactly? I'll cross that bridge when I come to it.

Next step toward space battles was making AI build ships so a player can have somebody to attack. In order to implement that I had to change how the game rotates players during the turn. So far I had a "current player" number and only one player could interact with a "game core" at the time. On the other hand AI was supposed to do it's work in the background. Since both AI and human player used the same means of communicating with the game core AI could only manipulate the empire of current human player so for a brief moment there was an AI which filled my building queues with random stuff :). To make AI independent I tossed the concept of the current player out of the core so from the it's perspective everybody is playing simultaneously and it is up to a user interface to worry about who has the turn. Interesting consequence of it is that Stareater is now very close to having hot-seat multiplayer.

utorak, 19. siječnja 2016.

Works on my machine

Every time I make Stareater release I find a new program breaking bug. Not just game breaking like improper behaviour of the game but bug that completely crashes the game's executable. Previous release turned out to be no different despite my effort.

Truth to be told I don't have much in a way of release procedure, there are no automated tests, nor alpha, beta and release candidate testing periods. Heck, there is not much in a way of installation package either, just zipped folder. But I do try to check by hand if the zipped stuff works at all before uploading it. And guess what, it did work on my machine. It also worked on the other machine I sometimes use for developing the project. I asked a friend to test it on his computer but Christmas was near, I couldn't wait so I uploaded it anyway. Couple of weeks later I met with him brought the topic up and he gave it a try. Main window appeared over the whole screen but main menu was not there. Second or two later the program crashed with only the most basic and generic "Application crashed unexpectedly" error message.


That puzzled me because I specifically made a logic for trapping run-time errors and displaying the error details in a manner which reasonably competent user could report to developers (me). Since there was no such error message I had to reproduce the problem in the environment where I have some debugging tools. Guess what, I could reproduce it on my own computer on which it worked before upload. Trick was to download a zip file from the Internet, not use the one I uploaded. No, it was not the case of GitHub or SourceForge (for some reason GitHub hosts Stareater releases there despite SoruceForge's shady recent history) injecting something in my file but the case of Windows not trusting downloaded files and .Net security. Such circumstances made the Stareater to reject loading DLLs for AI logic and map generator. These DLLs can be replaced by mods so they are not exactly known to the Stareater's EXE in advance and not trusted because of it. To be honest I'm not the best informed about security surrounding untrusted code but I've been educating myself on one previous projects and it turned out Mono doesn't support it. If I remember correctly Mono simply ignores security related functions, doesn't explode with errors but as we wanted to sandbox 3rd party code we dropped the concept and moved to something else. In the future I could spend more time researching the topic and make some sort of DLL trust checking but for now I'll just allow all.

Sorry for inconvenience, next build will be available when some visible part of space combats is implemented. Or sooner if there is an interest.