Greetings and salutations!
This week's screenshot shows a new feature of "space": Asteroid fields!
The week just past was perhaps focussed for the most part on content of one sort or another, but with a few other things included, too:
Monday, April 11. 2022
A Solar System More Populated
Summary: In which asteroids are added; "space"-traffic passes by; the path to the gaining of "metroidvania upgrades" is begun--and has a dream in its interval; the disabling of weapons and utilities is conveyed, and polished; and the game's response to window-resizing is altered.
Greetings and salutations!
This week's screenshot shows a new feature of "space": Asteroid fields!
The week just past was perhaps focussed for the most part on content of one sort or another, but with a few other things included, too:
Greetings and salutations!
This week's screenshot shows a new feature of "space": Asteroid fields!
The week just past was perhaps focussed for the most part on content of one sort or another, but with a few other things included, too:
As shown above, solar systems now have not only planets, moons, stars, and suns, but now asteroid fields too!
These proved quite tricky to implement, as I recall. In particular, an asteroid field, even a two-dimensional one as we have here, may include an awful lot of space-rocks. The field shown above has, if I'm not much mistaken, fully one thousand.
That would make for rather too many objects in the scene, I fear, both in terms of visible geometry and collision elements. A more performance-friendly approach was, I felt, called for.
On the visible side, this approach is, in essence, that of having just a single model depicting all one-thousand asteroids. This model is then subject to a new vertex-shader that moves the vertices into place, informed by data largely packed into the model's vertex-colours.
On the collision side, I employed a technique recently shown by a friend of mine: Internally, there is a pool of only thirty-one colliders per asteroid field. Logic is then in place to determine (approximately) the closest point on the asteroid-orbit to the player's position, and from this, to place the colliders at the calculated locations of the thirty-one nearest asteroids.
And indeed, these in tandem seem to work fairly well! They're not perfect, but for the most part seem to amount to a decent solution, I feel.
Remaining in "space", the solar systems gained one more feature in the week just past: traffic! Simply put, there are now other ships flying about the place, ostensibly off on their own travels.
These came, however, with some tricky design-work: How should they fit into the game? Perhaps in particular, should the player be able to fight them?
Consider: If the player can fight and destroy them, then what comes of doing so?
In one of the game's inspirations, Operation: Inner Space, such piracy, while dangerous, could provide some useful resources. But Moons in Crystal has a fairly limited set of resources, and no monetary resource at all.
Further, what of there being consequences for so acting? Should there be "police" ships that go after piratical players? Should there be changes in the player's interactions with various characters due to such actions? Such things seemed, as I recall, like elements that I didn't want to engage with in this project. And indeed, I think in retrospect that they would have been undue scope-creep.
In the end the solution that came to me was fairly simple: the player can shoot these other ships--but they have a ridiculous amount of health, and simply "boost" away when shot.
On the gameplay side, I began work on the course by which the player will, I intend, gain at least their major "metroidvania upgrades".
In short, this involves the arcanists of the (artificial) Arcane Moon, who upgrade the player's vessel with new parts, and through those new parts, with new abilities. This will tend, I think, to call for the player to acquire certain items for the making of the parts in question.
But the process takes time. Time enough for the protagonist to slip into dreaming--dreaming dominated by the danger that approaches...
All of this has had, at least, a start: The foundations of the Arcane Moon and of one arcanist are in place; the player can interact with that arcanist, and so gain their upgrade; and between one and the other, they enter a brief dream. However, much of this is quite nascent, and there's a fair bit yet to be done!
There are points in the game at which the player's utilities or weapons may be disabled. For example, while on a planet they are allowed to use neither, and while in a race they may not use their utilities. (After all, the teleportation utility could be a bit of a problem for the latter!)
In the week just past, then, I implemented the conveyance of this into the UI, and added a bit of polish to the functionality of it.
In technical matters, I made a change to the way that the game responds to its window being resized.
You see, in testing another matter, I discovered that the game's view responded in different manners to horizontal and vertical resizing: when vertically resized, it merely cropped the view, but when horizontally resized, it instead shrank the view.
Not liking this, I set about changing it.
What I now have, then, is in effect this: The game's view shows a fixed in-game distance in its shorter dimension. When the shorter dimension is extended or reduced, the game's view scales with it. Conversely, when the longer dimension is extended or reduced, the view simply shows more or less along that dimension. Of course, when a given dimension is extended or reduced beyond the other--when, for example, the longer dimension is reduced to be less than the shorter dimension--their roles naturally swap.
And importantly, this holds true for both the horizontal and the vertical, I do believe!
This, at the least, feels rather more consistent to me!
And once again there were various changes, fixes, and tweaks enacted in the week just past that don't seem worth detailing here!
That, then, is all for this week--stay well, and thank you for reading! ^_^
These proved quite tricky to implement, as I recall. In particular, an asteroid field, even a two-dimensional one as we have here, may include an awful lot of space-rocks. The field shown above has, if I'm not much mistaken, fully one thousand.
That would make for rather too many objects in the scene, I fear, both in terms of visible geometry and collision elements. A more performance-friendly approach was, I felt, called for.
On the visible side, this approach is, in essence, that of having just a single model depicting all one-thousand asteroids. This model is then subject to a new vertex-shader that moves the vertices into place, informed by data largely packed into the model's vertex-colours.
On the collision side, I employed a technique recently shown by a friend of mine: Internally, there is a pool of only thirty-one colliders per asteroid field. Logic is then in place to determine (approximately) the closest point on the asteroid-orbit to the player's position, and from this, to place the colliders at the calculated locations of the thirty-one nearest asteroids.
And indeed, these in tandem seem to work fairly well! They're not perfect, but for the most part seem to amount to a decent solution, I feel.
Remaining in "space", the solar systems gained one more feature in the week just past: traffic! Simply put, there are now other ships flying about the place, ostensibly off on their own travels.
These came, however, with some tricky design-work: How should they fit into the game? Perhaps in particular, should the player be able to fight them?
Consider: If the player can fight and destroy them, then what comes of doing so?
In one of the game's inspirations, Operation: Inner Space, such piracy, while dangerous, could provide some useful resources. But Moons in Crystal has a fairly limited set of resources, and no monetary resource at all.
Further, what of there being consequences for so acting? Should there be "police" ships that go after piratical players? Should there be changes in the player's interactions with various characters due to such actions? Such things seemed, as I recall, like elements that I didn't want to engage with in this project. And indeed, I think in retrospect that they would have been undue scope-creep.
In the end the solution that came to me was fairly simple: the player can shoot these other ships--but they have a ridiculous amount of health, and simply "boost" away when shot.
On the gameplay side, I began work on the course by which the player will, I intend, gain at least their major "metroidvania upgrades".
In short, this involves the arcanists of the (artificial) Arcane Moon, who upgrade the player's vessel with new parts, and through those new parts, with new abilities. This will tend, I think, to call for the player to acquire certain items for the making of the parts in question.
But the process takes time. Time enough for the protagonist to slip into dreaming--dreaming dominated by the danger that approaches...
All of this has had, at least, a start: The foundations of the Arcane Moon and of one arcanist are in place; the player can interact with that arcanist, and so gain their upgrade; and between one and the other, they enter a brief dream. However, much of this is quite nascent, and there's a fair bit yet to be done!
There are points in the game at which the player's utilities or weapons may be disabled. For example, while on a planet they are allowed to use neither, and while in a race they may not use their utilities. (After all, the teleportation utility could be a bit of a problem for the latter!)
In the week just past, then, I implemented the conveyance of this into the UI, and added a bit of polish to the functionality of it.
In technical matters, I made a change to the way that the game responds to its window being resized.
You see, in testing another matter, I discovered that the game's view responded in different manners to horizontal and vertical resizing: when vertically resized, it merely cropped the view, but when horizontally resized, it instead shrank the view.
Not liking this, I set about changing it.
What I now have, then, is in effect this: The game's view shows a fixed in-game distance in its shorter dimension. When the shorter dimension is extended or reduced, the game's view scales with it. Conversely, when the longer dimension is extended or reduced, the view simply shows more or less along that dimension. Of course, when a given dimension is extended or reduced beyond the other--when, for example, the longer dimension is reduced to be less than the shorter dimension--their roles naturally swap.
And importantly, this holds true for both the horizontal and the vertical, I do believe!
This, at the least, feels rather more consistent to me!
And once again there were various changes, fixes, and tweaks enacted in the week just past that don't seem worth detailing here!
That, then, is all for this week--stay well, and thank you for reading! ^_^
Trackbacks
Trackback specific URI for this entry
No Trackbacks
