closes #53

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

The ship should orbit the body of the top-most sphere of influence it finds itself within.

At present, a planet has a simple circular orbit around a parent star (#27). This works because the planet is a child of the star entity and has an Orbit {} component.

If the ship were given the Orbit {} component and made the child of another entity, it would orbit that entity's origin, which means it could easily be made to orbit the planet while the planet orbits the star or to simply orbit the star.

As the ship moves however we need to be able to un-parent it from one entity and have it orbit another. We need to detect these changes at a certain distance from the parent entities, hence the terminology "sphere of influence".

The star's sphere of influence should extend to the bounds of the current star system. Planetary spheres of influence will be much smaller and will sit within the stellar sphere of influence.

Unsure how best to implement this yet...

As the player travels around, they should be able to place their ship in an orbit around each body in the system. As stated, the orbital system currently works for objects with an Orbit component and a parent in the entity hierarchy. So could we, by determining proximity to a massive object, change the parent of the ship entity? Or is there some alternative way we should come about this...

See: https://github.com/BraymatterOrg/bevy_tiling_background

It's a young project (less than a year in development) but it is active. Not much documentation to be found, so I'll want to take it for a test spin and see if I can figure out how to use it from reviewing the source and examples.

1. Clone the repo and run the examples; find a best fit
2. Evaluate the example code and modify for Verse
3. Evaluate and attempt to understand the source[^1]

[^1]: If the project is abandoned, we will be forced to either adopt and maintain it ourselves, wait for someone else to do so, or reimplement the tiled background some other way.

There's plenty more I want to add to the credits. In the mid-to-long term:

• Backers/Supporters
• The game engine, Bevy
• Notable packages used

In the more immediate term, I've added a new audio asset and am unable to fit the credit on screen. I want to append this to the credits, but will need to implement scrolling in order to start showing more info:

            parent.spawn((TextBundle {
                style: Style {
                    margin: UiRect::top(Val::Px(25.)),
                    ..default()
                },
                text: Text::from_section(
                    "Audio".to_ascii_uppercase(),
                    TextStyle {
                        font: ui.font.clone(),
                        font_size: 24.0,
                        color: Color::rgb_u8(0x00, 0x88, 0x88),
                    },
                ),
                ..default()
            },));
            parent.spawn((TextBundle {
                style: Style {
                    margin: UiRect::top(Val::Px(25.)),
                    ..default()
                },
                text: Text::from_section(
                    "Impact Sounds by Kenney",
                    TextStyle {
                        font: ui.font.clone(),
                        font_size: 20.0,
                        color: Color::rgb_u8(0xCC, 0xCC, 0xCC),
                    },
                ),
                ..default()
            },));
            parent.spawn((TextBundle {
                text: Text::from_section(
                    "kenney.nl, CC0",
                    TextStyle {
                        font: ui.font.clone(),
                        font_size: 14.0,
                        color: Color::rgb_u8(0xAA, 0xAA, 0xAA),
                    },
                ),
                ..default()
            },));

closes #26

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

closes #17

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

I believe the way to build for release in Bevy is:

cargo build --release

This creates an executable I am able to run, but...

1. The ship sprite is not shown, indicating some issue with the assets pipeline maybe
2. The debug lines from Rapier2d are shown - these should not be present in production

The latter issue I believe can probably be addressed like so:

    #[cfg(debug_assertions)]
    app.add_plugins(RapierDebugRenderPlugin::default());

Just requires some modifications to the main function that sets up the app.

The missing sprite issue... I have no clue, and if it weren't for the debug lines I'd have no idea that the rest was even working.

Good to resolve these issues early so that we can think about implementing a continuous release cycle.

closes #57

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

I've just reworked modules to make for a tidier directory structure... It's good, but it's not perfect.

I'm wondering if something like a world-app separation makes sense, where a world module contains submodules astronomical/, terrestrial/ and spacecraft/ for the three types of "world" the player will explore and the app module would contain... everything else: the camera, menus, effects, post-processing, etc.

Maybe...

• Core
• App
• World

Core would contain state management, application setup, the game_time resource and that sort of thing.

App would contain menus, the camera, the states themselves, inputs, etc.

And world would contain the player and gameplay features.

Restructuring an app is pretty easy and straightforward, but tedious and messy in the git history. Not something we want to do often, so I want to hold off on any more for now - when I have a better understanding of which parts are better placed together, we'll revisit this.

closes #29

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

closes #50

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

A beam weapon. This should not spawn a tangible/consistent entity like the ballistic cannon, but should instead draw a beam in the pointing direction of "infinite" length. If the beam intersects with a ship or other collidable object, the length should be the distance between the emitter and the hit entity.

The beam should travel at the speed of light (though this is not worth considering at the scales we're playing at, I don't think), meaning that if relevant the length of the beam ought to grow the longer it is being fired... and when released, that length should persist as it fades into the distance. Again, not worth considering at the current scale - we'll skip this for now, I think.

I know roughly the logic that goes into producing a beam...

1. If a ship is firing its beam weapon...
2. Calculate a line of "infinite" distance from the ship in the direction it is facing
3. If this line intersects with some other entity, restrain the length to this distance (closest intersection)
4. Draw that in the scene and emit the consequences to the event system (probably)

It's the drawing part I'm unsure of. I'm sure I can draw a simple line in Bevy, I just haven't worked with Bevy's geometry components yet. I'm also not sure if it is the correct approach, or if a texture ought to be used instead. Any texture used would need to be repeating for the full length of the beam... And one thing I would like is for the beam to grow weaker over a greater distance (an imperfect laser), but again, this is unlikely to be relevant at the current scale.

What IS relevant at the current scale is this: The player should not be able to use this at infinite distances regardless of my talk of "infinite" length above. The player should not be able to sweep an arc around the scene and connect with enemy entities 10s of thousands of metres away.

Eventually beam weapons should maybe be affected by large gravitational objects like black holes (I've recently been playing with applying gravity to the ballistic weapons, but have not yet committed to implementing this).

This may inform the decision about whether or not to draw a geometric line or a texture-based one. A texture would be harder to bend, and you'd see the breaks in the texture as you attempted to do so, no? Hence I think drawing it as a textureless entity, based only on Bevy's geometry and drawing capabilities is the right way to go.

Combat

• [x] #53
• [ ] Weapon variety
  • [x] Ballistic cannon (23763184a17542eeec1465e298019fd2845f3ed9)
  • [ ] #69
• [ ] Enemy variety
• [ ] #52

Careers

• [ ] Asteroid mining
• [ ] Transport/logistics

World

• [ ] #51
• [ ] Interior spaces, living quarters
• [ ] Pets
• [ ] Crew
• [ ] Planetary landings
• [ ] #10
• [ ] Megastructures/Engineering/Wormholes and Warp Gates

Story

• [ ] Narrative and dialogue

This is a ways off, but I've been thinking about it a fair bit. Related: #33, #12.

In particular, I've been thinking about Earth and how to handle the shape of the planet. Since we're working in 2D, we're limited in how we represent the world and our best approach is going to be to represent the planet surface as a rectangle (parallel sides and opposite sides of equal length).

Seen from space, the planets should still be circles. We can create this illusion with masking, perhaps with some distortion, and we will definitely be thinking about animating the planetary surface as though the surface were rotating. Essentially we move the rectangular projection left or right and repeat it, as if it were rotating around a cylinder.

That's all simple stuff... (hubristic nemesis on this one is a long time from now).

What's more complicated is picking a projection (particularly for the Earth) and mapping it out so that it is traversable not just east-west (a cylinder) nor repeating in the north-south direction (a torus) but having it such that the cardinal directions are switched when you travel over the pole.

You should be able to travel North, head over the pole and... begin heading South down the opposite side of the planet.

So, assume the entire surface of the planet is a single tile. I'm thinking about a system like this:

The above uses the Mercator projection (not a final decision) but it illustrates my meaning. Travel north through Europe and over the pole and you will continue heading south through Russia and towards Australia. Each row of tiles is rotated 180 degrees and offset by half the distance of the whole...

I still don't know how we'll do this, but it sounds achievable, right?

The same will be done for Mars, the Moon, Mercury, any other local planets and moons we've mapped and we'll do the same for procedurally generated planets too.

The poles are infinitely larger than they're supposed to be, and the Mercator projection has some biasing in favour of conformal lines rather than equal-area. Alternative projections do exist: https://en.wikipedia.org/wiki/List_of_map_projections

When picking a projection, be sure to determine whether conformality is required in our maths (in which case, probably Web Mercator is best) or whether or not an equal-area or compromise map would suffice and be better representative of scales.

Recently implemented the beginnings of an AI system for enemies in the game, but all it does right now is aggressively turn and fly towards the player. The inevitable result of this is that if the enemy aligns perfectly with the player, they will collide with and push the player (their desired state is to be precisely where the player is). Since high-speed collisions should be, y'know, dangerous, we should prefer that they steer to avoid the player and strafe during combat instead.

That's just one behaviour from a list of steering behaviours not yet implemented:

• [x] Seek (00bf90d26b8f247c39879ae66252dd13dbe71d8e)
• [ ] Flee and Arrival
• [ ] Wander
• [ ] Pursuit and Evade
• [ ] "Movement Manager"
• [ ] Collision Avoidance
• [ ] Path Following
• [ ] Leader Following
• [ ] Queue

This list adopted from here: https://code.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732 "Movement Manager" quoted and emphasised because it isn't really a steering behaviour, but a way to combine steering behaviours.

The guide linked above is very old and was written for Flash (so there are some demonstrations missing) but I did reference it when writing the initial seek behaviour, and I think it offers clear advice even if I do have to adapt it heavily.

We don't need to implement these behaviours all at once, though some do clearly follow from one another ("Leader Following" and "Queue"). The list is also incomplete, and we might well consider adding advanced behaviours like flocking, flanking or pincering, advanced routing or pathfinding, etc.

A more detailed and more advanced discussion of steering behaviours can be found here: https://www.red3d.com/cwr/steer/gdc99/

An ideal implementation would be comprised of several smaller code submodules which could be swapped between using a tag or marker system (change behaviour at the toggle of a component). This would make it more manageable, more reusable and more compatible with higher-level AI implementations like big-brain.

When I created the milestone for v0.1, I added this description:

Something playable. By v0.1.0 we should have at least one gameplay loop that's actually fun and rewarding to play.

Well, we have gameplay now... it feels fun... but it isn't rewarding, and there is no loop.

So, before finalising v0.1, I want to make sure those last two conditions are met:

• the gameplay should reward the player
• there should be a tangible gameplay loop

Adding reward to the gameplay might be something as basic as displaying a score (this score might later evolve into an experience points system).

As for creating a gameplay loop, we need a few things:

• The player should be able to replenish their health (I imagine the ship hovering over the Earth-like planet and having their hit-points slowly restored)
• The challenge should increase (enemies should come in greater and greater numbers, making outmanoeuvring and destroying them all more and more of a challenge)
• And, of course, every successfully destroyed enemy should increase a score visible on screen

At that point, Verse isn't just a half-sim half-toy that features basic gameplay. At that point, Verse is a game.

It raises the question...

If that's v0.1, what is v0.1.1? Some of that gameplay will be dialled back as we tweak background systems. For my own development purposes, I could do with the capability to turn enemy systems on or off... which I can do by simply commenting/uncommenting code.

From a player/supporter/downloader's perspective, it makes sense that each versioned "release" is additive (meaning whatever systems I toggle off should be toggled back on before a release). If the gameplay fundamentally changes, this is indicative that another minor version increase is required.

In essence, any v0.1.* version should be fundamentally the same game as v0.1.0,

Does this restrict my process at all?

Might video devlogs slow to the point that they're between versions, rather than describing versions, with bigger release videos also happening every so often...

Bridges we'll think about crossing as we approach them, I think. For now, the aim for v0.1 remains for it to be the first version qualifying as a "game" (meaning meeting the aforementioned criteria).