This is the first in the series of blog posts detailing how I’m going with Charge. So far I’ve got most of the core gameplay systems up and running. There’s turns, each player has an army, you can do all the core orders for each unit, movement, pivots, charges, using abilities, etc etc. The game isn’t much to look at right now, but I’m thinking that once the core systems are implemented I’ll move onto making it less.. placeholder-y. Then the screenshots will come thick and fast. I hit a roadblock last week where the data that was being sent between turns (aka, the entire game state and history) was too big for Apple’s GameKit turn based systems. I figured I’d hit this point eventually, but not quite so soon. So this post picks up where I left off last week trying to implement the reducer pattern roughly inspired by this blog series: Making a turn-based multiplayer game in Rust - What’s a turn-based game anyway? (part 1/3) Long story short, we just send the actions for the previous turn, and then rebuild the game state locally. It’s more or less working at this point minus a couple missing features and a nasty bug with the Unity Editor itself. I’ll figure that out sooner or later. It’s also a roaring success for transmission size. Back down to under 10% of the budget. I’ve got some concerns about how saving the game state to iCloud is going to perform, I’ll have to keep an eye on those sizes, but at least 1mb is bigger than 64kb. I genuinely think it’s all coming together pretty well so far. Sure it’s taking forever, but I think I’m getting better at programming whilst doing this, so fingers crossed it doesn’t all fall over in a shit heap. On the productivity front, I switched out Notion for Things 3. Had a couple days where the internet was basically dead and I couldn’t get onto Notion to see what I had to do next. Decided I wanted something with a little more purpose, a little more offline and Things definitely seems more of both. Next week I hope to finish the work on the reducer pattern and get back into regular dev. Might even treat myself and make some more models or work on effects.
Tasks completed:
(03/03/2023)
- Playtest Reducer pattern some more.
- Reducer Event: Dice Results
- Reducer Events: Combat results
- Attacks aren’t deterministic, their results occur upon consumption.
- Reducer Events: Morale Results and Psych changes
- Change auto-deployment so that it intersperses leaders amongst regiments
- Orders: advanced
- Unit Controller Status Checks (02/03/2023)
- Anything that is consumed by the reducer should be logged to logger system.
- Split order results into individual result-events
- Look into building a better way of divvying up tasks into sprints (01/03/2023)
- Switch bug reporter over to Things
- Research Astra Fellowships
- Add Deselect button to Unit UI
- Don’t store full unit data in game data
- Replace existing c# events with messenger service
- Camera FOV gets wonky sometimes with an NaN error
- Change gamplay transmission to be orders only
- Unit Exhaustion
Bugs squashed
- Using abilities causes a nullreff
- Attacks just fall over. The event doesn’t actually fire.
- Order results are busted completely lol.
- Orders get spammed / looped somehow
- Missing Ref: UnitUI.ShowAbilityRadius
- Player one can see Player Two’s army on deploy
- Individuals are hard to select
- Cannot pivot a unit unless dragging from centre
- Unit names incorrect in viewer
- Order events only send state, not dice rolls or logs
- Local games camera always starts at player one
- Turns aren’t sending on Device
- Load game crashes after a game has already previously been loaded