Will try and get the fleet management ui done tomorrow. Meanwhile I've made a prototype for the sensor system: http://www.trekwar.org/Wiki.jsp?page=Devblog-18022010

Interesting. I believe that Supremacy will sort-of be using a similar system for determining sensor ranges and strengths, although I haven't really spoken to Mike about it so I can't be sure.

I do have some comments about potential improvements to the system though based on what I can see.

First off, is the sensor disruption range of anomalies. Major objects like Black Holes would have effects even light years from the singularity. However, your map as it currently stands has sensor disruptions that effect only singular sectors. I would propose that where you have red squares, they should also be surrounded by a ring of pink squares to show the diminishing, but still noticeable, effects of such major anomalies. Incidentally, BOTF actually already did this - sensor ranges in a ring of sectors were effected by things like Neutron stars. The amount of disruption caused, and the exact location of the strongest areas of effect by disruptions also changed turn-to-turn (Since Neutron stars spin, so in BOTF the location of sensor disruptions moved from sector-to-sector in the ring of 8 sectors around a Neutron star). So, using your first image as an example, if area of effect sensor disruptions were included, this is what the map might look like:



Taking this idea even further, you could even look at where the area-of-effect of separate sensor disruptions overlap. In these instances, you could have greater disruptions than pink squares that might not be as bad as red anomalies. in this instance, I would suggest orange or something to indicate the sensor reductions.




My second suggestion would be to remove the display of sensor disruptions in sectors that cannot currently be scanned. As it stands, players can see the locations of anomalies in sectors that they cannot currently scan, even though they aren't scanning them! In this respect, it allows players to cheat, especially if those anomalies would damage or destroy their ships if they were sent into those sectors - experienced players would know not to send their ships there. So, using the original map again, if the display of sensor disruptions outside of scan-able range was implemented, the map would instead look like this:




Please don't take these as criticisms, I understand the system is new and a work-in-progress. I mean this purely as constructive criticism. The sensor map sounds like a great idea already and i'm looking forward to getting to play the game.

The prototype only had single tiles with distruption as it was basically just a bresenham line algorithm that diminishes in strength as it hit obstacles.
The game will have sensor disturbances that are not limited to a single tile (neutron stars, black holes, sensor jammers). So it will be as in your image, that red squares can have pink squares around them. Pulsars will also have a long trail of sensor disturbance that rotates around it. Maybe neutron stars could have something similar, but not so long and maybe a bit more unpredictable?


Sensor disturbances will be combined, so two very heavy disruptions close to each other will produce this effect. Sensor disturbance can range from 10 (empty space) up to 100 (black hole / neutron star). Sensor strength will also be upgradable as new techs are discovered, going from maybe 20 to 120 (which would allow ships to see what's going on at a black hole if they were extremely close, but would still create a big blind spot behind it).

I think sensor strength will not be combined for ships in a fleet, cause then you could just have a couple of cheap ships with very heavy sensors, and be able to see everything. So just like the slowest warp drive determines the speed of a fleet, the best sensor will determine what the fleet sees.

Also sensor strength on the map itself is not added, so you cant just have 5 fleets next to each other and clearly see into a black hole.


This is just a prototype, so Fog of war is not implemented yet


Not at all, I'm happy for all feedback, and I want to thank you for taking the time to actually modify the screenshots to show what you mean. I should have put it more clearly that this was just a prototype and that fog of war and larger anomalies was not there, but would be there in the game.

Search the forums and you'll see that i'm always making images to explain what I mean. It really didn't take very long to do, and I did it in M$ Paint so it was simple.


I did some research on Neutron stars:

With such fast rotation times, having moving disruptions might not be the most scientific way of doing it. Perhaps Neutron stars should have a full ring of strong disruptions, whilst Pulsars have a sweeping arm of disruptions?



Mike has told me that Supremacy will work the same way, with only the scan strength of the best ship in a fleet taken into account. Since you're both working on similar systems, you might want to get together and discuss your implementations. There's no point in reinventing the wheel if either of you has already done the work.

oouh, animation nice.. that's precisely how I had envisioned the pulsars


Think that part is pretty straight forward, just looping trough the list of ships finding the highest sensor and then doing the bresenham's line algorithm from that point.

In Trekwar the client asks for the map, the server then uses the algorithm above to calculate what that particular user can see and then transfer that data only. If you can see an area very poorly the server will take this into account when making "your copy of the map" and reduce visibility / accuracy in that area. This is done so that even if people change code on the client, they can never get access to secret data (starsystem stats, info on enemy fleets, tech levels, etc..) that is outside their area of view.

Is anything similar done for Supremacy, in regards to which data is actually sent to the client? Is it done the same way? (a large int[][] matching the map which says what the player can view, and a function that makes a copy of the map based on that int[][]) ?

Err...i'm still getting used to the fact that Supremacy even has a client and server in the first place. Don't ask me the specifics of how it works!

You'll have to ask Mike about it sorry. Just send him a PM. He'll probably enjoy discussing it with you.

Each civilization in Supremacy has its own set of map visibility data (a class called CivilizationMapData). Internally, CivilizationMapData has only one data field, which is a ushort[,] array (two-dimensional array of 16-bit unsigned integers). Bit shifting/packing is used to store multiple values as a single ushort. One bit is used to store whether a sector has been explored (physically visited by a ship), another bit to store if a sector has been scanned (was within range of a scanner source, i.e. ship, listening post, station, etc.). Eight bits are used to store the fuel range of a sector (distance from nearest supply source, i.e. station, shipyard). The remaining six bits store the scan strength at that sector (the strength of the most powerful scanner in that sector, or possibly the range-diminished power of a scanner in a nearby sector).

The maximum fuel range is 255 sectors (no problem, as the maximum map dimension is 256 sectors). The maximum scan strength is 63, though actual values should be much lower.