plan

--- plan ---

--- making the initial screen

i think i want to specify a target number of lines to fit in the screen as a constant. and then everything else would be a derived value. during setup i could do a trial blit and see if our test content reaches the target # of lines, then grow or shrink it until we hit the desired size. the aspect ratio is always going to be variable and that's fine. after i do that i can put together a formalized component struct for our line buffer. that will take up all but the very bottom rows of text on the screen. the last line or two will be our actions as described below. and then yeah i think i am in good shape for my game. i could always expand upon it later if i wanted to blit individual characters to x/y coords for some nethack gameplay segments. but i think we're looking good.

we want a backscroll of room descriptions and titles, our actions. but we also want our options as the bottom line at all times. we could do this with ten lines ostensibly. we would have 8 lines as our backbuffer, a space, and then one line for our action options like move (n)orth.

it would require a complete rework, really just a "work" since it's not implemented yet, but it would require implementing the backscroll, allocating characters to their rightful place, etc. i think it should be as simple as take a string % char_width and throw it into the buffer. once it's in the circular buffer we save our buffer offset and print the previous x lines. we can always add complications later.

---

for starters, how about a map is 3x3 with the player in the center.

for this rehack project, need to ascertain how big a cell is. we can just start by saying it's 1/10th of the screen height

maybe a good initial rehack mvp would be one static dungeon level; you win when you get to the end. your character has inventory like potions and all the basic inventory management works. when you get to stairs down it flashes 'you win!'

maybe it would be funny to make all my 'games' little demos that end in 'you win!'
- hovercraft itself
- rehack
- the hex rpg one
- the idtech one

once i have really crude versions of those four i can get feedback and proceed with the most promising one.

i've now reset the project to be a central project for a few different rust/bevy game ideas i'd been working on. i set aside the idea of targeting wasm for now, though the proof of concept worked well enough. i'm convinced i could add it back in as a target later but for now it just adds complexity when i haven't finished a game mvp yet. so native only for all these little game demo ideas for now.

i want to at least look into training AI via reinforcement learning how to play my 1v1 game. it seems like tch-rs binds the C++ bindings from pytorch into rust. so i would just have to find a way for my game to run headless. or maybe i should have the AI actually read screen renders?  i don't know enough about it yet.

https://bevy.org/examples/animation/animated-mesh/

supposedly i can add a 'realize instances' node at the end to make real nodes the glb can then see and import

it turns out trying to export a geometry node animation to glb is a huge pain. i tried exporting to alembic and back, which did seem to do something productive, but in the end importing the .glb back into blender and hitting play revealed the animation was lost.

when i open up the .glb file, an animation is there but i do not see any explosion happening.

blender's cell fracture add-on is first-party and will let me model explosion animations

now that we've shown we can get _a_ shader to work, it's time to get a shader that at least looks a little like a laser to work.
it's also time to resize the laser, ideally just extracting information from blender about the cannon width.

https://bevy.org/examples/shaders/custom-shader-instancing/
^ use that to make my map draw faster

if i am going to add large files, use https://git-lfs.com/

it occurs to me the scene load logic may only fire if the scene _is not cached_. i may need to mess around renmaing the file just to force it to reload and fire the event

how about a chunk is a 2x2 set of tiles so we have a many:1 situation to test initially

i need to decide whether this is something i can make a decent improvement of my boring background by doing, or if i should just leave it some matte color and move on

in the motion blur bevy demo, the ground has a cool texture on it. do i need shadows=true?

consider adding `noise = "0.9.0"` to cargo toml for terrain generation
though i think random would be fine for now

are all targets travel points? are all travel points targets? do i want to navigate via target controls? warp via target controls? not sure yet

as we press T we cycle targets. pressing space approaches that target. that exercises the "get to destination" code that will then be shared by the bot. pressing O orbits that target at 100m. that will also exercise the "get to destination" code and we'll use the orbit code to get the destination. the only unique code will be how the bot selects a behavior (TODO) and how we do (with keyboard input).

