DEV Community: ty buser

ok. move the material update

ty buser — Sun, 27 Mar 2022 05:37:58 +0000

ok, instead of feeding hte material with updates on event tick, only do it after functions i want the material to work, then use a timeline which gives me better control on the curves. so move eneny > timeline > affect material

did some aspect ratio research!

ty buser — Mon, 31 Jan 2022 07:54:23 +0000

currently the bounds of the level are generated by reading the viewport size, instead i will feed it specific values of a common resolution type (probably 19:6 or 1.777777777777778).

then in camera setup, I'll get the viewport size, get the ratio value, use 1.777777777777778 as my default ortho width and camera height with a map range unclamped node, with a second value for 19.5:9) then adjust the camera as necessary. probably wont be a linear solution though, so I'm guess I'll really probably just have to test a bunch and make adjustments based on lots of testing

then i can probably strip out a lot of the "GetCameraInfo" calls since most of those were referring to level bounds really rather than camera or viewport.

then i can get back to spawning player pregame pawns.

detour

ty buser — Sun, 30 Jan 2022 07:15:39 +0000

thought i was going to be making logic for spawning player pregame pawns tonight. but i freaked out, i realized in a quest to maximize the playable area of a phone, i had derived the size of my play area by the resolution size. this gave me anxiety about how different players my visualize the game, the layout of enemies, etc. i wasn't sure how to square this without having the black bars. then after some digging, i realized that 16:9 is by far and away the most common resolution ratio. so i believe as long as i play to that, i should be ok.

gonna play some apex.

ok cant concentrate but...

ty buser — Thu, 27 Jan 2022 05:47:27 +0000

I've taken care of the asteroids.

Now heres what needs to happen. Player controllers need to read bsGameState and check IsPregameInstance, if true, then spawn a player actor at a location. Then allow the player to shoot as soon as possible.

Then add a timer.

Then determine distance from wall.

Then determine winner.

Here goes

ty buser — Wed, 26 Jan 2022 06:20:06 +0000

Hoping this will add some clarity for my future self. I'm going to be writing here at the end of work so I don't lose my momentum between gaps (baby girl #3 is on the way after all).

Tonight I finished messing around with the stupid pregame material. It looks ok. Good enough.

Then I investigated actually making the pregame stage actually happen. I did that by adding a flag to bsGameState called "IsPregameInstance" which is fed to the level on load as a parse option in bsGameMode. When that is true, bsEnemy actors will self-destroy. I still need to make it not do a lot of other stuff, game mode related I imagine. I think I should also have it destroy asteroids, leave any "crystals" that might be there though to lure players aim.

Decide how the player flow works. I think I'll just spawn players automatically to keep things moving and place them on the right side randomly, with them spaced out a bit from each other. With only crystals available as obstructions, no one should have a bad position.

Once their ship is spawned, player should be able to fire right away. None of the player ships will collide to keep things simple. Player closest to the wall goes first in the resulting game, player further to the wall goes last in the resulting game. Pregame should have a "timer" to keep things moving. 30 seconds?

With that done, then there's a level transition and a the level is reloaded without the "IsPregameInstance" parse option. I'm guessing I can store the player order in bsGameMode or bsGameState?