Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Since saving/loading obviously has in-game economic value, it would make sense to require player spending some resources to save the progress. Similarly to how Tomb Raider games used save crystals. In a fantasy strategy game setting, saving the game can be represented as a visit to Oracle, who takes money to predict future. Now usual supply/demand rules apply to the save-game economy. And suddenly you have save-system which work even in multiplayer games. In fact, both sides can agree on saving the game at some point and pay agreed price for that. Then any of the participating players could invoke the save. Obviously that would need to be somehow integrated with the diplomacy system.
Same way I plan to implement battlescape saves as a time travel spell, which would work even in multiplayer.
Currently I'm still struggling with getting the time system itself correctly. Original XCOM had only geoscape time, while battlescape was almost disconnected from the geoscape time-wise, with the only exception being night/day battles. And night missions were a special kind of nightmare, since aliens all had night vision. Now I want to connect the battlescape time with geoscape. Each Action Point squad spends on the world map this day will be subtracted from the time available on the battlescape, if squad enters the site exploration stage today. If the battlescape time runs out, then visitor will be forced to retreat unconditionally, losing any units surrounded by the enemy. Obviously battlescape time amount should be generous enough. Say 100 or 200 turns per day, but still encourage having some reserve time. Now time travel spell will not only help with the exploration, but will also unwind the time. The only catch is that the unit performing the time travel should survive.I don't think, result of this 3 body problem mean that you can't know what future is exactly because you need know current state better than physic laws allow.
The remaining questions is about making it possible to travel into the future from the past. That is always harder, since future is less known than the past. Or is it? Guess physicists will correct me that future is more stable and predictable than the past ( https://www.sciencealert.com/three-black-holes-orbiting-each-other-can-t-always-go-backwards-in-time ), since the future is still there, while the past has already dissipated, leaving a few fossils at best ( https://www.space.com/tunguska-meteor-impact-explained.html ).
Compared to XCOM, battles are expected to be completed faster, and there is no save in the battle. The only opportunity to save would be on the world map. But I will try to prevent save scumming. Still I guess people could save-scum anyway, running in the emulator. But at least I could use the PRNG to prevent reloading to achieve different result. I.e. all sites are pre-determined on the world generation, so there will be no way to reload the game until it spawns the type of monsters which can be easily defeated by the player's current army. Same with AI, which uses pre-seeded RNG, so reloading wont affect AI's behavior. IIRC, Heroes of Might & Magic IV determined when player reloaded the game to save scum some chests with random content and locked-up the PRGN, although that could have been a glitch. But I believe the error was determining the chest content on the pickup stages, instead of at its generation time.But you in reality replace one save-scum with another. Now player can scout in ineffective way losing most of int units, checking what he can grain, then he reload and only do things in effective way, skipping all fights that do not give any benefits.
Just to clarify - can I simply delete the entries in extrasprites or do I need to delete them elsewhere (armor defintions etc.) as well?This details I do not remember, possible only extra sprites should be fine.
my amateurish level suggests that the armor is already attached to the skins, but I could be wrongDo you mean unit face color (and hair)? If you want have marching in your new armor define `spriteFaceColor` and `spriteFaceGroup`
You just need a rotated version of each sprite, and there will be additional 3 views, each different by 90 degrees.At first glance this is disadvantage, because you need do 4 times more work than normally, but there is trick, each tile can have its own rotation, this mean if you see 4 same item each can facing different direction, this mean every version can be used even if player do not rotate map, even once.
That is called Z-buffer. A thing 3d hardware implements very efficiently.This is correct, if done poorly then big objects will be problem, but if we use tiles then on load we can check if any pixel do not "escape" 3d box where it should be.
But in case of tile-based isometric game with oversized sprites, you want to be very careful with Z-Buffer, so objects wont clip through walls. I.e. you want to render your giant units with Z-test turned off, just like you render HUD in FPS games to avoid it clashing with objects on screen. Then there are also transparent surfaces, which still require tricky sorting. Unless you do physically based rendering, where actual light rays travel the scene.
Although games like Warcraft III turned the clipping bug into a feature, providing buildings with foundation, that can be unearthed on uneven terrain.