- add planets
- unify player and bot movement around the idea of a destination
- introduce the idea of having two players and two bots
- add two orbit distances the player can toggle between with 1 and 2 keys.
- remove idea of manually controlling ship for now
- remove tag danglers
- increase scale of map
- remove grid and replace with a 3d procgen terrain underneath
- add instagib rail cannon
- add destruction animation
- add webifier module
- add idea of space weather? space wind? remember we're not actually in space. setting tbd
- i had some ideas for module sizes that would be easy to read and distinct from mwo: newt(tiny), mid(avg), and terror(huge)
- add actual mechanics around rotational velocity and other requirements to land a hit
- add UI elements to determine orbital velocity status
- make chance to hit pretty low for starters, it's instagib afterall.
- charging the main gun should take battery(batt), giving up other systems like fast movement, target scrambling, limiting the enemy's movement, etc.
- the pacing of allocating resources to the various systems should feel impactful even with just one gun
- the second "gun" i add could be boarding. after an enemy has fired, you know it will take time to recharge so it's safe to board them
- boarding would require the modeling of ropes and some small physics: the ropes should slacken/tighten to pull the other ship the same way as the bound ship. is that too much work for too little payoff? we'll have to see how hard it is to model rope slackness. my guess is it shouldn't be too bad.
- i read about chunking and it seems like that would be a great fit for my abstraction. i could break each system into a grid of chunks, and just render the 9 chunks around the player. then i would just need to make sure no effects in the game occur more than a chunk's diameter away. for starters, consider a system that's 100km by 100km. we can have it be mostly empty and that's fine. because the chunks are 1km blocks. so no weapon can fire over 1km; no jammer can jam over 1km etc. then we render the 3kmx3km zone around the player as 3x3 chunks. our max render amount is 3km^2, even though our system is 100km^2. then we can warp/travel around a big system and have hidden goodies everywhere but still get good performance. each system would be a completely separate server, but one server could handle these chunks i think.

--- references ---
https://bevy.org/examples/2d-rendering/mesh2d-alpha-mode/
^ seems like this might be an easier way to do what i want
working on rendering a target: use https://bevy.org/examples/shaders/shader-material-2d/
i'm not satisfied with the movement abstraction; i want approach, orbit and targeting.
a good first step would be to introduce the idea of acceleration, velocity, facing, and turn time (rotational velocity)
how is targeting going to work? it seems like we could use entity names to fetch the target of a unit.
look at custom primitives link above to see how to make a targeting square like what i want

example for FixedUpdate:
i think some of my systems now with the custom timers could instead use fixedupdate? do some research as to which is better

--- ideas for iterative projects ---
tag(done): there's a bot that wants to tag you, then just runs left once it's no longer it
sun overseer instagib: an enemy bot is trying to destroy you. you each shoot bullets. one hit kills. may orbit, approach, or flee
steve online: expand navigation system by loading chunks of 1km square at a time. systems are made up of a _great_ many of these.
you can warp to different chunks and take gates between different systems. each system could have 1k square chunks of 1km square. it would be mostly empty. you could warp to the sun, planets, asteroid belts, space stations, or similar points of interest. you could then orbit them, keep at distance, etc. no combat for this one, just embiggen navigation.

--- units ---
the units of the world are meters. if things are not the right scale for that to be reasonable, i messed up
currently the world is 1km square. each cell is 10m.

--- goodies ---
#[cfg(not(target_arch = "wasm32"))]
^ can make native and webasm versions work at once

--- notes on getting files out of the steam flatpak's blender ---
my "home" dir is ~/.var/app/com.valvesoftware.Steam

--- notes on making models in bevy that render the right way in this project ---
how to configure models in blender:
model facing x+
top facing z+
+Y up unchecked

--- notes on exporting animations from blender into bevy ---
use the cell fracture extension, can look it up in f3 after selecting the objects you want to fracture
set the 3d cursor in the place you want your explosion to emit from
select all the bits
use 's' to scale out away from the 3d cursor
i had to much about with some options in the 3d viewpoint currently in the upper center of blender UI
i also had to change the 'options' in the far right, lower part of the upper rim GUI to only move the pieces on scale, not actually scale them.
then i made keyframes at intervals.
then i exported to glb with some sensible selections.
then i both imported the whole scene and the actual animation, and applied the animation to the scene.

--- weird bevy bugs ---
you basically just have to rename a glb file each time you change it. otherwise it will reload the stale file until you like sleep or reboot your computer. even cargo clean or deleting target/ doesn't do it. weird.

--- tools i may try ---
bevy_inspector_egui
^ this lets you visually debug your game and inspect it like a webpage.

--- learning resources ---
https://bevy.org/examples/
https://johanhelsing.studio/posts/extreme-bevy