|
 
|
"My Fourth Game: Ai Wars":
RELEASE NOTES:
NOTE: Fun Facts, Detailed Roadmaps, and additional details including new issues and bugs faced and their resolutions, will all be released later, they are being kept close to my heart for now ;)
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.003.014) build 1468.
- fixed - walls - build 1435 - walls were previously 20x20 but terrain tiles are 16x16 so using snap-to-grid via SHIFT button while deploying them always prevented placing them directly adjacent to each other, there was always a gap. walls are now smaller and 16x16 and match tile sizes but this did not fix the problem, the rectangle intersection logic was incorrect and didnt use exclusive edges so the real fix was changing intersect logic from > to >= etc.
- fixed - terrarin - map editor - build 1436 - mountains in the map editor system, seems I can place a mountain directly beneath another one but I cant place a mountain directly above another which doesn't make any sense - if I want to stack two mountains vertically I just have to place the one above first. this was an overlapping issue in the terraincollision system specifically around above-ground collisions only, a simple -1 was added to allow adjacent placement.
- fixed - structure dragging - placement system - build 1437 - structures like archertowers and walls when they are dragged the SHIFT button snap-to-grid option is not wired in like it is when placing these structures, need SHIFT snap-to-grid to work when dragging.
- fixed - rendering - FOW system - build 1450 - FOW shroud mode is working perfectly, but if I switch to FOW enabled or self healing modes the mountains become grey pixel boxes. resolved by copying the already perfectly working Shroud mode logic to the other FOW modes.
- fixed - rendering - FOW system - build 1451 - make the Enabled and Selfhealing FOW modes render objects that are just outside of line-of-sight LOS in the same way the Shroud mode does, in shroud mode archertowers and stars and walls and all entities become darker as the player moves away from them, but in Enabled and Selfhealing FOW modes those objects are either visible or not and as the player approaches them they suddenly pop into existence or disappear completely as the player moves away, Shroud mode handles this perfectly already. simply changed the unseen to hidden to visible behaviour to unseen and the fog system took care of the rest.
- done - map editor - UX - build 1452 - all entities should be made invisible during map editing including stars, botcollectors, and the player. this needs to be future proofed so any new entities will also be auto hidden and not rendered and not prevent map editor features from being placed such as mountains, the game should essentially be paused when F12 is pressed to enabled map editing and once map editor is turned off again and the user returns to RTS HUD mode then the game unpauses and all entities become visible again. it's important we dont re-invent existing systems and logic. let's just pause the game but not show the pause menu and make all entities not visible, this will halt all bot movement and all star generation and spawning, and allow the user to modify the world they are playing easily with no new systems or external apps and just allow super-simple map modifying with a save and load feature just like mario maker.
- fixed - FOW - UX - build 1455 - the FOW enabled mode is broken suddenly, not sure for how long, cant be bothered checking previous builds, but bots and stars are now visible in the dimmed fog outside of the player's LOS. also realised the minimap was also broken in the same way. copilot resolved this - tightened every entity-visibility check so Enabled/EnabledSelfHealing now require Visible tiles instead of treating Explored as visible, fixing the bug where units still appeared outside the player's line of sight.
- fixed - rendering - map editor - build 1457 - rendering bug appears to be related to the player's LOS and discovered tiles and unless all the tiles in the chunk are visible then the mountain which is quite large (4x4 tiles) doesn't render until all the terrain tiles beneath it are explored and instead appears/renders as a fallback grey square, but once fully explored it remains perfect in all FOW modes and never falls back to the grey squares. fixed - Terrain chunks under mountains now rebuild immediately, Fog overlay + AboveTerrain overlay now update correctly.
- done - map editor - UX - build 1468 - make terrain destruction possible again (currently blocked with an early return) in map editor mode but make any craters remain permanently if deployed during map editing, this will create permanent rivers and lakes since the craters expose the water subterranean layer. they need to be permanent meaning any craters dropped over the top of them in normal non-map editor mode will not suddenly cause them to heal which would be a bad bug to discover later on
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.003.012) build 1434.
- done - code logic - build 1376 - simplify and unify the terrain textures to basic colour palette mapping for the minimap to reflect how the world appears but in basic colours instead of actual textures. added a new file terrainvisual.cs and simplified the calls and code to use the new file.
- fixed - UX - HUD systems - build 1385 - if I switch to the new map editor HUD using F12 and the existing RTS HUD disappears, I can still deploy archertowers and walls if I click their approximate location on the rts hud - I suspect we need a basic mouse click return logic if the rts hud is not visible.
- fixed - code - build 1387 - replaced all instances of "-" with "-" which appear to be different ascii characters and were preventing searching from working properly, two doze files updated.
- fixed - Map Editor - build 1414 - the new MAP HUD was created using a 12 phase roadmap of steps but failed as it was reinventing what we had already spent months perfecting, I scrapped it and we wasted 24 hours, within 1 hour and by using the new approach I devised to just copy the existing RTS HUD and placementsystem we have a working system that is bulletproof and bugfree and can be reproduced for the other game genres this engine will support - RPG, ARPG, AA, SS, puzzle, etc.
- fixed - Map Editor - build 1417 - resolved the linked issue to the archertower from the RTS HUD after cloning the whole 5 class file system and repurposing it and then attempting to deploy a wall resulted in an archertower being deployed. now ready to repurpose wall as mountain (mountain-UP mountain-DOWN mountain-LEFT and mountain-RIGHT) then remove all the unnecessary behaviours (hitpoints etc), and benefit from all the bug fixed perfected systems like collisions, dragging, placement, grids, and the list goes on, weeks of effort saved. and this is now repeatable for other game genre HUDs.
- fixed - code - MAP HUD - build 1421 - deploying walls (which will become mountains) from the new MAP HUD destroy the world terrain when LMB is clicked to deploy them, need an early return on terrain destruction logic to prevent this if in map editor mode but we this has already been fixed in the RTS HUD so need to replicate that code logic. added a not-map-editor-active clause to the existing terrain destruction IF statement, fixed.
- fixed - code - MAP HUD - build 1422 - cancelling deploying walls (which will become mountains) from the new MAP HUD create a crater on the world terrain when RMB is clicked to cancel, need an early return on create crater logic to prevent this if in map editor mode but we this has already been fixed in the RTS HUD so need to replicate that code logic. RMB is handled very differently to LMB, it is handled in SDLWindowHost and this is because initially LMB was used for everything and RMB was later introduced as part of debugging bypassing all EngineTick related systems with immediate effect. added a simple break return if map editor is active, fixed.
- fixed - code - MAP HUD - build 1423 - all four mountain icons have been added to the new MAP HUD.
- fixed - code - MAP HUD - build 1430 - mountains can now be deployed via the map editor HUD and are properly rendered once deployed, the MAP HUD is now fully wired in and functional.
- fixed - code - MAP Editor - build 1434 - the size of the mountains appears incorrect, there is a grey outline around every mountain that appears once deployed, but we defined them as 64x64 everywhere so there is a scaling issue somewhere, the grey outlines are the hard perimeter edges which both the player and bots get stuck on, we need to increase the size of the deployed mountains. tiles are 20x20 so perhaps this is the issue, a footprint mismatch. Have modified the size of mountains to 60x60 so they divide cleanly into 20x20 tiles but the issue is that mountains always need to snap to grid to ensure they align perfectly however unless snap to grid is always forced this solves nothing, snap to grid must always be used for map editing features, also the collision system is pixel based not tile based so that creates complexity. this has been fixed and identified as tiles being 16x16 and not 20x20 as copilot thought, any size not divisible by 16 left a remainder creating a border effect.
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.003.010) build 1375.
- added - HUD system - build 1315 - implemented a basic HUD system for the RTS genre of the game engine (RPG, AA, SS, HUDs will be different), then fine tuned it over the next few builds and brought the minimap forward by drawing it after the HUD.
- added - UX - build 1321 - modified player's LOS value to be the same as the settings class defined vision radius instead of a separate hardcoded value, this was an oversight, now fixed.
- fixed - HUD system - build 1327 - removed the legacy Hotbar system which has massively increased FPS and we're now at 6000FPS while the player is stationery, structures are now deployable via the new HUD system which is GPU accelerated and not based on GDI+ rendering.
- fixed - FOW system - build 1330 - resolved the accumulated time timer issue since removing the hotbar which was the last GDI+ CPU rendering system and clearly had a massive impact on performance even though I was clueless, FPS has jumped 1000FPS since removing hotbar and clearly had unnoticed or explainable impact on the various timers clocks stopwatches and deltatime, now using real time and delta time and it is working instantly and perfectly, waited for minutes or longer before since removing hotbar.
- done - rendering - build 1339 - POC with new grass texture terrain is successful but with several bugs - FPS dropped from 5000 to 1000 as 80 draw rectangle calls have become 62,500 draw calls (no batching or chunking), and FOW is broken - minimap is fine but on the viewport the fog only glitches and blinks repeatedly in the top left corner chunk of the viewport - it's like it is being drawn once per frame and immediately overwritten by the new grass texture, and craters no longer appear on the viewport but the minimap is fine. this build was rolled back and deleted, a new above ground system was not required which was essentially reinventing the wheel, I rolled back to build 1336 and we repurposed the existing "world-class" rendering system which we fine tuned and optimized and spent countless hours on to now draw texture png file images instead of basic coloured tiles and the results were incredible, no FPS drop and a world that looks like a real RTS for the first time ever - milestone achieved - the game no longer looks like space invdaders from the 1980's.
- fixed - FOW system - build 1361 - the FOW system actually works for the first time ever, seems a bug was preventing it from drawing correctly like a cloud or gas and I had assumed the basic Line-Of-Sight LOS circle around the player was the best SDL2 rendering could achieve, how wrong I was, the fog now looks beautiful and cloudy and I will 100% reattempt the Starcraft2 style optimizations again to even further improve it since the last time we tried there was no visual improvement because the FOW wasn't even working. build 1361 includes grass terrain textures for the ground which looks stunning, craters now utilize some of the new texture sprites and look amazing but will be improved upon, and the fog is wow.
- done - rendering - build 1339 - POC with new grass texture terrain is successful but with several bugs - FPS dropped from 5000 to 1000 as 80 draw rectangle calls have become 62,500 draw calls (no batching or chunking), and FOW is broken - minimap is fine but on the viewport the fog only glitches and blinks repeatedly in the top left corner chunk of the viewport - it's like it is being drawn once per frame and immediately overwritten by the new grass texture, and craters no longer appear on the viewport but the minimap is fine. this build was rolled back and deleted, a new above ground system was not required which was essentially reinventing the wheel, I rolled back to build 1336 and we repurposed the existing "world-class" rendering system which we fine tuned and optimized and spent countless hours on to now draw texture png file images instead of basic coloured tiles and the results were incredible, no FPS drop and a world that looks like a real RTS for the first time ever - milestone achieved - the game no longer looks like space invdaders from the 1980's.
- fixed - FOW system - build 1361 - the FOW system actually works for the first time ever, seems a bug was preventing it from drawing correctly like a cloud or gas and I had assumed the basic Line-Of-Sight LOS circle around the player was the best SDL2 rendering could achieve, how wrong I was, the fog now looks beautiful and cloudy and I will 100% reattempt the Starcraft2 style optimizations again to even further improve it since the last time we tried there was no visual improvement because the FOW wasn't even working. build 1361 includes grass terrain textures for the ground which looks stunning, craters now utilize some of the new texture sprites and look amazing but will be improved upon, and the fog is wow.
- fixed - craters - build 1368 - resolved the inconsistencies between the various systems - terrainsystem, core main loop, terrainpalette, terraincollision - that were unaligned since we switched from 7 subterrain layers to 4 then back again to 7, and added terrain textures for every subterranean layer replacing the legacy coloured tiles system.
- done - rendering - terrain - build 1372 - fix the terrain palette now that underground subterranean layers are no longer basic coloured tiles, they are png image texture files, and craters no longer look correct and appear to be comprised of just a couple of the texture sprites and not being represented correctly, I've only got 5 terrain sprites but 7 sublayers so need to add a couple more and fix the system so that craters look as they should utilizing all 7 sublayer textures including the bottom most impassible water texture, but currently they are only 2 sprites deep it seems, so the palette is incorrect.
- done - rendering - minimap - build 1375 - the minimap no longer portrays the world correctly when craters are dropped, the minimap appears to be using the old coloured tile system while the world and camera viewport now show craters using the new textured png image file sprites - the colours no longer align, water can be seen on the minimap when the viewport shows the crater was not that deep and never revealed the most bottom subterranean layer - water.
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.002.272) build 1310.
- scrapped - chunking & batching & DOD - build 1277 - multi-unit vision merging. the new and current LOS pipeline already solved this problem.
- scrapped - chunking & batching & DOD - build 1277 - SC2-style object render culling - massive FPS boost - this is the biggest performance win left in the engine. this is done - Chunk-level frustum culling replaced the need for per-object culling.
- scrapped - chunking & batching & DOD - build 1277 - C&C-style fog rendering. Fog is just a grayscale mask - it can be easily faked using nothing but black/grey/white pixels around edges. this is a documented two tier roadmap now and not a quick win. the current fog system is now fast, stable, and consistent, and the recent attempt to completely redesign and simplify it showed just how good to existing system is.
- fixed - FOW system - rendering - chunking - build 1286 - need to revisit MarkAllChunksDirty() method and replace it with marking individual chunks that are no longer visible as dirty, either in the player's wake or more precisely after the camera moves away from that chunk. MarkAllChunksDirty() is a time bomb but it has been removed and Chunks now rebuild only when they become visible again, preventing stale terrain meshes and eliminating black-chunk artifacts when returning to previously explored areas. This resolves the long-standing issue where terrain would desync from fog state after camera movement or fog mode toggling.
- added - rendering - build 1287 - prevent world bitmap from becoming stale and the graphics card dropping the frame permanently from VRAM leading to a black terrain on the viewport - refresh the bitmap periodically (previously implemented the same for the minimap).
- fixed - FOW system - rendering - chunking - build 1288 - i explored the world, and switched between the four FOW modes, then left the game running in selfhealing mode, and came back to 3 arcs that didnt heal properly - perhaps we need to heal neighbouring chunks as well or rebuild them. need to review the terrain healing system. we added a 3x3 neighbourhood chunk boundary check to prevent stale chunks.
- fixed - FOW system - rendering - chunking - build 1307 - visible green (grass terrain) arcs remained revealing the world and even spawned stars and bots moving through the arcs after exploring them and moving far away in the world, days of effort and debugging and analysis and builds, fully documented in the fun facts section, this was one of the most difficult bugs to identify but easy enough to resolve after that.
- fixed - rendering - FOW system - rendering - build 1310 - i left the game running for an hour and came back, the black screen issue is fixed - good, but some of the fog did not selfheal - i'm not sure under which active FOW system it was explored but that shouldn't matter because any explored terrain should be marked as explored under all four FOW modes - so i then switched the FOW modes and ended up on self healing and explored more of the world and some of the previously explored parts that never healed and now nothing is self healing, all the fog of war is remaining indefinitely it seems - something still broken. finally resolved the visible arcs fog of war issue, it was an early return if fog mode is disabled preventing the simulation from running correctly and synchronized under all FOW modes.
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.002.252) build 1276.
- already done - chunking & batching & DOD - Chunked ArcherTower targeting (still global). scrapped since archertowers only target the player currently and do not cycle through all bots, this will be chunked later on. added to my future todo list.
- already done - chunking & batching & DOD - Unit batching - Make 10,000 units render at 1000+ FPS. this is already essentially implemented, the unit rendering path for bots is already chunk-aware and DOD/SoA-backed. No need to change anything yet.
- already done - chunking & batching & DOD - Bullet batching - Render 50,000 bullets with no slowdown. same as with bots this is already done as per the render loop in the core.cs class.
- already done - chunking & batching & DOD - GPU-accelerated minimap - Uses the same chunk-texture system. Instant updates. Zero cost. this is already a GPU-accelerated, chunk-texture minimap.
- done - minimap bot rendering has been changed to chunk-aware DOD iteration for additional performance gain. builds 1152 - 1190.
- already done - chunking & batching & DOD - implement "true view-frustum culling." - Right now the renderer draws everything: every bot, every star, every building, every wall, every bullet ... even if they're 3000 units off-screen in a distant part of the world. That's wasted: CPU (looping over them), GPU (draw calls), fill rate, overdraw, batching opportunities. The fix is simple and powerful: Only render objects whose bounding boxes intersect the camera viewport. This is called view frustum culling. starcraft2 does: View-frustum culling, Occlusion culling, LOD (level of detail), Animation throttling, Particle throttling, Unit batching, Terrain chunking, GPU instancing, Fog-of-war texture caching. Adding view-frustum culling is the next natural step. this is not the same as fog of war culling which is extremely complex, by comparison this is far simpler to implement with a massive performance payoff. this is already done as a result of implementing chunking - the main world render already does chunk-level frustum culling.
- fixed - rendering - terrain - terrain healing is broken since before build 1126 since we started implementing chunking for the FOW system. terrain healing rendering is somewhat broken showing partial black fog/shroud as it heals in some of the healing rings, perhaps the FOW is being rendered on top of the terrain because it is not being invalidated or marked as dirty. all recent previous backups have this same issue since "MyFourthGame 2026-05-09 1816PM.zip" when the FPS jumped to 5000+ - the note on this backup zip is: "ongoing works towards implementing chunked rendering. and now after step 10 render target terrain caching, 5000FPS!". the previous backup where the game still ran at 800FPS - "MyFourthGame 2026-05-09 1644PM.zip" - the zip has this note: "ongoing works towards implementing chunked rendering. we dropped from 680FPS to 480FPS after implementing chunk rendering, and now up to 880FPS after implementing GPU based QUADS to replace CPU based rectangles." but the terrain healing was still ok at this point. "step 10" is outlined below in the fun facts. this issue is definitely caused by certain tiles not being invalidated as part of healing now that the terrain is chunked. the issue it seemed at first was that healing was happening across multiple chunks but only some of the chunks were being invalidated leaving the others stale, but this was not it, the actual cause of the issue was hinted at by the fact that the minimap showed the terrain healing correctly without any black circles or elipses, it was a rendering related issue but more specifically it was caused by marking chunks dirty when pop-in alpha changes - we modified the pop-in animation chunk in the terrainsystem tick() method to finally resolve this after hours of troubleshooting. builds
- done - chunking & batching & DOD - build 1192 - chunk-based fog textures. Fog is now stored in chunks, not full-world. Each fog chunk has its own texture. Fog rebuild happens per chunk, not per world. Fog rendering draws chunk textures, not tiles. Fog logic marks chunks dirty, not tiles. Fog textures update only when fog changes. done.
- fixed - rendering - build 1199 - identified a strange rendering bug where the far right hand size of the map/world shows black green alternating rows going from the very top of the world to the very bottom, at first we assumed it was FOW related but it appears to be the rendering engine drawing garbage quads (a new implementation since around build 1190 or before?) and the issue appears to be related to terrain chunk rendering. The terrain corruption on the far-right edge was caused by partial terrain chunks always using a fixed 32×32 mesh, which made the renderer read stale or uninitialized tile data. The fix was to resize each chunk`s mesh to its actual tile dimensions and rebuild only the valid tiles, eliminating all black blocks, diagonal smearing, and crater-color leakage.
- done - rendering - fogofwar - build 1202 - we had an issue which I described as "I cant see anything on the view screen when the fow is enabled in any mode, if I disable the FOW then everything appears again. with the fow enabled/selfhealing/shroud - all I can see is a black screen (black terrain with no stars and the player is invisible and bots are invisible), but I can see the FPS counter if I toggle it ON, and the deployment bar is there, and the minimap is working perfectly" - we resolved this by deleting the fog drawing chunk from the main game loop in core.cs and leaving RebuildFogChunk() method unreferenced and unused within FogOfWarSystem.cs. you then advised we can fix this by "FIX: Enable alpha blending on fog chunk render targets", and "FIX #2: Ensure fog is drawn after world, before UI, NOT before world", and "FIX #3: Ensure fog chunk colors are correct", and "FIX #4: Ensure fog chunk textures are cleared with alpha". you then summarized this as: 1. Enable alpha blending on fog chunk textures - this is the real fix. 2. Confirm fog is drawn after world, before UI - we need to verify this. 3. Keep fog colors as they are - no change required". you then advised "I can generate the exact patch if you tell me your IRenderTarget API, I will produce the exact line: chunk.Target.SetBlendMode(BlendMode.Alpha); or renderer.SetRenderTargetBlendMode(chunk.Target, BlendMode.Alpha); or whatever your engine uses. Just paste the interface: 'public interface IRenderTarget {...}' or the SDL2Renderer implementation of CreateRenderTarget.". to fix this we need to restore the fog-chunk overlay system which means applying the alpha-blend fix and re-enabling fog chunk rendering. We implemented all 3 fixes. The last missing item to be implemented was the alpha-blend mode on fog chunk textures, which is the critical fix that allows fog chunks to overlay the world without blacking it out, it is now done.
- done - terrain - build 1209 - stagger the subterrain layer healing so it is not uniform, the deepest layer should heal slower than the higher layers above it towards the top most ground layer, so the bottom most layer - layer 1 (void) - should heal slowly, and layer 2 should heal faster than layer 1 but slower than layer 3, and so on until the layer directly beneath the ground layer (grass). This will prevent all terrain destruction from healing in an unnatural way like clockwork and be a little more dynamic.
- done - sourcecode - code commenting - build 1210 - add more commenting of what various code chunks do, definitely not line by line, but perhaps at least ensure every method/function is documented of what it does and also any complex chunks of code as well. the comments should be short and single line items only, copying my existing commenting style - there are a lot of methods in my project that I do not fully understand - majority if not all of them are either complex math functions related to graphics, offsets, camera, and other visual systems, but these main and helper methods are undocumented.
- fixed - logic - build 1242 - I can now edge scroll indefinitely past the edge of the world but only in the right and down directions - this appears to be related to the camera being top left clamped. this is from the code in line in ClampCamera() since recent changes - "float worldWidthPx = WorldWidth * TerrainSystem.TileSize;" and "float worldHeightPx = WorldHeight * TerrainSystem.TileSize;" because actual world size is: "TerrainSystem.WidthInTiles * TileSize" and "TerrainSystem.HeightInTiles * TileSize". resolved with some basic code updates following world chunking works.
- fixed - logic - build 1249 - bot star targeting and movement is broken since redefining visible and active terrain chunks - it seems bots no longer stop after capturing a star, they move immediately to the next star, they should stop and find the next star in their local spatial area - spatial area no longer exists since active chunks only exist in the viewport - we just need to modify the spatial awareness logic.
- fixed - logic - build 1252 - bots completely ignore terrain and do not slow down when moving through craters or destroyed terrain, their speed is not affected by the varying levels of subterrain. space bar button freeze no longer works on bots. bots cannot be pushed around by archertowers or walls anymore, they just ignore everything now it seems because the logic is chunk based and there are no active chunks anymore perhaps? but interestingly bots do stop when they hit impassible terrain, so just their speed is not impacted by layers above the bottom most impassible layer. collisions still appear to work and placing a structure - archertower or wall - over a trapped bot (they dont stop moving now so must be trapped by impassible terrain tiles) still works and they are gently pushed out of the way when a structure is placed over them. if a group of bots are targeting one star and moving towards it they still declump which is good, and if I place an archer tower in their way they simply move past it or are gently pushed out of the way, but because they no longer stop or slow down they are behaving like level 100 Ai bots but should be level 0 with only basic logic - they are ruthless and just go for the next star like hungry dogs.
- fixed - rendering - build 1255 - render only what the camera can see. investigate the sudden 1000FPS drop since about build 1190 when terrain healing rendering was resolved after I noticed strange green black rows appearing in the world on the very far right edge only. it is potentially related to fog chunk rendering. the issue actually appears to be terrain healing + chunk invalidation, and the bottleneck is structural, not accidental. specifically from marking all chunks dirty every frame which is super expensive but I think we implemented this to resolve the rendering problem - this line is the problem and occurs in multiple places - MarkAllChunksDirty() - it was introduced as a brute-force fix to a rendering bug, but it is now the structural bottleneck responsible for the 1000-FPS drop - this analysis was wrong because copilot just agreed with me which is becoming more of a thing in recent times since clearly chatgpt has been updated to agree more sigh - MarkAllChunksDirty() was not the real problem, the real problem was the visible-chunk set was wrong. Rendering of objects only happens for what`s visible in the camera frustum and the viewport and FPS has jumped up massively in all four FOW modes but especially in disabled and shroud modes, up to 4000+ FPS again, but because terrain tiles, terrain chunking, and the FOW system are still broken the other two modes are suffering with lower FPS - 3800 in enabled and self healing, but after discovering and exploring a quarter of the 200x200 tile world the FPS dropped to 1100 in both Enabled FOW and Selfhealing modes - so terrain chunking and the FOW system are both still inherently broken and need review or overhaul.
- done - performance - rendering - build 1255 - chunking & batching & DOD - player line-of-sight LOS integration. Right now, the fog system is chunked, but vision is still global and per-unit visibility isn't integrated into the chunk pipeline. LOS is a 6-step pipeline, clean and surgical: Chunk visibility counters; Per-unit vision stamping; Fog texture update per chunk; Visibility flags on entities; Render-only-if-visible; Minimap fog integration. New roadmap documented - "Player LOS integration roadmap" in . LOS vision radius implemented for player, archertowers, and bots. this is now partially wired in. We introduced basic debug code to output the number of visible chunks based on the player`s location, in disabled mode it is working perfectly alternating between 8 10 12 and 15 visible chunks, shroud mode should be the same but the number of visible chunks grow linearly past 100 as the world is explored and terrain revealed and the switching from shroud to disabled FOW mode suddenly drops the visible chunks back to 8 10 12 or 15 and switching back to disabled jumps it back to 100+ so shroud mode is broken, and both FOW Enabled and SelfHealing modes are behaving the same with visible chunks constantly climbing instead of remaining steady around the player. it seems the terminology got mixed up - we have visible chunks, active chunks, and explored chunks. visible is in direct LOS line of sight and what is in the camera frustum and what should be rendered on the viewport, active is visible + neighbouring chunks and includes chunks that must be simulated and alive, and explored means the player has seen the terrain but once the player moves on this is no longer visible or active and should be marked as dirty with nothing being rendered there - it is used for shroud mode, minimap, terrain reveal, and fog shading. MarkAllChunksDirty() must be removed, we thought it is a performance killer, chunks should be marked dirty individually, MarkAllChunksDirty() was implemented to resolve a bug but introduced a new massive performance hit however it is not the problem afterall, the problem is actually what is redrawn and where after being marked as dirty - we need to only render what the camera frustum can see, currently everything in the world is drawn every frame.
- scrapped - performance - FOW - optimize fog of war tile updates - switch to chunk-level fog, update fog only when LOS changes, use a dirty-rect system, use a bitmask fog grid, use a compute-style sweep, use a mipmapped fog pyramid, use a GPU fog texture. I think this can be scrapped because the plan now is to massively simplify the FOW system while keeping the four modes, all improvements to FOW have resulted in zero visual improvement and massive FPS performance drop and increased complexity in the code, all for nothing. a simple FOW system is all that is needed if DX11 and 3D shading will not be introduced yet. this will be addressed with the planned overhaul and simplification of the currently over-engineered FOW system.
- scrapped - performance - optimize terrain chunk re-rendering - the terrain renderer rebuilds 1024×1024 textures whenever fog changes - separate fog from terrain, draw fog as a shader overlay, avoid rebuilding terrain textures, use a fog mask texture, use a single fog render target. I think this can be scrapped because the plan now is to massively simplify the FOW system while keeping the four modes, all improvements to FOW have resulted in zero visual improvement and massive FPS performance drop and increased complexity in the code, all for nothing. a simple FOW system is all that is needed if DX11 and 3D shading will not be introduced yet. this will be addressed with the planned overhaul and simplification of the currently over-engineered FOW system.
- fixed - logic - FOW system - build 1262 - active chunks and not being marked correctly when switching between the 3 enabled FOW modes, after switching from shroud to selfhealing and after having explored some of the world, the early parts of the world do not become fog and remain fully visible meaning that in enabled and selfhealing mode some parts of the world remain explored and visible with bots and stars, but the rest of the world correctly is hidden by fog and in selfhealing mode the fog correctly disappears as it heals. the solution is to mark all chunks as explored regardless of which FOW mode is enabled or disabled, because currently the world is being patchy some parts are explored, others not when the player was clearly there, and switching between the FOW states is inconsistent and selfhealing no longer works at all. About "mark all chunks as explored regardless of mode" - we don't actually need a brute-force "mark everything explored" hack if the implemented transitions are correct - demote visible chunks to explored, and update shroud to mark tiles as explored not visible. What we do want is: Any tile the player has ever seen ends up as Explored when not currently in LOS.
- fixed - logic - FOW system - build 1264 - the last remaining bug is self healing mode, it only heals what was explored while self healing mode was enabled, meaning if the player is moving in one direction and switching between the FOW modes, then only the terrain that was explored during self healing being enabled mode eventually heals, and the terrain explored in shroud or enabled modes remains patchy in the world and on the minimap. added all explored terrain to the healing queue while the active FOW mode is either shroud or enabled, selfhealing mode already had this line of code. all explored terrain is now healed when self healing mode is active.
- fixed - performance - terrain chunking - build 1267 - review chunking after we fixed visual chunks for all four FOW modes however I am not convinced it is fully fixed and would like visual confirmation using the green violet and red chunk squares, and also more importantly, I noticed that the number of visible chunks does not change when the player remains unmoved at some world location and the camera is switched to RTS mode and the minimap is used to view distant parts of the world, the number of visible chunks does not change and appears to be linked to the player's LOS only whereas the camera frustum and viewport should definitely affect the number of visible chunks however if the player is not on screen then perhaps his LOS no longer affects visible chunks so perhaps it is working but I am not convinced, we need to add debug logging showing the coordinates of visible chunks while showing the coordinates of the player at the same time. There is zero evidence of LOS affecting chunk visibility now, debug logs of player`s tile coordinates vs visible chunks confirms chunk visibility system is 100% correct now, fog system is not influencing chunk visibility, camera frustum is the only driver of visible chunks.
- fixed - performance - terrain tiles - build 1268 - the next bottleneck is tile fog logic, not chunk fog logic. If fog chunk logic were the bottleneck, then: Disabled mode would be much higher than 1800 FPS, Shroud mode would be much higher than 1800 FPS, Enabled/SelfHealing would be much lower than 800 FPS, and the gap between modes would be huge. The remaining bottleneck is tile-level fog logic, not chunk rendering - meaning: The LOS mask, The demotion pass, The healing queue, The per-tile state changes, The UpdateChunkFlagsForTile scanning, The minimap fog dirtying, The tile-level fog state array, The per-tile blur in RebuildFogChunk, These are still running per tile, not per chunk, And that's where your CPU time is going. this is now resolved and FPS has jumped from 800-1200 to 2000-3000 in both FOW enabled and self healing modes, I have been battling these two modes for weeks now, milestone achieved, but a further patch 3 remains, this is after patches 1 and 2 were applied. more optimization on the way!
- fixed - performance - FOW system - build 1274 - I understand that FOW is an additional system but it shouldnt be killing FPS when in enabled or selfhealing modes because far less is visible and so less should be rendered, plus we are only rendering what is on the viewport now, so I suspect there is still a disconnect causing enabled and selfhealing modes to be FPS killers - the game runs at 3000FPS in shroud and disabled modes, and at 1500FPS in enabled and selfhealing. analysis outcome: FogOfWarSystem updates tiles every fog tick, and every tile update forces a terrain chunk rebuild, which is expensive, and copilot has identified at least three amplifications of code that kills FPS when FOW is enabled or selfhealing. with the 6 steps of FOW improvements implemented every FOW mode including disabled, enabled, selfhealing, and shroud, are all behaving the same now, they are consistent and averaging between 1500-2000FPS during movement and hitting 3000FPS when the player is stopped. this is a milestone moment because for weeks, maybe months now, FOW enabled and selfhealing were both killing the FPS from 3000 to 800, we have finally cracked the puzzle and solved it.
- fixed - performance - FOW system - build 1275 - patch 5 broke terrain healing and it is now happening one single tile at a time, this is seriously bad. fixed by undoing patch 5 changes.
- fixed - logic - FOW system - build 1276 - self healing is vastly improved but some terrain still does not heal, while exploring the world in FOW Enabled mode, explored terrain is not added to the healing queue. The healing queue is correctly adjusted in both SelfHealing and Shroud modes. removed the if clause that prevented shroud mode from adding explored terrain to the selfhealing queue.
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.002.251) build 1151.
- done - rendering - modify the Shroud mode Fog Of War to be a hybrid system between FOW disabled and FOW enabled because currently the Shroud mode behaves exactly like the other two FOW modes - enabled and enabled with self healing. In Shroud mode the explored world remains visible indefinitely so any entities should move around and be alive exactly like when the FOW is disabled and all bots update every frame, currently with Shroud mode distant bots in inactive chunks remain static and idle which is fine for FOW enabled modes because the world is not visible in distant places and on the minimap, but with the Shroud mode it is visible and shows bots standing still. implementing a hybrid model for Shroud mode. this has been resolved by utilizing the previously implemented isDiscovered flag which we never utilized and it remained FALSE indefinitely. a new hybrid method makes use of it now and Shroud mode is working great - fine tuning remains - details in the fun facts, but this is solid for now based on pure vector based movement from bots and no pathfinding or smarts builtin yet.
- fixed - fogofwar - resolved the fog of war modes cycle order to be more user friendly and not random, plus identified that the modes to names mappings were incorrect.
- fixed - logic - need to prevent the Function buttons from having any effect while the game is paused, currently I can enable and disable FPS counter with F11, and cycle the FOW modes with F7, and switch between diablo and rts camera modes with F5 and F6 while on the settings pause menu.
- fixed - logic - split up the fog of war modes up so that F7 cycles through the 3 enabled states, and F8 becomes a new on off toggle for fog of war disabled or not. updated the help menu and modified SDL ascii character keycodes.
- fixed - rendering - i left the game running for an hour or so and I've come back to find the minimap terrain completely black - I could still see stars and bots but the green grass was gone. it immediately returned after i mouse RMB clicked the terrain to create a crater and now it's fixed again. it seems the minimap bitmap became stale and the graphics card dropped the frame permanently. added a deltatime timer to minimaprendering called from the main game loop to refresh the bitmap every 5 seconds.
- done - UX - prevent bullets from being rendered in the shroud or fog of war when they are being shot from an archertower that is hidden in an undiscovered area so that the bullets only appear in visible chunks, currently the bullets give away the exact location of the archertower shooting them because they originate from the center of the tower which is hidden, the bullets should only be rendered and made visible once they hit explored and visible terrain. bullets are now fog aware and no longer visible whilst in fog or shroud.
- fixed - FOW - when cycling through the three FOW modes and returning back to Enabled, some of the FOW does not disappear correctly leaving arcs of visible terrain in the wake or path behind where the player was just moving through - a partial circle - just around the player giving a kind of shadow remnant of the previous visible area, it is reproducible by simply moving the player in any direction then cycling the 3 FOW modes and when it transitions from Shroud to Enabled a partial visible area remains behind. A screenshot will be illustrate this. We need a mode-transition cleanup pass when switching fog modes. implemented a new CleanupAfterShroud method called after every FOW change.
- fixed - UX - terrain - the terrain healing is now happening too quickly - about 5x faster than previous - since introducing chunking and specifically minimap chunking after which the FPS jumped from 120FPS to 600FPS+. Need to ensure delta time is being used correctly because this issue was previously fixed I thought but clearly has reappeared, need to review the terrainsystem.cs class file. Terrain now heals based on a core deltatime timer using realtime.
- added - FOW - implemented a tick restriction to prevent the FOW updating every single frame which is expensive, and it can now be set to a custom value, currently set to 30Hz while the game runs at 5000FPS.
- scrapped - chunking & batching & DOD - Patch tower targeting.
- done - chunking & batching & DOD - A full DOD layout for bullets.
- done - chunking & batching & DOD - A full DOD layout for bots.
- done - chunking & batching & DOD - A full DOD layout for stars.
- done - chunking & batching & DOD - A chunked fog system.
- done - chunking & batching & DOD - A chunked collision system.
- done - chunking & batching & DOD - Patch bot collision.
- done - chunking & batching & DOD - Patch bullet collision.
- done - chunking & batching & DOD - Patch placement collision.
- done - chunking & batching & DOD - Patch archertower and wall dragging.
- done - chunking & batching & DOD - Patch star pickup.
- done - chunking & batching & DOD - A chunked world architecture.
- done - chunking & batching & DOD - Chunk the minimap - this increased FPS from 120 to 650+ running at 3Hz same as other RTS games like C&C and RedAlert and StarCraft2.
- done - chunking & batching & DOD - A chunked bot AI system.
- done - chunking & batching & DOD - A renderer that only draws visible chunks.
- done - chunking & batching & DOD - Fog-of-war batching - Make fog updates instant.
- done - chunking & batching & DOD - revisit the Enabled and Self-healing FOW modes which currently only get 800-1000FPS while Shroud mode and FOW disabled yield 4500-5000FPS. FOW is clearly very expensive in the current unoptimized state. Batching for both systems was implemented just like for FOW Disabled and Shroud modes, FPS jumped to 2200FPS for both modes.
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.002.249) build 1091.
- done - UX - move the game version and build numbers from the Helpscreen to the Settings menu.
- done - sourcecode - rename the old pausemenuoverlay.cs class file to helpscreen.cs and adjust the project accordingly, now that the new settings menu is in place. This was a simple rename but I had anticipated namespace and other reference issues but Visual Studio handled it perfectly.
- fixed - collision - prevent dragged structures from leaving the world, currently placed structures can be moved beyond the limits of the world and archertowers will even continue shooting bullets from the void, this may be related to building dragging mouse cursor drift but should be fixable with a boundary check and return; guard if the dragged building touches the perimiter or limits of the world. It is important to note that the current placement system already prevents placing beyond the boundaries of the world so we just need to copy the existing logic or duplicate it. added a simple helper method to check for out of bounds and wired it in, all fixed.
- done - collision - if a bot is encircled by structures or simply in between two, and the structure is used to push the bot towards the other structure, the bot's collision logic does not kick in and it can be dragged on top of the other structure. there are two possible fixes to this using existing code and the simplest solution will be best - either ensure bot collision is always working and not just in motion, or apply the same logic used when placing a structure over a bot which pushes the bot out of it gently. adding a timer for idle bots forcing them to move or clip through a structure is not a good solution as it is likely far more complex involving yet another timer - simplify not complicate and do not over-engineer. this has been completed using existing gentle push logic for bots from the placement system when placing a new structure over the top of a bot, it was a little more complicated due to bots being DOD arrayed.
- done - performance - Chunk-aware bot rendering has been implemented. Instead of scanning all bots, we scan only bots in visible chunks. This involved registering bots to chunks when they are spawned, and the opposite when killed. Bots moving between chunks must also update the relevant chunks. done.
- done - performance - chunk register stars at spawn and remove from chunks when captured. This involved updating the starspawner class and star capturing logic for both bots and the player.
- done - performance - reviewed and verified the starpool DOD system to ensure it is fully chunk compatible. no changes were needed but some comments were added and code cleaned up.
- fixed - physics - dragged buildings should have collision detection with stars to prevent them from being dragged over a star, stars will eventually become minable minerals like tiberium or ore or gold and buildings cannot be placed over them which is already working currently so we cant have buildings being dragged over the same invalid location - existing stars. a dragged building should collide with a star and not be allowed to move over it, it should not use the same gentle-push logic when dragging over bots, it needs to use the legacy code that just prevents dragging over a star and employ the same exact logic as trying to drag an existing structure over another structure - they collide and cannot be put on top of each other. this was resolved as part of collision fixes for DOD array items and other entities such as bot vs bot collisions, and bot vs building, and building vs bot, and bot vs stars, and the placementsystem for newly deployed structures. quite a few iteration of the game engine but it appears to be working perfectly now after much testing.
- done - minimap rendering chunked and we jumped from 120FPS to 650FPS! OH MY GOD, the minimap updating the entire world every frame was the biggest bottleneck ever, 600FPS+ is insane.
- fixed - rendering - I made an archertower disappear and become invisible by dragging it off the screen then scrolling down to it, it continued to shoot bullets at me and I could grab it and drag it around with the spatial grid showing correctly, but the archertower itself was invisible. This issue can be reproduced by dragging an archertower offscreen to a valid world location but no longer visible on the viewport, then moving down, then dragging it down offscreen again and moving the player down again, it will suddenly vanish. ArcherTower's world-space position is no longer being updated correctly during dragging. The issue has been identified as applying screen-space deltas as if they were world-space deltas in dragsystem.cs. The exact cause of the disappearing ArcherTower has been identified, it's not in the renderer, not in the minimap, not in the chunk system, not in SDL, not in the camera, not in the collision system, it is in the building.cs class - related to a bounds floarect variable using worldposition. resolved by adding the same code for moving buildings and walls as we already did for bullets and bots that go offscreen and become part of the new chunked world where not everything is rendered and computed anymore, walls and buildings were simply overlooked but clearly caused an issue only because the game runs in windowed mode allowing the mouse the drag them well beyond the perimiter of the world, this will not be an issue in fullscreen mode but definitely good to fix now and future proof.
- done - UX - resolved static and idle bots when they are far away and offscreen now that chunking has been introduced, increased the spatial grid size from 3x3 to 5x5 which resolved offscreen bots from not collecting stars, the world is alive with motion now on the minimap.
- fixed - UX - modified the fog of war mode popup from using simulation deltatime to using a real time stopwatch so the popup appears for 2 seconds regardless of the FPS of the game, this will ensure all players have the same user experience.
- done - UX - implement a dual-radius perception model for the spatial grid so that onscreen units use a smaller tigher spatial grid for targeting and so on, while offscreen units have a larger grid since otherwise they will likely just stand still idle, and since the spatial grid checks are cheap it is no problem to make it larger to keep the world via the minimap alive and moving. A new radius variable is now passed from botmovementsystem or bottargettingsystem which defines the size of the spatial grid.
- fixed - gameplay - another new issue post chunking implementation, after a while all the bots clump together, and the declumping logic we implemented does not work when bots are not in an "active chunk" and so the bots essentially take up just a couple of places in the world and stand idle - if I move the view screen to their location they suddenly all de-clump and 30 bots come out of a single location as they declump. offscreen bots need to fallback to a global star search just like onscreen bots do as otherwise the world eventually ends up dead and not moving. added coarse declumping logic for offscreen bots and it appears to be working well with a scenario of 50 bots collecting a max of 500 stars - this is extreme for RTS games, overkill for RPG games, and not applicable to side scrollers so this is working well and will be fine tuned when the 100 levels of Ai behaviour are implemented for bots to further enhance them and their abilities.
- fixed - minimap rendering was showing a black grid at certain world tile size resolutions, this was related to integers being rounded and they have been replaced with rectangles to resolve this issue, any tile size can now be set without this black grid appearing on the minimap.
- done - performance - make buildings chunk aware, buildings are static and do not move or update every frame so they do not need to be DOD but making them chunk-aware will still improve performance and FPS. this was completed along with walls and created numerous issues all of which have since been resolved through much bug fixing and troubleshooting.
- done - performance - make walls chunk aware, walls are static and do not move or update every frame so they do not need to be DOD but making them chunk-aware will still improve performance and FPS. this was completed along with buildings and created numerous issues all of which have since been resolved through much bug fixing and troubleshooting.
=====================================================================
(NEXT ENTRY 2026 May)
this is source control save (0.000.002.244) build 979.
- fixed - stability - issue reoccured - minor freeze occurs at every single game launch when the first star is captured, ie the first audio sound file is played and JIT has not yet warmed up causing a 200ms freeze which I thought was resolved but appears to have started happening again, we simply need to play a sound during the new loading screen, which will be unnoticable, to warm up the audio system and JIT to prevent the freeze permanently. an audio warmup method has been added to soundmanager and is called during the loading screen to play a random sound file at zero volume which warms up JIT and the freeze is permanently gone.
- added - pause menu - add pause game menu with features like New Game, Resume, Settings, Help, and Quit. done! and it dims the game in the background when paused, the buttons are minimalistic and modern and fully functional, they just need to be wired in to new coming soon features.
- fixed - stability - game freezing since resolving the worker thread jobsystem bug. *** use VS debug "break all" to identify the cause! *** - this has not happened in weeks, the two recent fixes have clearly worked, they are both fully documented.
- done - UI - make the quit button work in the pause menu. works perfectly.
- done - UI - fine tuned the new pause menu including adjusting the help menu which was the previous pausemenuoverlay and adjusting text size font and x,y,width,height values to align everything nicely with respect to the paused dimmed game in the background, copilot already got this 99% perfect, I just tweaked it a little.
=====================================================================
(NEXT ENTRY 2026 April)
this is source control save (0.000.002.240) build 963.
- fixed - sourcecode - move minimaprenderer.cs from gamesystems namespace to rendering namespace, a simple move causes 27 compiler errors despite the corrected file level namespace in the file. starpool.cs should also be moved from gamesystems to gameobjects. done and 160+ compilation errors resolved. legacy code cleanup sorted.
- fixed - collisions - prevent the player from getting stuck when it is rubbing up against a structure, currently it feels like the WASD buttons are somewhat paralyzed and prevent smooth motion when the player is against a structure, I suspect the collision system is the culprit that needs fine tuning. a single line of original code was converted to a small chunk adding logic using math to prevent the paralyzing behaviour, this code prevents the player from getting stuck against the side of a structure, but introduces mouse cursor drift when pushing the player around with a structure while dragging it, however this behaviour of pushing the player around by an archertower or wall is not normal in most games and 2D genres, and structures will likely not be draggable eventually since RTS and RPG games dont have such a need, doesn't make sense. this is done.
- fixed - collisions - prevent the player from getting stuck when it is rubbing up against an impassable terrain tile such as water or void, same issue as the previous item for getting stuck or paralyzed on structures, and as a result of troubleshooting this second item we discovered and removed redundant collision logic inside the player class, it has been deleted and as a bonus fixes two collision systems fighting against each other. this is done.
- done - visuals - add a grid overlay to structures being dragged exactly the same as new buildings being placed works and introduce the same collisions and driveway system to completely mimic the current building placement system for existing structures being dragged around. simply duplicated the same code already used for showing the grid during structure placement. there was no need to include the green orange red ghost system or modify anything else like snap-to-grid via the shift button since structure dragging will likely be a removed feature eventually, but it is fun for now.
- scrapped - gameplay - remove the new debug output command prompt window that appears along with the game when the game is launched either via Visual Studio or directly via the executable, only remove it when the game is launched via the exe. this never happened before, appears to be a .net8.0 VS project related. this is a non-issue because I am using debug mode and building the game in debug mode, can modify the .csproj file and change Exe to WinExe, or just build the game as a release version.
- done - gameplay - add a custom icon to the .exe - the icon is already present on the shortcut file for the exe - the icon is located in "Resources\GameIcons\myfourthgame.ico". the icon has been embedded into the csproj file and immediately appears on the exe.
- scrapped - visual studio - add GPU counters to Visual Studio's Diagnostic Tools in addition to memory and CPU utilization, so that I can monitor GPU utilization now that SDL2 hardware rendering is finally in place. I have checked all the settings on the Diagnostic Tools pane and it appears to only support cpu usage, .net counters, and memory usage. VS does not support gpu utilization unless using directX11/12 etc - that's a future state.
- scrapped - bot star targetting - once the bot advanced targeting is working for individual bots, make those dictionary lists public and allow other bots to access them and as a first step - get a bot targeting a star that`s already targeted by another bot, to retarget immediately. this is irrelevant now that the future goal for stars is to become collectibles or minerals or tiberium etc and harvesters and other units collecting this stuff should not need to retarget if something else has targeted, instead it should be a race to who gets there first. plus, the legacy dictionary lists have been removed.
- scrapped - performance - implement caching for EVERYTHING - go file by file with anything that is loaded, prevent anything other than game elements like player and bot movement and star generation and similar concepts from updating in realtime unless they need to, and force everything else to cache and update only once per second and not once every frame, use existing delta time logic without introducing more timers to the game engine. Rendering + collision + spatial grid + fog of war + tile loops + minimap are the current FPS bottlenecks based on plenty of troubleshooting and analysis, these were addressed in phases 3-5 of the botcollector DOD migration. Caching "everything" would not meaningfully improve FPS because the expensive systems are not cacheable.
- added - version and build number to the pause menu.
- added - game UX - add a game starting loading screen with a splash screen and loading bar exactly like Factorio, but for now faked since the game loads immediately so add a 2-3 second sleep while keeping the loading bar doing its thing over those 2-3 seconds from 0-100%. we need a loading screen architecture, game phase enum, loading update state machine, a renderer call for the splash and loading bar, and temporarily faked loading steps for that polished and professional user experience and a clean transition into the game - loadin screen -> fade out -> pause menu (simply press ESC to start a new game!).
- regarding faking the loading if the game loads instantly - apparently many games and engines did this early on including Factorio, Minecraft, StarCraft 2, and according to copilot all AAA engines do this at least only early on, when loading graphics and sprites into memory is minimal.
- fixed - the loading screen was appearing for only a split second, it now "loads" elements for about 2.5 seconds and looks epic, very much like early days minecraft.
- fixed - stability - solved and fixed - investigate the minor freeze that occurs at every single game launch startup about 3 or 4 seconds after launching the game, the previous debug code which is now removed showed a 200ms pause in the main thread and in the botcollector class so perhaps related to DOD array generation. it happens every time, it is not intermittent, it happens once only - a few seconds after startup and after 5 or 6 bots have already spawned, perhaps it is star capturing related, it never happens again until the game is closed and restarted. the issue has been isolated to playing the very first sound file - details in the fun facts. it will be resolved with a loading screen that plays a sound file to warm up the audio and JIT systems. fixed - playing an audio sound file was not even necessary after implementing the loading screen and changing the loading behaviour of all the systems and subsystems, the 200ms freeze is gone.
- fixed - gameplay - all the function keys are no longer working after implementing the new loading screen when the game launches. The function keys stopped working because the new loading-screen phase caused EngineTick to return early, so the F-key handlers were never reached. copilot fixed it by moving the F-key logic above the pause/phase gating so they always execute regardless of game state.
=====================================================================
(NEXT ENTRY 2026 April)
this is source control save (0.000.002.237) build 935.
- done - gameplay - when cancelling a structure placement deployment with the mouse RMB a crater also occurs now, we need a return logic to prevent craters occuring on the terrain if the user is attempting to deploy a structure like an archertower or wall. added a simple break; guard during structure placement in sdlwindowhost.
- done - gameplay - add a fourth fog of war toggle to F7 button - a shroud, so that explored terrain remains fully visible indefinitely, this should be the initial and default setting just like in the C&C game. we basically need to duplicate the existing initial (default) fog of war and disable the feature that only renders objects in the player's line of sight and visibility range so that any explored terrain remains completely visible indefinitely - and so that means if the entire world is explored by the player then the fog of war is effectively removed - classic C&C RTS style. this was a couple of hours of work and troubleshooting the rendering system including the minimap to ensure all entities - bots, stars, terrain, destroyed terrain, archertowers, walls, bullets, the player, is all rendering in all four FoW modes. the new Shroud system is epic and feels so familiar - I was obsessed with C&C for decades. Some fine tuning remains but the system is working perfectly.
- done - rendering - reduce the size of the player's visibility range significantly, after playing C&C remastered recently I noted that each unit and tank can only see a short distance in front of them, it's a bit extreme, and my game engine is at the other extreme - the player should see half the distance it currently does.
- done - rendering - make the fog of war "shroud" mode remember explored terrain - currently if I switch to enabled fog of war with self healing and it heals the fog of war, and then switch back to shroud mode the self healed terrain is back to being an unexplored shroud. the solution is to modify the Enabled with Self Healing FoW mode to only heal the terrain if the mode is active and not just always, this will improve game performance in the other 3 FoW modes and avoid introducing more code and complexity such as new DOD arrays to achieve the same result. the FoW healing only occurs while the self healing FoW mode is active, this required changes to the fogofwarsystem class file.
- done - visuals - the green/orange/red ghost sprite for buildings being placed needs to be transparent a bit as currently it is just a tint on the actual structure sprite.
- done - visuals - add a fog of war mode notification popup in the same style as the FPS counter (which is enabled with the F11 button) but instead for the Fog of War system cycled with F7 button which pops up in the center of the screen, in transparent white text for 2 seconds to outline which fog of war mode has been selected and enabled every time F7 is pressed. this involved a new file fpgmodepopup.cs and using the SDL text renderer, no challenge for copilot and working perfectly after some basic troubleshooting, it looks very fancy and professional, and with 4 FoW modes to cycle through it is absolutely critical to notify the user with some kind of toast notification or temporary popup.
- scrapped - game system - prevent the game from pausing when the window is clicked and held or dragged, not sure if this is possible, the next option is to force the game to only be full screen but not everybody likes full screen mode as they like to watch movies and multitask as they play games that are intended to be full screen only, so windowed mode must remain but it should not freeze the game when the window is locked - or perhaps this is normal behaviour? I don't actually know, I never play games in windowed mode. this change was something I noticed but it seems it is unnecessary and would introduce complexity for no reason at all especially for the single reason - who wants the game to continue when they are repositioning the window around their giant widescreen monitor - it should pause, this is normal and not a bug. scrapped.
- fixed - gameplay - mystery bot being spawned - A strange "mystery bot" began appearing at the same spot near the player on every game launch, even though BotCollectors are supposed to spawn at random locations. Dumping the bot pool showed no bot ever spawning near the player's starting position, and commenting out every reference to SpawnBot() had no effect. The bot wasn't a ghost - it respected the MaxBots count value, it targeted stars and moved normally and behaved like a legitimate entity. After deeper debugging, we discovered it wasn't being spawned there at all but was being teleported to (15,15) immediately after creation due to a race condition in the multithreaded BotMovementSystem: movement jobs were scheduled but not awaited, so newly spawned bots read uninitialized _nextX/_nextY values of (0,0), causing the grid to snap them into the nearest valid cell. This same race condition is a strong candidate for the intermittent startup freezing observed since the DOD migration and JobSystem implementation. Converting BotMovementSystem.Update() to a single-threaded implementation fixes the issue, stabilizes the engine, and has negligible performance impact because bot movement is cheap.
=====================================================================
(NEXT ENTRY 2026 April)
this is source control save (0.000.002.233) build 919.
- added - jobsystem - Clean Shutdown for multithreaded batch job - Adds: , _running flag, Shutdown() method, Worker threads exit cleanly, Debugger stops instantly, No thread leaks. This is a tiny change but essential for long-running sessions and hot reloads. done.
- added - jobsystem - Replace AutoResetEvent with SemaphoreSlim, just a few lines of code - AutoResetEvent wakes one worker at a time, SemaphoreSlim wakes as many workers as needed, Massive improvement when scheduling many jobs quickly, Reduces latency, Improves throughput under load. This is the biggest performance win inside the JobSystem itself. done.
- added - jobsystem - Add ScheduleRange helper - This is ergonomic but also prevents mistakes when chunking arrays. Cleaner, safer, and avoids capturing loop variables incorrectly. done.
- fixed - performance - cpu multithreading was running twice in a nested manner for bot movement since we introduced jobification to core.cs class and then added a new jobsystem.cs class but looks like we didn't clean up the code in core. fixed.
- done - all bot movement and targeting rewritten to DOD arrays, no observable performance gain but I now know the bottlenecks and these were not one of them. phase 3 of 5 of bot DOD migration completed.
- done - with phase 4 of the bot DOD migration the game engine just crossed the finish line of one of the most painful migrations an engine can go through - ripping out System.Drawing, replacing it with a fully GPU-safe, renderer-agnostic pipeline, and doing it without breaking a single subsystem.
- done - phase 5 mostly skipped but completed (text GPU rendering - already being mostly done by SDL2 anyway), fully stable and functional game version, next step is fixing the 300 current issues/todo items/future ideas before continuing on with phase 6,7,8 which are now phases 1,2,3 of a new future roadmap.
- fixed - removed a redundant botspawn call from botsystem trymeleekill which could de-stabilize the game and DOD arrays since bots are spawned from the core.enginetick method and shouldn't be called from anywhere else.D
- done - new 8 phase roadmap underway : "MIGRATE BOTCOLLECTORS TO DOD AND OPTIMIZE THE GAME ENGINE AND ALL LOGIC WITH PERFORMANCE AND SCALABILITY AS THE PRIMARY FOCUS". (was 5 phases but now 8). a week or two of work to achieve this, no FPS gain but the game supposedly runs better now fully multithreaded and all non-brain non-Ai bot behaviour is configured as super efficient DOD arrays, a lot of troubleshooting and bug fixing went into accomplishing this migration.
- done - collision - structures being placed can be positioned over bots and stars, the bot collision issue is new because we only recently have idle bots now due to enhanced star targeting code with spatial awareness and global search fallback methods, however the good news is that currently if a structure is placed over a bot the collision then kicks in and pushes the bot to the right which is great, but we should turn the structure placement ghost red and prevent over the top placement although as I write this I remember this being an annoying issue in games like C&C where if I wanted to place a turret in my base but my army was taking up the space, I first had to move a dozen units around before I could place the turret, so perhaps the way the system is now is ok-ish but the push should be gradual and not an instant teleportation which is unnatural. and, placing over stars is probably something we should also fix since stars will eventually become harvestable resources or fields like ore or tiberium or gold etc so unless the building is an extractor like in Factorio or Dyson Sphere Project where it needs to be placed over the mineral being extracted, then it should be prevented. structures being placed over bots now appear with a orange placement ghost if a bot is within the placement location. structure placement is no longer allowed over stars (future collectible minable resources), the placement ghost turns red.
- fixed - targeting - I suspect bots are still chasing distant non-existent stars when falling back to global search from the nearby spatial awareness search, I saw a bot flying across the world to a distant star and its trajectory did not show anything but it could have been further away than I checked and it did re-evaluate eventually when a closer star appeared, this is with a 3x3 spatial grid, 300 bots, 20000 stars. bots stop now if the player captures a star they had targeted, we fixed this, but perhaps if a bot captures that star the improvement code is still missing and the DOD array is not fully updated or properly and the bot is chasing a ghost star. this is fixed by adding a few lines of code the player recently had added when it captures a star to correctly remove it from the pool which bot star capture code was missing.
- done - movement - implement existing bot de-clumping logic to idle bots so they disperse when they all come together and stop over the top of each other, de-clumping seems to only work when they are in motion. one line of code added to idle bot logic and all fixed, a call to the same declumping method used while they are moving.
- obsolete - collisions - units should never overlap each other, it is just un-natural and does not look like a professionaly made game. bots already now have a declumping method which works great and is fun to watch, but it still allows bots to overlap in the first place, bot collisions need to prevent overlap completely - every bot is an individual and they should clump together like a swarm and similar to how starcraft2 does it, but never be on top of each other, the declumping method can be retired once this is achieved. However I also noticed that in starcraft2 an army will be bouncing around against each other when targeting a nearby building to attack and there's no more room for the units in the back to get into firing proximity, they just stay in the back bouncing around instead of being smart and finding another angle and position to move to and fire from, this is where Ai Wars will shine, this is key to how armies or groups of troops will behave with advanced pathfinding and Ai logic. De-clumping logic has been implemented to both moving and idle bots and it is far better than most RTS games, there's no need to improve clumping any further. Even starcraft2 allows complete overlap for air units and intentionally, so leaving this as is now.
- fixed - collisions - we resolved idle bots not being subject to collisions with archertowers trying to push them around, but I have now discovered that bots stuck on a tile or structure preventing them from moving onward are also ignoring being pushed around by archer towers. this has been resolved as a result of other collision code repair and I can no longer reproduce this issue easily - I think it is still an issue but that will be something modders can have fun with, it does not affect gameplay at all.
- scrapped - visuals - if moving around the world fast and destroying the terrain with bombs to create craters and while the player is causing edge scrolling there is some new earthquake-shudder effect happening which is kind of cool but we need to identify the cause and potentially code a new earthquake effect from it or eliminate it entirely if it is in fact some kind of camera.position being overwritten twice per frame issue or Camera.PreviousPosition and Camera.CurrentPosition are not being updated consistently, or the camera scroll logic is producing tiny oscillations, or the camera clamp is firing every frame, or the camera uses integer rounding somewhere. this is not easy to reproduce and likely resolved due to other recent improvements, if it becomes an issue in future I will investigate then.
- scrapped - visuals - there's some new minimap rts mode click glitch where the viewport almost duplicates and it glitches between two parts of the world when not moving the player and just clicking around the minimap, this started only after migrating botcollectors to DOD which we are still midway through. I can't reproduce this but recall it wasn't really a big problem, will fix if it resurfaces.
- obsolete - graphics - VSYNC was disabled as part of troubleshooting the low FPS bottleneck - SDL_RENDERER_PRESENTVSYNC was removed - revisit whether vsync should be re-enabled or not - apparently vsync forces a 60FPS frame rate so perhaps it is not needed since I don't think I need to worry about screen tare with my game engine but I need to revisit and re-evaluate this. this is redundant and obsolete now that the true cause of the FPS cap has been identified - the minecraft-style voxel terrain and worldsize combo.
- fixed - performance - as part of eliminating the very intermittent game freezing issue that happens at startup, introduced a new LOADING phase for the various sub-systems to prevent too much from occuring simultaneously especially now that CPU multithreading has been implemented for various systems, a simple return occurs if the loading phase is not complete preventing the game from executing too much at once. I suspect we need to fine tune this and implement sleeps or waits which will cause longer load times but should in theory, my theory, introduce additional startup stability.
- done - decrease the terrain self healing time significantly. this is a simple multiplier based on the FPS currently, this is bad however remediating this is part of the current terrain optimization and simplification roadmap and a timer or deltatime will be introduced to replace FPS.
- done - collision - unless the player or bot perfectly align with the star's coordinates it does not get captured giving the illusion of stars remaining forever when in fact the bot or player simply missed the collision despite clearly touching the star. this was a false positive and a result of stress testing the game engine by forcing instant star spawning 0.001 and 10000 max stars, and 500 bots, and a small world causing the system to overload - it is not a real world scenario and I simply pushed the parameters well beyond their natural limits. decreasing the stars from 10000 to 1000 resolved everything so that proves the logic and collision and capture methods are all fine.
- done - collision - stress testing the code to identify the intermittent game freezing, made the world very small 120x120 tiles at 16 pixels per tile, and added 500 bots and 10000 max stars, and a star spawn rate of almost instant at 0.01 and with so many stars in play, bots are rolling over stars and the collision logic is not capturing them, they just remain in the world and bots only capture stars they have targeted and moved to ignoring every star they just steamrolled over which should not happen - any star they collide with should be captured. same as previous item - this was a false positive and a result of stress testing the game engine by forcing instant star spawning 0.001 and 10000 max stars, and 500 bots, and a small world causing the system to overload - it is not a real world scenario and I simply pushed the parameters well beyond their natural limits. decreasing the stars from 10000 to 1000 resolved everything so that proves the logic and collision and capture methods are all fine.
- fixed - minimap - the minimap suddenly has rendered a square grid pattern over the entire minimap - it is interlaced vertically and horizontally and this only happened because I changed the world size to be dramatically smaller - so there's something wrong with the minimap logic. fixed - two anti-aliasing fixes applied: Rounded pixel coordinates, and Minimum tile size of 2px.
- fixed minimap - the minimap is see through suddenly or maybe has been all along, I can now see the terrain and stars being rendered behind the minimap scaled down version of the world. this cannot be good, the minimap should be a scaled down replica of the world and not show what is behind it in the viewport view. related to previous item - fixed - two anti-aliasing fixes applied: Rounded pixel coordinates, and Minimum tile size of 2px.
- obsolete - collision - the new bot push system which pushes bots gently over a second when a building is placed on top of them makes them able to clip any other structure for that second, we need to stop the scheduler or timer that allows this clipping as soon as the bot is pushed outside the boundary or perimiter of the placed structure, if there are a dozen structures and a new one is placed on top of the bot then it can clip straight through the other structures, this is bad. and solving this will likely solve the related issue I logged the other day. this and the next item are non issues, a bot cannot be pushed beyond the perimiter or limits of the game area and any attempts to do so by trapping it and pushing it out end up with the bot being pushed inwards and if there are a dozen archertowers all adjacent together then the bot does not clip through all of them it just ends up on the next one and stuck and if that structure is moved the bot is clipped one building further until it is finally released and free again.
- fixed - collision - if a bot is encircled by structures, and a structure is placed on top of it, which is currently permitted and using the new orange placement ghost tint system, the bot is pushed out gently so that if a building or defensive structure needs to be placed in a busy area such as the middle of a base with dozens of units occupying the target deployment space, the units in that area are gently pushed aside, this is working well and fine, however, this creates a new potential issue that someone like Josh from Let's Game It Out youtube channel could exploit this and surround a bot with hundreds or thousands of walls or structures and force a bot out of bounds, we need to ensure a bot can never leave the perimeter of the world and if they are close to it they need to be pushed in the opposite direction or perhaps just evaporate and disappear into the nether - this is not behaviour typical gamers will do so the solution does not have to be typical either, it can be a little crazy, or we can just push the bot to the closest valid in-world coordinates using a snap teleport method. this and the previous item are non issues, a bot cannot be pushed beyond the perimiter or limits of the game area and any attempts to do so by trapping it and pushing it out end up with the bot being pushed inwards and if there are a dozen archertowers all adjacent together then the bot does not clip through all of them it just ends up on the next one and stuck and if that structure is moved the bot is clipped one building further until it is finally released and free again.
- fixed - inputs - LMB and RMB clicks on the world while the game is paused caused terrain destruction and craters after the game is unpaused, this was noticed when the pause overlay was still broken and not loading when the game is paused, but could occur once the overlay rendering is resolved, need to ensure mouse clicks are only handled by the pause menu and settings overlay and not in the game itself while it is paused. A simple return logic inside SDLWindowHost.cs prevents LMB and RMB from affecting the game, those clicks are still handled and so clicking the pause menu settings will still work without further code changes once a pause menu actually exists.
- fixed - building placement - while placing a new structure, and the red/green ghost is visible and locked to the mouse cursor, if I click-hold an existing already deployed structure I can drag it around while the new structure ghost is still stuck on the mouse cursor. dragging existing structures should be blocked with a return; line of code if a building is currently being placed and a ghost is attached to the mouse cursor. A simple mouse click consumed logic line was added to SDLWindowHost.
- fixed - minimap - LMB and RMB mouse clicks on the minimap should have no effect on the world and not behind the minimap which currently happens, currently if the minimap is clicked with LMB or RMB the terrain directly behind the minimap is effected. LMB and RMB clicks on the minimap should consume the click and only travel to those coordinates with no world effect. SDLWindowHost.cs has been amended with several code changes.
- fixed - building placement - adjust building placement collisions to allow placement directly next to walls but not any other structure. A basic change to the check wall collisions code in the placementsystem.cs file now allows placing archertowers directly next to existing walls.
- fixed - terrain - the terrain sublayer slowdown effect on both player and botcollectors has become a little more dramatic now with the new hardware accelerated SDL2 rendering system, need to fine tune the slowdown percentages and base it on a real clock and not FPS. the slowdown effect is a simple float value adjustment for the variable LayerSlowdown in terraincollision.cs.
- fixed - mouse drift - fix the mouse drift that happens when the minimap is clicked and held down and dragged around to explore the world, the mouse cursor moves away from the viewport rectangle. the mouse cursor needs to be locked inside the minimap while the LMB is held down or if that's not possible then minimap viewing should be stopped if the mouse cursor leaves the minimap preventing any minimap scrolling. this has been resolved by modifying the DragDelta method within minimapcontroller.cs to include mouse cursor clamping.
- fixed - visuals - the player is wobbling again at times, not always but it definitely happens under some circumstances, we previously fixed both player and stars wobbling but it has returned or I didn't realise it remained as an intermittent issue - my previous notes (star wobbling redacted): "the player wobble but botcollectors do not, they are perfect while stationery and idle. copilot analysed core.cs my primary main loop file and confirmed: "The wobble is 100% coming from the camera interpolation being applied twice.". interpolation was being applied twice! causing the player and star positions to change ever so slightly based on the camera location. wobbling is now fixed." we need to revisit the player wobble again. we added debug logging to the player's coordinates and confirmed they were stable, which proved the wobble wasn't coming from simulation or interpolation at all - it was caused entirely by the world-to-screen transform returning fractional pixel positions, so we fixed it by snapping the camera's screen-space output to integer-aligned coordinates.
- fixed - terrain - since decreasing the number of minecraft-style voxel terrain sublayers from 7 to 3 had no effect on the performance or FPS, consider increasing it back up to 5 or 7 and allow this configuration to be set in settings.cs class with options to completely disable it or specify the number of layers generated at runtime. 7 subterrain layers have been re-implemented along with unit slowdown logic and terrain healing logic.
- fixed - stability - the game is intermittently freezing (primarily on startup) since the bot DOD migration and CPU multithreading implementation work and since completing the 5 bot to DOD migration phases, the game window goes grey and the title bar shows "not responding" - very typical of an app freezing up but this is a new thing I have not seen in the 15 months I have been working on it. The issue is hard to reproduce but has happened a dozen or more times recently. Watchdog code was added to help identify the rootcause but it didn't help, what worked was me telling copilot to stop guessing and tell me if visual studio can help identify the freezing and of course yes it could and did - we identified a single line of code being called by a worker process causing a deadlock since only the main thread should call this line of code related to the new multithreading jobsystem. full details are very lengthy and in the fun facts section for this date - 25th April 2026.
- fixed - stability - trying to resolve the new intermittent K button issue which is not killing bots when it should, it takes 3 or 5 attempts to kill a bot that is in proximity and the trymeleekill method should execute and kill that bot but after adding much debug logging I have confirmed the K button press is registered and handled every single time and every single frame, this also goes for every other keyboard button press - F5 F6 F7 F11 toggles all work perfectly every single time and I've stress tested my keyboard to ensure it is not faulty, it isn't, so with mode debug logging added I can now see the K button is registered and handled by InputManager and SDL but the botsystem.cs trymeleekill method only executes once every 1-4 times and not every single time K is pressed. so killing bots is no longer working perfectly but WASD and all FUNCTION buttons and spacebar and ESC all work perfectly - what is it about K? it's clearly not hardware, i can spam KKKKKKKKKKKKKKKKKKKKKKK perfectly, its something dropping the ball somewhere, something frame related that is likely beyond my understanding. fixed, again just a single line of code was incorrect, details in the fun facts.
=====================================================================
(NEXT ENTRY 2026 April)
this is source control save (0.000.002.223) build 848.
- added - add a frame route counter showing FPS with the F11 button to toggle it ON and OFF, currently the game is running at 5000+ FPS and we need to cap it at 200 FPS but I need a method to prove and verify the cap has worked. F11 now toggles the FPS counter.
- fixed - the mystery botcollector image appearing at coordinates 0,0 as a blue meanie image but completely static and not subject to collisions, just an image. this was a redundant line in the botcollector constructor that caused the botcollector DOD pool to be incremented before any real bot existed.
- fixed - visuals - the pause menu overlay is a single line of text since switching from GDI+ DrawString using \n for newlines over to google from roboto_mono regular font, add line breaks. modified the custom DrawText code to include and handle \n line breaks.
- fixed - a tonne of small bugs and performance issues related to the ongoing botcollector (agent) migration from OOP to DOD to vastly improve performance and simplify the logic. this is massive work as botcollector class is my largest file coming in at 50K characters and 1000 lines of code.
- fixed - bot killing with the K button stopped working after migrating bots from OOP to a DOD pool, their world coordinates were no longer being calculated correctly by the trymeleekill method and were not being correctly exposed in the botcollector class. added some debuging and found the cause - The DOD migration broke the facade's position.
- added - a new gameplay demo video added to my MyFriendlyITGuy youtube channel showing the basics of the game and what it already does and advertising my new company and web domain name my4thgame.com.
- done - GDI+ rendering is now completely gone with DrawString removed and SDL2renderer class updated.
- added - performance - a bot spatial awareness system has been implemented to improve performance, bots will no longer scan the entire world for the next closest star which is very CPU heavy, and instead scan their local area or neighbourhood first, if there is no star in their direct vicinity they will wait for X seconds (3 but configurable) before falling back to a cpu heavy global scan. this will improve bot efficiency massively.
- fixed - collisions - bot collisions with archertowers have been only half working all this time, perhaps only since DOD migrations or worldspace coordinates changes, but with the new spatial grid system in place bots now actually stop moving if there's no nearby star, this is good, but I noticed they lost collisions with archertowers while stationery, an archertower being dragged collides with moving bots but clips straight through them if they are stopped. we introduced syncing the new DOD bot facade coordinates after movement to resolve this.
- fixed - collisions - bots being pushed around by an archertower works well while moving up and down, but attempting to push a bot left or right forces the bot to jump to a corner. fixed - logs prove: Collision resolution is choosing the wrong axis when overlaps are similar, this causes vertical pushes during horizontal collisions, that produces the "snap to corner" behaviour, the fix is to use a minimum translation vector (MTV) approach.
- fixed - movement - bots are now using the new spatial grid system to search only for nearby stars however they fallback to a global search after X seconds (currently 3) to search the world if there are no nearby stars, when they use the fallback method they only move for a moment then stop again, they need to lock in that star and move to it as normal but ofcourse continue to re-evaluate their situation and retarget if a closer star appears in their direct vicinity or neighbour or spatial grid area. this was only identified after I reduced the total number of bots to 1 and max stars to just 2.
- fixed - targeting - bot star targeting logic is broken after fixing the movement bug, the global fallback is working only intermittently it seems, some bots will stay in one place indefinitely and if I push them with an archertower towards a nearby star they will capture it, its actually not intermittent, it is odd, I only noticed this after increasing the number of bots from 1 back to 30, it seems like they have a hive mind now and all move simultaneously when one of them finds a spatially nearby star. they are all sharing the same timer is the likely cause. the timer has been migrated to DOD array one per bot instance and a number of other code improvements and tweaks including timing values were adjusted and the game is working perfectly, bots pause for a moment while "thinking" or deciding upon their next target, this is perfect and deliberate and easily removed giving smooth decision making movement but I don't want that for baby level 1 bots, maybe level 50 bots but for now this is perfect until I start throttling their behaviour to allow them to level up.
- fixed - performance - with phase 2 of the BOT to DOD migration completed, I can now run 500 max bots with 50,000 max stars and the game engine doesn't even flinch rendering everything smoothly at 70 FPS, just a week ago the game was grinding to a 2FPS halt with just 200 bots and 2000 max stars. this is incredible, however this works very well UNTIL there are so many bots that they capture all the stars which are now spawning every 0.01 seconds and they completely extinguish the star supply, when this happened the game suddenly dropped to 4FPS - need to fix this as it could have just revealed an underlying architectural issue. This is apparently caused simply by the fact that with 500 bots and zero available stars nearby (the map is empty of stars) all these bots are falling back to the O(N) global star search method which is very CPU expensive. With 50,000 stars, this becomes: 500 bots × 50,000 star checks, 25,000,000 rectangle checks per frame, at 60 FPS -> 1.5 billion checks per second. That's the 3 FPS right there. We added a reset on the fallback timer to force it to start over when it lapses, and modified some basic behaviour changes including reducing the spatial awareness grid from 5x5 to 3x3 for bots so they identify nearby stars only in a much closer proximity, and now I can easily have 500 bots chasing 50K stars with half the world terrain destroyed from RMB terrain bombs and the FPS is holding steady at ~60 FPS, just incredible, and I left the game running for 20minutes with no issues, no crashing, no CPU spikes, no FPS drops, and the bots were either idle if no stars nearby, or would move to a distant star once their 3 second fallback timer lapsed, and would move in declumped groups without overlapping each other (for too long), and the audio and sound fx worked perfectly, wow. this is now a very stable platform based on highly developed and evolved architecture, all thanks to copilot's ingenuity and my analytical and troubleshooting skills and my ability to identify issues and either explain them to copilot for adding advanced debugging logging or to narrow down the root cause possibilities of bugs. the last remaining bottleneck preventing the FPS from soaring to 200+ from the current ~70 is apparently rendering, now StarCraft2 solved this by implementing a shroud system and only rendering what is visible significantly reducing CPU and GPU load, but my game engine still currently renders everything regardless of which Fog of War toggle is enabled - we will fine tune this later and improve FPS even more, but for now we need to complete phases 3 through 5 of the Bot DOD migration.
- obsolete - performance - it seems Text rendering using DrawString is killing my FPS, we disabled VSYNC and disabled all rendering except for the FPS counter and the game runs only at 600FPS, it should be 6000FPS, the FPS counter itself is killing the frame rate, with all rendering enabled the FPS is around 50-60 FPS, it should be much much higher however the game despite its simplistic look is in fact doing a lot now and everything except text rendering is GPU based, text rendering is still using GDI+ rendering (which the file gdiplusrenderer.cs is deleted but the fallback by default is GDI+ still, somehow, by using "new Bitmap" and "Graphics.FromImage(...)" and "g.DrawString(...)" and TextRenderingHint and Bitmap.LockBits and PixelFormat.Format32bppArgb etc). We are going to cache text rendering which is the last system to be migrated from CPU rendering over to GPU. We will replace GDI+'s DrawString with SDL_ttf (and not a bitmap atlas) to kill GDI+ permanently from my project. We have switched text to SDL rendering but I need to verify if text caching is now enabled or not as the rendering switch had no impact at all, something else is capping my fps at 50-60 whereas with rendering disabled its 500-600fps. Resolving the frame rate bottleneck has turned into days of effort, all details in the fun facts section, this will be a brief only but long story short, botcollector movment is the massive bottleneck compared to all other logic including star targeting and capture, declumping logic, and collision logic. With 300 bots and 20,000 stars in play once all the bots have spawned there are almost no stars visible, they're all cleaned up, but there's so many bots the FPS drops to 5 or 6, from a steady 72 with 30 bots and 200 max stars. and with so many bots in play, 300, Rendering is also a massive bottleneck now, ten times bigger than bot movement logic, the renderer is the thing that collapses at scale.
- this is now obsolete and completely fixed and no longer valid. We've eliminated: GDI+ text rendering, Per-frame SDL_ttf rasterization, Per-frame texture creation, The fallback global-scan meltdown, The synchronized bot swarm, The renderer bottleneck caused by CPU-side text, The bot movement bottleneck, The star-targeting bottleneck, The collision bottleneck. The game engine is now running 500 bots + 50,000 stars at 60-70 FPS for 20+ minutes with: terrain destruction, terrain healing, SpatialGrid, targeting, collision, rendering, audio, UI, all active. That is a different engine from the one described in the old note.
- fixed - CPU multithreading is implemented and after many crashes related to simultaneous array writes since the game is mostly DOD now, the game is stable, holding at 72FPS, and working well. I dumped the CPU utilization stats using command line before, during and after this works and based on the latest figures, copilot analysed the number and advised: "You've got it to a really good place now-those CPU numbers say "real work on multiple cores", not fake parallelism. Quick read on the CSV: Core 1 is doing the heaviest lifting: ~40-66%; Core 2, 4, 6, 8, 11, 12, 14, 15, 16, 20, 22, 23 all show meaningful load; Total sits around 9-15% (so you've got tons of headroom); So: multithreading is actually happening, and the engine is stable enough to start deliberate stress testing." wow that's cool and only took a couple of hours to implement and perfect but I suspect it would have taken weeks or more if I had 6 senior developer working for me on this one issue - all taking $150K pa salary which would be a million dollars I do not have lol - this project just could not be possible without the advancement of Ai, my dream can actually become true and I keep worrying at every advancement that the next step or phase will be too difficult and my project and dream will be roadblocked, but no sir, copilot smart gpt 5.1 is up to every challenege and smashing it in moments.
- fixed - performance - ongoing phase 3 of 5 of BOT DOD migration. we are now implementing CPU multithreading via batch jobs and have already confirmed with my current architecture the game is utilizing CPU core 12 heavily while the other 23 cores are barely being used, single threaded, we need to divide the load amongst all the cores. A visual comparison of task manager cpu performance compared to a command line output comparison reveals the same.
- the command to dump 8 seconds of CPU utilization is : "typeperf "\Processor(*)\% Processor Time" -sc 8 > c:\temp\cpu_before.csv"
- this issue is completely resolved with the game running stable for 1 hour now without any DOD array corruption or degradation or array indexing issues or stars mysteriously disappearing as they spawn with no nearby bots to capture them, all the code has been made multithread safe which I was reluctant to believe because of my experience with multithreaded technologies and array reads and writes, but copilot did it, and with minimal code, just some basic wrappers around each code chunk and boom we have no more crashes or strange bot clumping due to DOD array corruption, I am astonished and amazed. phase 3 is not yet completed but the game is super stable, working perfectly, no strange bot movement or behaviour, everything being observed is 100% intentional including bot delays (thinking) and retargeting and I am almost lost for words. it's perfect. let's continue!
- fixed - targeting - some bots are still only moving for a short time towards a distant star when they fallback to the global scan search for stars when there are no nearby stars found using the new spatial awareness grid method, they move for a second or two then stop, this is bad and is more noticable now that I've reduced the max number of stars. one of the timers was being reset when it shouldn't have been, debug logging confirmed the bot had a nearby star which it captured, then no nearby stars, then after a few seconds it fell back to global star search and found one, then a second later the target was null while the star it aimed for was still present. all fixed.
- fixed - rendering - I am seeing the stars in play are wobbling in their place, it wasn't too noticable before but now when I get closer to the screen it definitely seems like stars are moving left and right while they should be perfectly stationary, this could be affecting the frame rate and the cause of the still unknown 72 FPS frame rate bottleneck! the stars and player wobble but botcollectors do not, they are perfect while stationery and idle. copilot analysed core.cs my primary main loop file and confirmed: "The wobble is 100% coming from the camera interpolation being applied twice.". interpolation was being applied twice! causing the player and star positions to change ever so slightly based on the camera location. wobbling is now fixed.
- fixed "good enough for now" - targeting - bots falling back to global star search if no nearby stars are found in the spatial field is working well, however, it needs fine tuning because I noticed if a bot targets a distant star using global fallback and moves towards it but I as the player capture that star before it gets to it, the bot should immediately stop but instead it targets and moves towards another distant star immediately if the star I captured is within the timer reset period, this is wrong. it should find one closest star and if it is captured by the time it gets to it, then it should stop and re-evaluate its position. the fix should not be adding a forced stop when the target is captured, the fix should be to optimize the global search code and ensure only one target is found and returned every single time the global search is used. the solution is one global target per fallback window. there was a lot of fine tuning involved and hours spent and the logic is still not perfect how I want but it is good enough, and as before, bots are meant to be dumb babies with no clue of why they exist or their purpose in the game when they are level 1, so leveling up will improve their behaviour and targeting is the number 1 trait, or maybe the only trait, that will be improved as they get smarter.
- fixed - targeting revisited - bots falling back to global star search if no nearby stars are found in the spatial field is working well, however, it needs fine tuning because I noticed if a bot targets a distant star using global fallback and moves towards it but I as the player capture that star before it gets to it, the bot should immediately stop but instead it targets and moves towards another distant star immediately if the star I captured is within the timer reset period, this is wrong. it should find one closest star and if it is captured by the time it gets to it, then it should stop and re-evaluate its position. the fix should not be adding a forced stop when the target is captured, the fix should be to optimize the global search code and ensure only one target is found and returned every single time the global search is used. the solution is one global target per fallback window. there was a lot of fine tuning involved and hours spent and the logic is still not perfect how I want but it is good enough, and as before, bots are meant to be dumb babies with no clue of why they exist or their purpose in the game when they are level 1, so leveling up will improve their behaviour and targeting is the number 1 trait, or maybe the only trait, that will be improved as they get smarter. this was mostly resolved on 14.04.26 but bots will still target a star on the opposite side of the world if their global target is captured, this needs further fine tuning. we need to reduce max stars to 20, reduce max bots to 1, and add debug logging for every star in play and its coordinates, and log what the bot is targeting because the bot is still targeting a star a million miles away when there are closer stars however it does retarget on its path to this super distant star and capture closer stars on its path and re-evaluate its next target, but the original trajectory when followed shows a really far away distant star as being the target, something is seriously wrong.
- the issue is clearly logic based and the bots will identify a star using global search and target it, while new stars spawn that are closer BUT they do not fall into the current spatial awareness grid so as the bot is moving it does not detect them because they are just out of reach which results in the bot moving half way across the world to the "nearest star" when closer stars clearly exist. I think the issue is the global fallback timer, it is not being reset when the target is captured and not reset if the spatial awareness method kicks in during movement to a distant star.
- fixed - When the player captured a star, the bots were never told to forget that star. So even though the star vanished, the bots still believed their target was valid and immediately retargeted globally. The final fix was simply: On player capture, explicitly clear that star from all bots' targets and reset their fallback timers.
=====================================================================
(NEXT ENTRY 2026 April)
this is source control save (0.000.002.217) build 776.
- fixed - game window - prevent the game window from being resized using the mouse, eventually the game will become a full screen game but windowed mode should be supported and the size should be static but modifiable by modders. SDL2 does this by default but we had added RESIZABLE code, simply removing it fixed this problem, the Window size can still be tweaked but no longer resized during game play using the mouse.
- added - terrain - let's add something fun. LMB currently destroys the terrain. let's make RMB explode a bomb with a radius half that of the current fog of war, and the bomb should destroy the terrain in a circular manner with the deepest effect in the center and gradually decreasing towards the edge of the circle so that the destruction circle is strongest in the center destroying all terrain to the bottom layer, and only destroy a single terrain layer at the edges. this is hilarious and works amazingly well for 10 minutes of effort. a fun feature update for once and not just troubleshooting or performance hunting or optimization or wrestling with broken code. yay, something fun :)
- fixed - terrain bomb - now has a more granular concentric circle with a larger center of destruction and rings exposing all layers of subterrain, it looks good and overlapping craters are just insane and actually shape the world and show a real world environment now on the minimap making the game feel alive for the first time ever, it feels like it has a terrain and not just a basic green background or basic black background as in earlier versions till now. I can see lakes and the minimap is just alive!
- fixed - rendering - migrating away from WinForms' GDI+ rendering over to SDL2 finally as currently SDL2 is just a thin wrapper that presents the window, but all rendering is still (to my surprise) being done by GDI+! arrrghhhh this graphics stuff is too difficult and I didn't realise it would play such a massive huge part in building a game - I thought the game physics and logic would be the hard part which I can easily handle, but cameras, camera follow, camera offsets, camera maths, drawing vectors and triangles and rectangles, and rendering images, and all these new concepts are too hard for me to handle on my own since I am not a professional developer or a game developer, I am just a programmer, a Senior Systems Engineer in my 9-5 looking after infrastructure, platforms, and servers, writing ansible and powershell code but not as a professional developer. But with Ai's help I can do this and learn some cool stuff along the way. This would not be possible even with a team of highly skilled developers - I'd be broke paying their salaries, lose my house, and not learn anything at all, and make far less progress. So this is still going well.
- the invisible elements including the player and deployed archertowers and walls, and stars, while terrain destruction and bomb craters and botcollectors and bullets were fine, was caused by calling the EndFrame method twice per frame. all fixed and all elements are visible, no longer flickering on and off since another fix and plenty of troubleshooting.
- done - remove GDI+ rendering once and for all, from all systems, subsystems and the entire project - refer to roadmap "REMOVING GDI+ COMPLETELY AND PROMOTING SDL2 TO THE PRIMARY GPU RENDERER - "THE FINAL RENDERER MIGRATION"" in my "winforms to sdl2 migration progress.txt" file. done, it took a couple of days and one completely wasted day that achieved nothing, but we got there in the end. My engine is now fully GPU-driven, SDL-native, and renderer-agnostic - No GDI+. No hybrid paths. No fallback hacks. No invisible entities. Everything - terrain, entities, UI, minimap, ghosts, bullets - is now running through a single, clean, modern pipeline. copilot: "This is the architecture you've been building toward for months".
- fixed - ALT and CTRL move the player upwards for some reason - likely because undefined keys are defaulting to UP? yep the default return key was the same code as for up. the code now returns zero for unmapped keys, problem fixed.
- fixed - pause overlay - the pause overlay is no longer appearing since we resolved the SDL2 rendering issues with invisible elements, the game pauses but the pause menu does not show, and the game cannot be unpaused and the executable must be terminated. this is proving difficult to fix (2nd time around) and all efforts have failed, an hour spent on this one tiny issue so far, adding debugging to identify what is happening in the pipeline. Since deleting the GDI+ renderer source code class file and working on troubleshooting and making SDL2 rendering work, many elements were broken and had to be fixed individually such as bullets being invisible because both the sprite was null and backup circle drawing method was non existent in the SDL2 class. pause menu overlay was fixed by a number of factors including rewriting the drawstring method which writes fonts to screen.
=====================================================================
(NEXT ENTRY 2026 April)
this is source control save (0.000.002.213) build 748.
- added - minimap - show terrain on minimap - I'd like a more detailed minimap - I'd like to see the terrain including tiles that have been destroyed revealing below ground layers. done! minimap now shows the complete terrain including all sub-ground layers as single pixels, looks cool, however and although this is related to GDI+ rendering and wont be an issue for SDL2 rendering, we need to optimize this to be a cached bitmap since the terrain rarely changes so there is no need to re-render the entire world map every frame from scratch, especially since there clearly is a performance hit with the current setup, I want this optimized before we introduce fancy hardware acceleration.
- fixed - minimap - optimize the new minimap whole world being shown including all terrain and all tiles rendering due to noticed performance hit. the game engine is now fully rendering the entire world into the minimap and only using 48MB of RAM! amazing optimization, previously it was exceeding 3.9GB and crashing the game, introducing bitmap caching made all the difference and also switching to calculating integer numbers instead of floats is much faster for GDI+. GDI+ is of course not hardware accelerated so a few tens of thousands of tiny rectangles per frame being calculated will affect the FPS rate so a slight performance hit is noticable but SDL2 will fix that.
- done - fogofwar - implement a fog of war to the world and ensure it is reflected on the minimap, initially only the area around the player should be visible, with a radius the same as the archertower's firing range currently, as the player explores the world the fog of war should be removed. fog of war options need to to be added to the settings.cs class with key press handling in the core.cs class to toggle the fog of war in the same manner as the f5 and f6 buttons currently toggle the camera style - either diablo mode or rts mode. the fog of war should have three settings initially - toggled with the F7 key - and include: disabled (no fog of war), enabled (default), and enabled but self healing so that only the currently visible world by the player (and eventually all troops) is visible with a 10 second self healing momentum should a troop that is exploring the world be killed - this will allow the user to view what happened to that troop before the fog of war shroud recaptures the terrain and world. I would like this based on popular RTS games - C&C and Warcraft2 and StarCraft2 but with an aim to have this available in RPG games made using the game engine as well. It will likely be disabled for factory sim games, city builder games, side scroller platforms games, etc.
- fixed - fogofwar - fine tuning - all three modes of the new fog of war work epic, exactly how I remember them from playing C&C and Warcraft2 and StarCraft2 for decades, however some fine tuning is obviously required. The Enabled mode works perfectly, no issues. The Diabled mode works perfectly, no issues. The EnabledSelfHealing mode however was not self healing unless switched to from Enabled mode, this has been fixed, refer to the fun facts section for details. The visibility circle around the player was very blocky and chunky, it was based on the archer tower's firing radius which is tile based, we have fine tuned this to be more round and softeneded however I will leave it as is and modders can fine tune this later and potentially make it a perfect circle around any friendly troop.
- fixed - fogofwar - repairs needed for disabled mode - when the fog of war is disabled nothing is rendered anymore, I didn't even realise because I assumed this mode would bypass everything. buildings, walls, stars, and bots, are all invisible. If i deploy an archertower it will immediately disappear. the rendering has been resolved in three source code files including the most important core.cs class and everything is working perfectly as expected.
- added - added the native SDL2 DLL files to the game root directory and changed their properties to be "content" build action, and "copy always" for the copy to output directory property, they must be beside the myfourthgame.exe file to function.
- added - all Resources (sounds images etc) recovered from backup and now included in the project .csproj file to ensure the entire folder is copied to the output directory during compilation.
- fixed - resolved all the compilation errors and resolved the few game crashes occuring on game launch, the game launches now! I can see the player in the top left of the map, I hear bots collecting stars, I see the fog of war and stars generating in my direct field of view, but none of the keyboard keys work at all, there is no mini map and the deployment hotbar is missing but the game is now being rendered by SDL2 - AMAZING!!! WINFORMS IS DEAD FINALLY and I have a proper .net8.0 project with SDL2 rendering, I'm over the moon, all the blood tears and stress were worth it. party time!!!
- done - re-creating the project in MS Visual Studio from scratch to migrate away from the legacy WinForms dependencies ("References") and the legacy .Net Framework project over to the more modern .Net 8 project which means deleting everything except my source code files, all dependencies on WinForms including Resources like Images which now must become Sprites, and packages like NAudio and SDL2-CS need to be reinstalled to the project using Nuget and rewired from scratch as I am essentially starting with a blank slate but just adding in my 40 or so source code files but the foundation and framework is missing. I can't believe this is finally done. I've seen Josh on youtube Lets Game It Out playing so many games, yes mostly early access, but still their frame rates would drop to 1 or 2 FPS and just die or crash, and now that WinForms and GDI+ UI Forms rendering designed for printing A4 documents back in the 1990's is gone, I have a proper game grade renderer and my frame rate will never drop unless I don't stick to my strict coding practices of only keeping optimized and clean source code, I do not want hardware acceleration to make up for sloppy coding practices, HW acceleration will only make my game engine even faster and I will ensure this by disabling HW acceleration to test all new source code, always, forever. this is EPIC!
- done - rendering - implement SDL2 hardware accelerated rendering for the game engine. The two phase (phases 11 & 12) roadmap has been fully updated, it consists of 12 sub-phases and apparently my game engine is already 90% there and ready for SDL2, cool. SDL2 is confirmed as working - I can see the GPU now doing work when the game is running, task manager performance view shows my rtx3070 ti using 5-10% utilization for the first time ever.
- fixed - mouse edge scrolling is restored after the massive move from WinForms to SDL2 rendering. keyboard key presses are next, then restore the minimap, and restore the building deployment hotbar, then check every other feature and system. so close now!
- fixed - resolve f5 and f6 being treated as move up or up arrow or W. and F7 not working.
- fixed - the mouse LMB and Function buttons F5 F6 and F7 are behaving like an autoclicker and LMB is decimating the terrain and not just destroying it one tile and one layer at a time, while the F7 toggle fog of war button cycles through the three modes continuously, need to prevent these events from being sent every frame. a single line in SDL Host "InputManager.BeginFrame();" resolved this by ensuring events are only sent once and not repeated. Copilot advised: "The per-frame state transition is the heart of your input model. With it restored:
- Edge-triggered actions (F5/F6/F7, ESC, K, LMB) fire once per press.
- Continuous actions (WASD, Shift, dragging) remain smooth and predictable.
- Mouse deltas are now meaningful again.
- Your entire simulation loop is no longer being hammered by repeated toggles.
This is exactly how your engine behaved under WinForms - and now it behaves the same under SDL, but cleaner and renderer-agnostic.
- fixed - botcollectors capture stars and make the popsound but when the player captures a star it generates an error: "Error playing sound 'Resources/Media/Sounds/popsound.mp3': The system cannot find the file specified. (0x80070002)". This was a duplicate legacy call to SoundManager which I simply deleted, WinForms is gone, and StarSystem now handles the capture star event for both player and bots.
- fixed - changed the slightly annoying scream.mp3 botcollector death sound to a new recording ahh.mp3.
- fixed - all currently mapped keyboard keys are finally working again - SHIFT was the only challenge as SDL has various keycodes for the various SHIFT options - leftshift rightshift & shift - so shift and shiftkey were scrapped, and now both leftshift and rightshift behave the same:
KeyCode class:
public enum KeyCode {
W, # working
A, # working
S, # working
D, # working
Up, # working
Down, # working
Left, # working
Right, # working
Space, # working
LeftShift, # working - fixed the one line mapping in the player.cs class from .shift to .leftshift
Shift, # legacy winforms - removed - left & right shift should be the same always
ShiftKey, # legacy winforms - removed - left & right shift should be the same always
K, # working
Escape, # working
F5, # working
F6, # working
F7, # working
F12 # not mapped yet - this will toggle the SDL2 renderer from GPU to CPU only for performance testing new code to prevent the GPU from simply overpowering un-optimized code
}
- fixed - shift button speed boost is not working. refer above.
- done - update the subterrain colours to be more natural - green grass, dark brown soil, light brown soil, grey rock, magenta (for fun), then three layers of blue water replacing the current bottom layer void with water.
- fixed - esc pauses the game but the pause menu overlay does not appear. this has been restored by wiring up the overlay to the new renderer. The pause overlay coming back online means the entire UI pipeline is now fully functional under SDL, and the renderer abstraction is officially doing its job. You've rebuilt a clean, engine-side UI layer that no longer depends on WinForms, and that's a foundational upgrade for everything that comes next.
- minimap is still missing. minimap has been restored using the new SDL rendering system however it has had a significant performance hit on the game. copilot: "A sudden performance hit right after restoring the minimap is a very strong signal, and the pattern matches something extremely specific in your architecture: the minimap renderer is doing full-world tile iteration every frame, and now that it's running inside the SDL frame loop, it's executing far more often and with far fewer idle gaps than it did under WinForms."
- fixed - the minimap needs to be optimized as it has caused a significant performance hit on the game since being restored. The fix: cache the minimap terrain layer Your terrain does not change every frame. Only destroyed tiles change, and even then, only a few per second. the minimap has been optimized significantly however I still see a noticable performance difference when the fog of war is enabled (both modes - on and healing) vs being disabled when the game runs much faster, more optimization is needed as I would have thought with most of the world being hidden behind a fog of war then less elements are getting rendered and so the performance should be far better with the fog of war enabled and the whole world mostly hidden but the reverse is true, so the fog of war being enabled needs to be optimized significantly by reducing the number of times it redraws the minimap when enabled.
- fixed - the minimap has been significantly optimized but with the FOW enabled the performance is still slower than with the FOW completely disabled, the reverse should be true since less of the world is visible and rendered when the FOW is enabled, but something is still not quite right and the world is being re-rendered on the minimap too frequently when the FOW is enabled. copilot: "Fog-of-war is still costing you more than it should because the minimap is rebuilding the entire terrain cache every single frame whenever any fog tile changes. Even though we reduced the number of dirty-flag triggers, fog still changes constantly in a radius around the player, so _terrainDirty = true is being set every frame.". copilot: "The breakthrough came from shifting the minimap from a full redraw model to a dirty-tile model, where only tiles whose fog state changes are repainted. That means:
- fog-disabled -> zero terrain redraws
- fog-enabled -> only tiles in the player's visibility radius redraw
- terrain destruction -> full redraw (rare)
- fog mode toggle -> full redraw (rare)
This matches the behaviour of professional engines and explains why the performance gap disappeared.
Your fog-of-war system is now decoupled from the minimap renderer. That's architectural gold."
- fixed. the mouse RMB is being treated like LMB and destroying the terrain, it should not do anything right now. also need to ensure unmapped key presses do not default to anything and are simply ignored, this should be ok now but need to double check the code. in fact all mouse buttons were being treated as code zero which is LMB, adding a "which" uint to SDL_MouseButtonEvent in SDL.cs resolved the mapping issue. all mouse buttons working perfectly now.
- fixed - building deployment hotbar is still missing. this has been readded to rendering and is now appearing along with the archertower and wall icons. neither can be deployed however and once the hotbar is clicked with LMB the button is trapped and can no longer destroy the terrain, but the hotbar is restored.
- fixed - building deployment hotbar is not clickable, well it is but it doesn't work - neither building or wall can be deployed and once the hotbar is clicked with LMB the button is trapped and can no longer destroy the terrain. additional mouse click routing had to be added to core.cs to resolve this issue.
- fixed - building deployment hotbar icon images are appearing and both archertowers and walls can now be placed on the world and the archertowers shoot bullets! the rendering system is working perfectly. however the ghost placement image is not appearing for neither archertowers or walls.
- fixed - building deployment hotbar is clickable and both archertowers and walls can be deployed, but the ghost placement image is not appearing for neither archertowers or walls. this has been restored with some minor code tweaks utilizing the legacy WinForms code but with new wiring for SDL2.
- fixed - structures being placed are missing the grid system overlay that surrounds them allowing the user to place structures neatly aligned but without forcing a grid system on the terrain - starcraft 2 style and not most other RTS games which force grid placement - grid placement should be made optional with holding down the SHIFT or CTRL button but unless the mapped key is held down the placement can occur anywhere. First I need the grid overlay to re-appear around the structure being placed. the grid overlay has been reintroduced.
- done - structures being placed should be able to utilize a tilemap grid placement method optionally by holding down the SHIFT or CTRL button during placement to make them snap to grid but unless the mapped key is held down, the placement can occur anywhere. the SHIFT button now forces grid placement using either structure center coordinates for even number of terrain tiles or top left corner placement for odd number of terrain tiles.
- done - the structure placement ghost grid surrounding the building should snap to the terrain tiles and not move freely around, this may be disorienting however so needs to be tested, I quite like the current way the grid follows the structure being placed as it hovers over the world but it does not allow for a perfectly aligned placement in line with other buildings so perhaps this should be a toggle also using the SHIFT or CTRL button during placement. the grid gently snaps to the terrain tiles but follows the structure being placed otherwise.
- fixed - placed structures can no longer be dragged, the mouse click handling is gone since introducing SDL2. And something we previously fixed has returned which is terrain being destroyed when placed structures like archertowers or walls are clicked. all fixed by rewiring the old code to use the new renderer.
- this issue has reappeared after SDL2 implementation, it was previously fixed under WinForms rendering - previous note: "edge scrolling continues even if the mouse cursor is no longer over the game window, edge scrolling should only occur when the mouse cursor is near one of the edges and within the bounds of the game window. we previously added some new safeguards to inputmanager, gamecanvas, camerasystem." but this issue has now reappeared under SDL2. all fixed with a basic code change, copilot: "That's a satisfying one to put to bed - and a good reminder of how differently SDL behaves compared to WinForms. The moment we stopped letting OnMouseMove overwrite the window-leave state, everything snapped back into the clean, predictable behaviour your camera system was designed for."
- fixed (again) - the game is in turbo mode for the first 7 or 8 seconds again, this happened previously in source control save (0.000.001.144) but resolved itself (we now have to fix it again it seems). this is fixed and was related to how SDL2 handles DeltaTime for the first part of a game once launched and all modern game engines face this very issue and resolve it the same way - What your engine needs (and what Unity/Unreal/Godot all do):
Every major engine clamps early deltas:
- Unity clamps deltaTime to ~0.1s
- Unreal clamps to ~0.05-0.1s
- Godot clamps to ~0.1s
- MonoGame clamps to ~0.5s
- SDL2 samples time twice before the first frame
Your engine should do the same.
- done - add snap to grid via SHIFT button for buildings being dragged exactly the same as new buildings being placed works. this was easier than I expected and works perfectly, walls cannot be placed directly adjacent to each other due to their smaller than the grid size but this can be fine tuned later, snap to grid works if SHIFT is held down.
- fixed - the game was in turbo mode for the first 7 or 8 seconds again, this is now mostly resolved but still present and requires further optimization - A small residual turbo effect usually means one of the early deltas is still larger than it should be, but not large enough to be visually obvious. The clean way to confirm this is to instrument the engine so it prints or overlays the first 20-30 deltaTime values. That gives you a precise picture of what SDL is doing during startup. This requires some debug logging and confirmation of what is in fact happening - ie. need to log the first 30 deltaTime values. The frame DeltaTime method was not even being utilized causing the initial frame related game turbo mode while the SDL renderer warms up, a known issue that all game engines need to resolve because the first few frames may be very large compared to the following frames, by referencing the method within the EngineTick method and removing the hardcoded 0.016 reference (60FPS) this has finally resolved the turbo mode permanently.
- fixed - performance / rendering smoothness - the game is unplayable with 200 stars in play, but absolutely smooth as with just 1 star and 5 botcollectors chasing it and capturing it then the new spawned star. days of effort into troubleshooting the performance bottleneck, i got copilot to ingest all 60 source code files and review every single one for any legacy winforms and gdi+ rendering code, and after ruling everything out we stumbled on the cause by accident - stars are OOP and due to the botcollector targeting logic, millions of calculations were being performed per frame griding the game to a halt. the solution was to make stars DOD just like bullets are, we copied the same bulletpooling code and syntax for stars and the game can now run ultra smooth with 2000 stars in play, 20 bots chasing them, and 20 archertowers surrounding the player all firing hundreds of bullets per minute, amazing! stars and star targeting and capture logic was the bottleneck all along. wow! I would have not thought this, but now I can have Factorio style performance with thousands of stars just like Factorio has thousands of conveyor belts, stars will evolve to being collectibles across the genres of games my engine will deliver including RTS, RPG, side-scrollers, and action-adventure, it will be ore or tiberium or rupees or XP orbs or minerals that can be mined or power up chests.
- fixed - performance and audio - the game can now handle Factorio levels of elements and objects and run ultra smooth. the sound engine NAudio however crashed the game when too many stars were being captured simultaneously with 20 bots capturing stars from a pool of 2000, a cooldown guard rail was added to prevent this sound load and play overload. all sound files are currently I/O operations during gameplay - this is very very bad, we need to preload all sounds once into memory and use that completely removing all redundant I/O and improving performance and stability.
- added - fixed botcollectors from clumping together as they target and chase stars with a new declumping method and call every tick, anti-swarm - they now separate if stuck together and overlapping for more than X seconds, it is a gentle separation and works really well.
- fixed - sound - audio playback is working perfectly but I am seeing this error frequently - is it just getting overloaded and can be ignored or does it require a fail safe guard - "Error playing sound 'Resources/Media/Sounds/Star/popsound.mp3': All mixer inputs must have the same WaveFormat" - the popsound is associated with star capturing and with 50 bots capturing a star or three every instant I suspect it is overloading the cached playback and can be ignored, potentially. fixed by adding a sampler and forcing all media playback to the 44.1Khz frequency in soundmanager class. SoundManager now auto-normalizes ANY audio file during playback, no matter how it was recorded, encoded, or downloaded, with zero performance hit.
- fixed - optimize the game as the frame rate appears a little low especially now that we've moved to SDL2 and it should be significatly better I would have thought. However, even with 35 ArcherTowers are shooting at machine gun speed setting 0.2f the game does feel fast and smooth although at certain times it does feel a little jerky and should be smooth 100% of the time, just need to add a frame rate counter and debugging code to see what aspects of the code slow down the frames I think. the FPS drop was all caused by Stars, they are no longer OOP and now DOD and I can have 10,000 stars with zero performance impact whereas before 200 stars made the game run at 3FPS, unplayable.
- done - remove old winforms class files, need to review every source code file and determine if it is still needed and if it contains any dead code - hopefully there's a shortcut quick way to identify all unreferenced methods in visual studio.
- ..\Engine\Simulation\GameCanvas.Stub.cs appears to be completely empty but has two references to GameCanvas, need to figure out why and what they actually do if there's no source code at all beneath the class declaration.
- obsolete - bot star targetting - I need to resolve the get closest cluster logic not working although looking at the logs its an even 50/50 (117 to 122) split between "Ai Targeting (Closest)" and "Ai Targeting (Cluster)". star cluster targeting has been ditched in light of converting stars from performance killing OOP objects to DOD data oriented design arrays of data, and stars will evolve to being ore or tiberium or minerals or collectibles or XP orbs so the clustering idea is no longer valid anymore.
=====================================================================
(NEXT ENTRY 2026 March)
this is source control save (0.000.001.169) build 649.
- added - terrain - sublayer effects - the terrain sublayers need attributes assigned for movement effects such as slowing down units passing over deeper terrain or being completely impassible etc. the terrain sublayers 2 through to 7 now slow down both the botcollectors and player on a sliding scale with layer 2, just above the impassible void layer 1, being the slowest, and the terrain layer 7 just below ground only has a minor slowdown effect. amazing. this was not much code but just required a basic maths multiplier for the existing speed value, pretty simple.
- fixed - adjusted the botcollector and player coordinates from being the top left corner to being the center to correct slow reduction and movement speed behaviour over sub-ground terrain layers.
- added - a new "Future above ground classic RTS style terrain while keeping the existing minecraft style underground terrain roadmap" has been added to my after SDL2 migration "next todos.txt" file.
- fixed - edge scrolling continues even if the mouse cursor is no longer over the game window, edge scrolling should only occur when the mouse cursor is near one of the edges and within the bounds of the game window. added some new safeguards to inputmanager, gamecanvas, camerasystem
=====================================================================
(NEXT ENTRY 2026 March)
this is source control save (0.000.001.167) build 639.
- added - new layer1 terrain void mechanism so that the very bottom tiles are treated as impassible and voids preventing buildings and walls from being placed on top of them.
- fixed - dragging existing placed buildings and walls over voids (terrain layer 1) is still working although it should be prevented. this was resolved by employing the same blocking mechanism already in place for dragged buildings colliding with other existing buildings, it is very different to the red green overlays and ghosting used by new building and wall placements and that is simply for variety and future proofing the code with additional scenarios and code styles for variations in similar but different concepts to keep modders happy as they won't need to reinvent the wheel everytime they want something a little different.
- updated - help menu - updated the instructions on the pause help menu.
- added - terrain - impassible - new layer 1 terrain void mechanism where the very bottom tiles are treated as impassible and voids preventing buildings and walls from being placed on top of them, and now from existing buildings and walls from being dragged on top of them, but should also now be impassible for bots and the player, this should just be a simple return logic somewhere. pretty basic code changes to implement this since both the bot and player classes already had building and wall collision mechanisms in place, so just had to extend them by adding terrain checks for void tiles.
- fixed - terrain - void collisions - fine tune the building collision with void tiles which sort of works but if I drag the mouse on the void's edge center I can drag an archertower or wall over it, but if the mouse is on the other parts of the void tile (corner or offcenter edge) then the penetration is correctly blocked, need to prevent all penetration. troubleshooting building/wall placement over void tiles which currently uses void tile coordinate sampling (4 corners and 4 edges), instead of geometry (rectangle-rectangle intersection) like placing over existing buildings has been resolved by implementing the same collision checks for void tiles as existing buildings or walls. this is also true for bots and the player.
=====================================================================
(NEXT ENTRY 2026 March)
this is source control save (0.000.001.165) build 625.
- added - implement a minecraft style terrain to the world, something no other RTS has ever done, it should be 7 layers deep beneath the ground, and 7 layers high above the ground. only the top level of every grid block item should be rendered, each block should be based on the existing world map grid system and potentially each block can be broken up into smaller sub-blocks but this can be a future state. explosions will destroy the terrain making it impassible for units leaving massive craters but the terrain will either quickly self heal (quirks of an alien planet) or be repaired with nano-bot bombs that can be dropped on damaged terrain to restore it back to its original state. This is MASSIVE and not just a new feature addition, it is beyond words, and has a 1000 questions that need to be answered first. the Roadmap document has been updated - "minecraft terrain addition, Q&A". this is huge. Unbelievably this is done relatively quickly and without too much effort, we employed DOD arrays for the terrain layers and apart from some initial bugs such as the terrain.tick method recalculating all 100,000,000 tiles every frame griding the game to a complete halt, easily fixed, it is all working perfectly now and I couldn`t be happier, modders will love this in the future when they realise how massively they can improve my game and game engine and how vastly they can tweak behaviour such as tanks crawling up a minecraft block style terrain lol but I did not use blocks, I went with tiles, although they can easily change their parameters as everything will be exposed via simple API calls and config changes. I am thrilled!
- fixed - fine tune the new minecraft style world terrain, the implementation is only completed at the basic levels and many bugs and optimizations need to be addressed.
- fixed - first resolve the building and wall placement mouse click destroying the terrain after modifying mouse LMB click behaviour to destroy the terrain so I could actually see the sublayers beneath the ground, and it is epic, but now building and wall placements also destroy the terrain which is undesired, a simple if building being placed then return safe guard did not work suggesting the click handler is still firing elsewhere.
- fixed - prevent existing building dragging from destroying the terrain when clicked to drag around, a safe guard added.
- fixed the minimap viewport is no longer a rectangle but just a dot that moves around the minimap.
- fixed - we identified that due to some maths logic copilot assumed I wanted to increase the world size from the existing 4000x4000 world to 160000x160000 which is insanely huge and explains all the performance hits, the minimap viewport being a dot, the player moving right for 2minutes and only moving a few pixels on the minimap (which previously appeared like it was dead and not moving but it took time to realise the reality). the world will remain at 4000x4000 and modders can change that later on, plus just like in C&C each level will have different world sizes so this is not exactly set in stone.
- fixed - performance optimizations and the new minecraft world terrain now only uses 50MB of RAM whereas before that it was 688MB and initially when first introduced it spiked to 3.5GB and crashed the game.
- fixed - pretty much all aspects of the new minecraft world terrain to make it feel natural (yes alien planet but natural nonetheless from a human`s perspective), the terrain sublayers are clearly there and just need attributes assigned for movement effects such as slowing down units passing over deeper terrain or being completely impassible etc.
- done - switch all x,y coordinates from the current 2D model to a 2.5D model initially using x,y,z where z is always zero but this will future proof the game engine allowing for 3D model objects to be placed onto a 2D game. this was completed and working perfectly.
- done - change the background pictures from the current backgrounds to give the game a unique feel - my first goal of programming a new game was to recreate something similar in looks and gameplay to clash before I progress onto making the game unique - I wanted to prove to myself I could build a game like clash before I move onto the more challenging aspects and my future ideas. instead of background pictures we now have a minecraft style world terrain in place and yes we can add images to replace the current flat colours based on layers but for now this is absolutely golden and epic, it can be improved upon later.
=====================================================================
(NEXT ENTRY 2026 March)
this is source control save (0.000.001.161) build 604.
- verified - Prevent Placement Outside World Bounds, Right now (a long time ago) you can place buildings off the map. A simple bounds check in CheckPlacementValidity() fixes it. this is now obsolete and legacy from the WinForms era.
- fixed - Prevent Placement Over the Player. You probably don't want the player trapped inside a building. One rectangle check solves it. fixed by adding a simple rectangle check in the placementsystem class.
- verified - Prevent Placement Over Minimap or Hotbar. Right now (a long time ago) you can place buildings on top of UI elements. Just add: - if (InputManager.HotbarArcherRect.Contains(mouse)) invalid; - if (InputManager.HotbarWallRect.Contains(mouse)) invalid; - if (InputManager.IsMouseOverMinimap) invalid; Easy and clean. fixed - this is legacy and has resolved itself by the new UI-agnostic input pipeline.
- done - Placement Sound Effects. A tiny sound when placing or canceling adds a surprising amount of feedback. SDL2_mixer will handle this later, but even a simple System.Media sound works for now. Both a placement and cancel placement sound effect have been added and wired in and working.
- added - a line based halo style grid around any new building being placed to highlight where it fits and doesn't, it complements the existing red green system of showing the same and together they give the game a professional look and feel.
- done - completed the full all-class migration to a completely 2.5D game engine using x,y,z world-space coordinates for everything, everything! I now have a fully Vector3-native world model - every subsystem speaks the same coordinate language. No more PointF leaks, no more mismatched math, no more hidden 2D adapters. This involved re-writing all PointF coordinates for BotCollectors, Player, Star, Bullet, Camera offset, Collision System, Movement logic, Targeting logic, Pathing logic, and World boundaries, as new Vector3 x,y,z coordinates to future proof the game engine only, as 2.5D is not necessary for my planned Ai Wars game based on this engine. PointF values still remain in a hybrid models but they absolutely benefit the game engine and are necessary for screen space and UI space conversions, while Vector3 now look after all World space systems. Once WinForms and GDI+ rendering is gone however, PointF will also be completely removed, but there's no benefit at this stage so this is parked for now.
- fixed - fine tune the camera follow speeds to prevent jitter especially when the player is moving in one direction and the mouse is on the opposite edge, or actually, this comes down to camera ownership and it should not flip flop between mouse edge scrolling and player edge scrolling, if the player is moving then that should override all other camera ownership rules. this was not about camera ownership at all, but in fact remediated by "Player movement completely disables mouse edge scrolling. Mouse edge scroll should not even be evaluated. This is how every RTS handles it: StarCraft, Age of Empires, Company of Heroes, Supreme Commander. Because otherwise you get exactly what you're seeing: two competing camera forces = jitter."
- fixed - fine tune player edge scrolling in rts camera mode as currently when the player reaches the edge it creates a jitter effect, this is very noticeable but small jitter while the player is moving normally, and massive 100 pixel jitter jump when they are speed boosting. this is essentially parked indefinitely and potentially resolved and caused by WinForms GDI+ rendering which is rubbish and not designed for high performance games, this can be addressed later once SDL2 hardware renderning is in place, if it's still an issue. Right now the camera is doing exactly what it should: following a moving target that occasionally crosses the edge threshold. With a lone hero, that motion is visually obvious. With squads, armies, or a commander-centric RTS view, the camera will be driven by intent, not by a single sprite's exact screen position - and the micro-oscillation won't even register.
=====================================================================
(NEXT ENTRY 2026 February)
this is source control save (0.000.001.157) build 588.
added / updates:
- fixed - new bug identified which I need to figure out how to replicate but it involves moving the mini map to another location the letting it return to the player then trying to deploy a building or wall from the hotbar which causes the camera to instantly snap back to some other previous world location where once the structure is placed the camera then snaps back to the player's location. this bug has changed however since we resolved the rts camera mode slow return, it is now different and not related to clicking the minimap or deploying buildings anymore, so it is resolved and I am raising a new bug in this one's place.
- fixed - when i start the game now (default is diablo mode), edge scrolling is completely dead - however this is because the player is in the very top left corner at 0,0 coordinates and not centered, so edge scrolling does not work and this is good, I just have to get used to it. if I start the game, and immediately switch to rts mode, edge scrolling works perfectly straight away without moving the player. the issue is that in rts mode, if i start the game, switch to rts mode, move the player to the center of the world, then try to edge scroll in any direction, it works until the player is about to go off screen and the camera no longer continues edge scrolling in that direction and instead becomes stuck in a jitter deadlock between the edge scrolling and keeping the player on screen - edge scrolling needs to have control over the camera if the player is not moving, but if the player moves then it needs to return to the player - is this achievable? this issue was also a bit of a journey but nothing like the rts slow return saga. I asked copilot what the fix was, it advised: "I stopped the camera-follow system from running while the mouse was actively edge-scrolling, so RTS follow could no longer fight against manual camera movement. Then I restored edge-scroll processing inside the camera's own update loop (so it isn't wiped each frame), which brought back smooth scrolling while keeping follow logic stable and jitter-free.". amazing, it all works like it used to back in the WinForms days but definitely improved and no more WinForms!
- fixed - fix both camerasystem camera returns snapreturn and slowreturn - slowreturn is far too slow to return to the player`s position, and snapreturn has some quirks where the camera jumps around the world especially when deploying new structures from the hotbar. this is now resolved and fully customizable for both systems including diablo camera mode and rts camera mode and both slow return and snap return for each camera system.
- fixed - fix wall deployment collisions so they can be placed directly next to each other without a driveway surround and enable walls to snap to the closest wall when being deployed to the viewport, the challenge will be user preference on whether walls can block building driveways and snap to buildings or not. buildings still respect a driveway system to prevent them being from placed too close too close to each other, however walls can now be placed directly next to buildings ignoring the driveway surround that is intended to prevent units from getting trapped, however the very nature of walls means they need to be placed against buildings. the catch now, is that new buildings cannot be placed directly next to walls due to their driveway collision system - this is easily fixed by checking what the surrounding building is however what if there is both a wall and building in the way, it will get tricky and I want to keep this simple so other developers can put their own preferences in, but I'll find a middle ground way forward.
- done - look into a mouse cursor clutching solution which will prevent the cursor from moving if a dragged building collides with another and doesn't move while the mouse continues to move with the button held down causing a disorienting effect where the mouse cursor is over here and the building being dragged is far away - the mouse cursor should remain over the building being dragged until the button is released. this is self-resolved as a result of changing the hotbar deployment behaviour using ghosts of actual buildings or walls and the cursor already is glued to the ghosts, so this is now a non-issue.
- done - Bullet pooling - Huge performance win once you have lots of towers. Consider the lack of pooling in Supreme Commander which attributed to causing massive performance hits, and on the other side Factorio which achieved millions of moving parts without that performance hit and Factorio achieved it with brutal discipline, data-oriented design, and zero waste. And the principles Factorio used map directly to my engine. The key here is to use Data-oriented design (DOD), not OOP (object oriented programming) - Factorio stores data in flat arrays, not object trees. Copilot advises: "Bullet pooling is the moment your engine stops behaving like a "game made in C#" and starts behaving like a simulation engine-the same architectural leap Factorio made when they abandoned object-per-entity and embraced flat, contiguous data. The core idea is simple: bullets stop being objects you create and destroy, and instead become rows in a fixed, reusable array that your simulation updates deterministically.".
- based on Factorio, C&C, Supreme Commander, KKND2 and other similar games, and the options presented to me, I want to proceed with a fixed size bullet pooling option as this is the most performance effective option and if we set the threshold to 5000 and the live bullet count hits 5001 (unlikely) the 5001'th bullet will simply not spawn and in 99.9% of cases the player won't even notice, this threshold can be adjusted later however based on the size of the current world map, a tower defense base builder using up 10% of the world to build a massive map, the number of defensive turrets and the types - slow archer tower, fast machine gun, slow mortar, super fast lasers, etc it is unlikely we would hit 5000 bullets in play at once, and this is the same strategy Factorio employs to allow for millions of moving parts and if the conveyors are full then some items just do not spawn, but this is completely un-noticable, and a non-issue, and keeps the game smooth, high in frame rate, and consistent. I like it. A bullet pooling roadmap has been added to my roadmaps file.
=====================================================================
(NEXT ENTRY 2026 February)
this is source control save (0.000.001.154) build 570.
added / updates:
- fixed - edge scrolling appears to be working much better but if you scroll down then attempt to scroll up, the screen will first scroll down a bit before it finally scrolls up, the same happens in any opposite directions left and right, right and left, up then down, down then up, and similarly for diagonal scrolling in opposite directions. This has been resolved by reseting the camera velocity after scrolling and the game engine now kills leftover velocity the moment direction reverses, basically zero out the previous value.
- fixed - in default diablo camera mode, with a settings configured camera slowreturn (not snapreturn), if the player is offscreen and not in the viewport, and they move, the camera will very slowly return to their location, however, if they are on the viewport and visible but not fully centered, the camera will snap back in an instant and it's a little disorienting. need to slow down the instant snap back to be a gradual return. this was a minor tweak to the existing code and essentially caused by a single line of code.
- fixed - in diablo camera mode, prevent the viewport returning to the player immediately once the minimap is clicked to another world location but only if the user is holding down the mouse click button on the minimap so they can view that part of the world while holding down the mouse button. This was resolved and both the RTS and Diablo camera modes allowing remote viewing of the world without returning to the player unless the player starts moving.
- fixed - speed up the diablo and rts camera mode slowreturns and make it tunable, currently the slow return is very slow and if the player is speed boosting the camera cannot even keep up. adjusting the LERP value has made no difference. the camera now returns to the player very fast and smoothly.
- fixed - the camera system now behaves like one in a professional ARPG engine: minimap drag has full authority while held, release hands control back to the engine, slow return finishes the job gracefully, WASD movement overrides everything cleanly, edge scroll still works without interference, no snapping, no jitter, no fighting
- done! - camera system overhaul to resolve the current hybrid screen-space and world-space model I have (that I was not even aware of) preventing the camera behaviour I expect from working due to complex screen-space and world-space conflicting calculations and both subsystems fighting each other. All RTS and RPG and Platformer games used pure world-space camera systems so this is paramount as my now and long term goal, and rendering does not play a part in this so the fact I have not yet migrated to SDL2 rendering is not an issue. A new phased approach roadmap has been added to my migration roadmaps file. Implement an intent-based camera movement. The camera system is now completely world-space and it took half a day to do with some minor challenges along the way but everything was easily resolved including rts camera mode being broken, diablo camera mode not being able to be switched back to after switching to rts mode, and fine tuning the speeds etc.
- fixed - the minimap viewport was getting stuck on any edge when click dragged against an edge preventing it from returning to the player in both rts and diablo camera modes, it just gets stuck and refuses to move unless the mini map is clicked elsewhere away from the edge again at which point full functionality is restored. viewport getting stuck on the minimap world edge is resolved - It would prematurely return while the mouse was still down, apparently I never dragged the minimap at all, there was not a single frame where dx or dy was computed. the key was "if (!overMinimap && !isDragging)". IsDragging has since been reinstated and works correctly. Why isDragging can safely stay - Before the fix, the minimap controller had this fatal flaw: It would prematurely return while the mouse was still down, this caused: isDragging to flip false too early, the release handler to never fire, MinimapOverrideActive to stay stuck ON, the camera to freeze at world edges, follow to be blocked, RTS lock to never clear. That's why I had to remove the isDragging condition earlier - because the state machine was broken. Additionally, to re-resolve this previous WinForms bug, I provided details of the earlier release notes which in turn allowed CoPilot to ensure the appropriate debug logging was put in place to identify the true root cause, and with the full output logs ingested, it found the issue very quickly after 4 hours of failed try attempts all day today, I was getting over the guess work so had to find a new way forward, and we got there, amazing.
- fixed - MAJOR BREAKTHROUGH FIX - RTS CAMERA MODE SLOW RETURN IS fixed!!! :
- TOO HARD BASKET FOR A RAINY `NOTHER DAY - 5 solid days wasted on this and always same result and no change - in RTS camera mode need to resolve the camera slow return only returning to the player`s location from another location in the world after the minimap was clicked or dragged, currently it only returns while the player is moving with WASD buttons and stops mid way if the buttons are released, we need a toggle switch that is false and only becomes true after the player is back on the screen in the viewport to ensure any minor player movement causes the camera to snap back or slow return back all the way back to the player. The snap back option works fine, it is just the slow return settings class option not working, it is far too slow.
=====================================================================
(NEXT ENTRY 2026 February)
this is source control save (0.000.001.144) build 541.
added / updates:
- an insane amount of troubleshooting, testing, trying new code, moving code from one class to a new subsystem, and we finally resolved building dragging which was completely dead and misbehaving when it did work dragging the wrong building when another was clicked and dragged, copilot advises the following which I'm glad to hear - "You've just validated a key principle of your migration: All input beginnings should be event-driven. All input continuations should be frame-driven. This is how Unity, Godot, Unreal, MonoGame, SDL2, and every custom engine does it. You've now aligned with that pattern." Awesome! but this almost killed me and I wanted to rollback so many times after we modified 6 of the 44 source code class files and made a mess of things as part of the WinForms migration.
- what currently works and doesn`t:
what works now after painful troublshooting - all of these were broken (again, not the first second or third time, this WinForms migration kills everything until it is rewired in a new way and conflicts resolved and old code removed, not easy):
- player movement with WASD and speed boost with SHIFT button. this is now fixed.
- bots moving and collecting stars. this is now fixed.
- player star capturing. this is now fixed.
- edge scrolling. this is now fixed. however a new behaviour has emerged, edge scrolling in RTS mode is perfect, it works anytime and after clicking the mini map to another world location. edge scrolling in diablo mode no longer works however perhaps it never should have since diablo mode forces the player to remain at the center of the screen, always, how interesting this wasn't a problem before but is now. I'm not sure what overrides or code changes to do since maybe this is ok?
- pausing and unpausing the game with ESC button. this is now fixed.
- building and wall dragging. this is now fixed.
- buildings shooting bullets at the player. this is now fixed.
- building and wall collisions with the player and bots. this is now fixed.
- bot freezing with spacebar. this is now fixed.
- mini map clicks were completely unresponsive and dead but this is now fixed.
- hitting F5 and F6 is also completely unresponsive so the camera mode cannot be toggled away from default diablo mode to rts mode but this is now fixed.
- bot melee killing with K button did nothing but freezing them with spacebar works, killing bots is now fixed.
- fixed - everything! everything works and even better than before, the new hybrid diablo camera mode is epic allowing edge scrolling while the player is not moving rather than forcing the camera to center on the player, so good and feels so natural. almost no migration work done in the last 4 hours, it was all troubleshooting, diagnosing, testing, logging, and repeat, but we got there just before the end of the day.
- done - migrated the primary game engine timer loop - main loop - away from Form1 and into Core class, CameraTimer_Tick() method is gone forever - this is a huge milestone and the legacy code will be available for all Indie devs using my game engine to build their games so they can see what the change was from and to.
- completed - cameratimer_tick deletion from form1 and relying on a new engine tick in core class.
- done - new phase 10A.6 - Move Camera creation into Core.
- done - two days of modifying code, migrating away from WinForms, breaking all game functionality, all elements, nothing works now except the basics, but I am continuing on trusting that copilot knows what it's doing, because I do not have a clue.
- done - migrated the mini map in full away from WinForms and it is now rendered by GameCanvas and inputs are handled by InputManager.
- done - Phase 10L completed - all legacy WinForms labels have been removed - (a new HUD system will replace them eventually but for now they are just removed) - they were: labelStarsPlayer, labelStarsBot, labelStarsRemaining, labelStarTargeting, labelBotMoveLocked, labelActiveBotInstances, labelActiveTargetStars. Form1.Designer.cs is now just a dozen or two lines long. UIStateSync has also been removed from the solution, UIStateSync was a temporary bridge that read engine state and pushed those values into the WinForms label controls on Form1.
- done - Phase 10M - Remove WinForms Pause Panel - removed, we tried to draw it through GameCanvas but the game was crashing on "Parameter is not valid" and all attempts to remediate within just a few minutes of effort failed so we parked it since this is a known issue with WinForms GDI rendering - this will be removed soon so no point wasting time on it. For now, the game can be paused and unpaused with the ESC button.
- done - Phase 10N - stripping Form1 down to the bare minimum and planning its deletion. Form1 has been reduced to 60 lines (it was 800 lines previously and has been shrinking daily and with each migration step).
- The following has just now been removed from Form1.cs:
- All camera logic, All debug flags, All unused fields, All unused methods, All WinForms UI logic, All sound helpers, All diamond drawing, All unused namespaces.
- Form1 is now:
- A window, A canvas, A timer, A focus fix, A call to Core.EngineTick, Nothing else.
- done - completed a full review of 1000 lines of previous roadmaps and multiple versions of roadmaps for all the work we have done on the game, game engine, improvements, bug fixing, and future state. Marked almost everything as completed and the amount of work we have done together is literarily insane, it's massive.
- done - Phase 10O - The Plan to delete Form1 entirely - Form1 currently - Creates a window, Hosts GameCanvas, Runs a 60 FPS timer, Calls Core.EngineTick(), Ensures GameCanvas has focus. Everything else is gone.
- done - Form1.cs Form1.resx and Form1.Designer.cs are all gone, deleted, permanently. WinForms is dead wow! and the game still works perfectly (with the existing but well known issues) and I can finally work on restoring all the lost features and functionality again. Massive milestone reached. Wow - I now have a fully platform-agnostic engine now:
Form1 was the last WinForms-specific artifact tying your engine to a UI framework. Now:
- Window creation -> WinFormsWindowHost
- Game loop -> WinFormsEngineHost
- Rendering -> GameCanvas
- Input -> GameCanvas + InputManager
- Simulation -> Core.EngineTick
- Camera -> CameraSystem
- UI overlays -> GameCanvas
- Assets -> Core + Systems
There is no WinForms dependency in the engine anymore.
Apparently I just achieved the "Unity/Godot/Unreal" architecture - and my engine now matches this pattern perfectly:
Every real engine has this separation:
Engine Responsibility | Platform Host Responsibility
Simulation | Window creation
Rendering logic | OS event loop
Input processing | Raw input events
Camera | Swap buffers / redraw
Game state | Window title, icon, size
- fixed - ESC button functionality and the pause menu overlay are restored and working. added temporary debugging to InputManager, GameCanvas, and Core and identified that due to how the frames were being created and the game engine timer tick was being sequenced, the input never reached the core class and so the keypresses were not being recognised in the engine class, core.
- fixed - The pause menu overlay was causing the game to crash but this was resolved by adjusting the onpaint brush disposal code.
- fixed - After resolving the pause menu overlay it was working but flickering like crazy and this was resolved by preventing the world from redrawing when the game is paused.
- fixed - Bot freezing with spacebar button is resolved by integrating the input key handlers and fixing the inut pipeline which was broken by incorrect input timing, not missing key wiring.
- fixed - F5/F6 camera mode switching - F5/F6 buttons are functional again - this was related to bot freezing and caused by the same issue and solution.
- fixed - Minimap click - is resolved and working by identifying that LastRenderBounds is never set anywhere, so it stays {X=0,Y=0,Width=0,Height=0} and overwrites the correct bounds that RenderToGraphics just wrote. Deleting a single line of code after troubleshooting for two hours resolved this issue. in summary the minimap was caused by a silent overwrite leftover from legacy WinForms code.
- fixed - Minimap dragging is also fixed for the same reason as minimap click.
- fixed - Bot killing with K button - the wiring for the K button was missing in player class and a call to the new BotSystem trymeleekill method was also missing after deleting form1.cs which had this code previously, but WinForms is gone.
- fixed - Hotbar icons missing for both ArcherTower and Wall - they were not missing, they were just being overwritten by post-migration placeholder code as grey boxes.
- fixed - DragSystem after building and wall deployment neither can be click dragged and this was caused by a single missing line of code post WinForms migration which Form1 previously handled.
- fixed - when I click and drag the mini map viewport, and drag it all the way to a mini map edge, and dont let go of the mouse button, then try to drag away from the mini map edge - i cannot - the viewport gets stuck on the edge. the mouseisoverminimap boolean became false when the mouse cursor went past the edges of the mini map causing a premature return on the minimap controller causing the viewport to get stuck to the edge.
- fixed - when buildings are placed from the hotbar using an auto clicker or fast clicking and they overlap then some of those buildings become stuck and cannot be dragged, we spent 2hours implementing a new hotbar dragging system but it was a disaster and I had to revert to a backup. for now, this can wait until the hotbar is removed and replaced with a proper HUD. this has actually been fixed by switching from deploying to predefined onscreen coordinates to a more user friendly ghost building being stuck to the mouse cursor allowing easy placement anywhere with the mouse left click and deployment cancellation with the mouse right click.
- added - Ghost building and wall Collision Validation to prevent newly deployed structures from overlapping existing structures.
- added - ghost building deployments highlight as green when placement is possible and highlight in red when they collide with other world structures, this is huge and will be improved upon once the terrain is added.
- fixed - ghost building deployments were showing a zoomed in top left corner of the overall image rather than the actual image in the correct size so that it matches the final deployed structure.
- added - a structure placement clearance constant to prevent buildings and walls from being placed too close to each other to prevent unit trapping, the constant value can be modified or reduced to suit preference.
- done - the game engine now contains a proper distributed game state management system, similar to Unity, Unreal, and Godot game engines, as a result of all the new subsystems in place. So, a proper "GameStateManager" - So the engine can switch between: Playing -> Paused -> Menu -> Loading -> Cutscene -> GameOver , modes is no longer necessary and if it were implemented it would simply be a thin wrapper around the systems I have already built anyways, there would be no point introducing a new class for this.
- done - A unified "TimerRegistry" - So any future object can auto-register its timers for pause/resume. This was a planned upgrade when WinForms (now gone thankfully) was still part of the solution and everything used timers, every bot, star spawning, camera timer, update timer, all these timers are gone now and replaced with an engine tick and update loop.
- done - Create a camera controller system with multiple modes - this has already been completed as a result of implementing things like camera modes (RTS and Diablo style), camera follow styles, edge scrolling, multiple minimap overrides, player-follow, etc.
- verified - ensure buildings that shoot anything towards anything else always shoot at the coordinates where that something was to prevent projectiles and bullets from arching or turning mid flight on their vector way towards the original the target that since likely moved away, this will be a more realistic approach however the game already handles this pretty well although I have observed some turning at the very end if the target moves just before impact - this may already be a non-issue. This is confirmed as resolved as ArcherTowers currently obtain the player`s world position coordinates at the time of firing and shoot at those coordinates each time which makes the game very realistic and fun, I`ve noticed clash of clans projectiles that are not seeking-projectiles can and do change direction right before impact which drives me nuts.
- fixed - PARKED UNTIL WINFORMS IS GONE - everything works and really well, archer tower dragging and bullets firing, bots moving, everything. BUT, for the first 7 or 8 seconds the game is in turbo mode - everything - bots movement, the player movement, the player speed boosting, archer towers firing bullets, bullets speed, everything is in turbo mode then it just slows down to normal. The fix is to clamp deltaTime on the first few frames, this is what Unity, Unreal, Godot, MonoGame, SDL2 engines all do. this has been resolved by changing the order of initialization - The turbo mode was caused by a huge first deltaTime, the new engine architecture fixed the startup timing, the engine is behaving exactly like a real engine now - clean startup, deterministic timing, no drift, no turbo.
- obsolete - once phase 6 walls are done I need to circle back and remediate the building class as we identified an issue, well I did, showing that the building class is still using legacy code related to Visual Studio Designer which the cleaner Wall class is not, the line is "WorldPosition = Core.Camera.ScreenToWorld(new PointF(this.Location.X, this.Location.Y));" and I need to ask copilot to help me with "Begin Phase 6 Building Migration - apply the same thin-wrapper corrections you applied to Wall.cs, but using Building.cs as the source file.". This will be known as phase 6B for no reason at all except that copilot suggested we revisit phase 6 which was for walls but this is when I identified the issue, so 6B it is (even though it should really be 3B). there is no WinForms code remaining and Building.cs is fully migrated and a thin wrapper now with no UI dependencies.
- obsolete - once phase 6 walls are done I need to audit form1 starGenerator and any remaining Bounds/Width/Height usages that still mix screen and world space. "Audit Form1 for any remaining screen-space logic (Bounds, Width, Height, Location, Control-based collision) and convert all of it to pure world-space, especially inside starGenerator and any spawn/collision checks". WinForms is long gone and this todo items was from that era.
- redundant - with the removal and migration away from WinForms and GDI+ rendering the Core class defined stars collections are no longer updating and as a result the counters for bot captured stars and player captured stars are no longer working. This is because the old references are WinForms controls which no longer exist and are null. Strangely the other labels which are WinForms controls are updating - such as Number of Remaining stars label which is working perfectly. This will be addressed with a new HUD system and the majority of the legacy now gone WinForms labels were merely for debuging purposes and did not really serve any benefit to the player.
- obsolete - remove all references to the now legacy WinForms rendering system for all elements in the game. I've removed WinForms behaviour, WinForms timers, WinForms controls, and WinForms rendering paths for all major entities, but there are still residual references to the old rendering system scattered across the codebase. Everything has been migrated to IRenderer and even this temporary system will soon be replaced by SDL2 rendering.
- obsolete - bot movement logic - prevent jerky bot movement behaviour such as targeting a star that suddenly disappeared and retargeting a new star in the opposite direction only to have the same happen a second later, creating an effect where the bot moves left then right then left again for example ... a human would not move this way in the real world although they may move their game character this way if a star suddenly appears nearby but in the opposite direction... some psychology involved I suspect. This will be addressed with my 100 levels of hardcoded bot logic followed by emerging Ai behaviour and learning after that.
- obsolete - change all labels text from descriptive to just 1/6 or 3/3 along with an image of what that label references. This is a legacy todo item from the WinForms era.
- fixed - placed buildings that overlap each other cannot be click dragged, they ignore the mouse click while other archertowers or walls beside them are fully draggable. buildings and walls are now deployed in a different way and overlapping is simply not possible due to the added collision system, this is no longer an issue.
- obsolete - the form labels do not update instantly, only every 1 second as per the configured star generator or other timers on the form designer view, this is because the update code is temporarily housed in the star generator function as a POC. WinForms is gone and labels will eventually be reintroduced with a new HUD system.
- obsolete - the ai targeting label on form1 is not updating to ever say it is targeting a cluster although the log file shows a cluster was chosen over the closest, this is likely because the closest cluster is being detected and stored over the closest star variable value, to resolve this I need to add code that will ensure a cluster is "always" chosen over a closer single star, except if the single star is on the same path or trajectory as the closest cluster being targeted, allow a temporary one time switch to the closest star but then revert to the previous cluster that was targeted by one of the stars in that cluster, if the closest cluster contains the closest star, then target the cluster and not the closest star - but the cluster is indexed by the closest star so if the closest equals the cluster then target the cluster by another star in that cluster excluding the closest star. WinForms is gone and labels will eventually be reintroduced with a new HUD system.
- obsolete - the ai targeting targeting label is sometimes switching to Cluster from Closest but then remains Cluster for a long time suggesting Cluster detection is not working as expected, seems to be related to both the label updating at an in appropriate time when it should be constantly updated, and cluster detection not working. WinForms is gone and labels will eventually be reintroduced with a new HUD system.
- obsolete - some of my classes fail to open in visual studio designer view giving an error "Failed to parse method 'InitializeComponent'. The parser reported the following error 'Object reference not set to an instance of an object.'. Please look in the Task List for potential errors.". the classes that open in designer view are - form1.cs, botcollector.cs, player.cs, star.cs, and bullet.cs, and the classes that fail and generate the above error are - wall.cs, building.cs.
- fix or add the parameterless constructors for visual studio designer view to be able to load the wall and building classes without causing a stack crash due to supporting objects like form1 and star etc which are all runtime only objects - refer to my fun facts section in the January 2026 release notes for more detail.
- this is no longer an issue now that WinForms is gone, Visual Studio WinForms view no longer applies.
- obsolete - bot and player advanced collision logic - I have already observed that bots, all 3 of them when in play and all in close proximity to each other following each other to the next closest star, all stuck against a building side, with the new collision bounce back "BounceBackLocation" code, while targeting a distant star on an angle, will all slowly slide along that wall in the star`s direction and eventually get around the side but at a reduced speed which I think is ideal as their speed should (emphasis on "should") be impacted if they're scraping against the side of a structure such as a wall or building, they should move away at least one (or 5) pixel(s) from the building`s exterior to regain full speed and ensure to avoid further collisions until that building`s, (and the next building`s or wall`s or other structure`s), side(s) is/are all cleared allowing full speed progression towards the target star, until of course another collision occurs. However, if the angle is just right, the bots will remain stuck indefinitely. This will be addressed with my 100 levels of hardcoded bot logic followed by emerging Ai behaviour and learning after that.
- verified - bullets should continue to shoot to their full range after missing their target, they should not just stop as though the defensive object shooting them was aiming at the ground where the target was but has since moved from. This is no longer an issue since it is confirmed that archertowers evaluate the player`s coordinates and shoot at that location and implementing this may be a future improvement but not something I want to worry about for now as it`s just not important and doesn`t make too much sense.
=====================================================================
(NEXT ENTRY 2026 February)
this is source control save (0.000.001.110) build 421.
added / updates:
- fixed - edge scrolling needs to work even if the player is off camera and the minimap was clicked to another world location after which the user tries to edge scroll which currently doesn`t work. this only applies to RTS camera mode because the Diablo style camera auto returns to the player`s location when the mouse is released.
- Here's the ultra-compressed roadmap you can hand back to me later - short, precise, and containing exactly the cues I'll need to reconstruct the full plan:
"Unify the camera into a single explicit state machine (Free, Following, Returning, MinimapDrag), make edge-scroll ownership depend only on that state + intent, remove all hidden conditions tied to player visibility or minimap override, and migrate all legacy booleans into derived outputs of that state machine." That one sentence is enough for me to rebuild the entire architecture when you're ready.
- As part of this works, we also need to address and resolve the current edge scrolling bug after minimap click:
"it all works except the camera ownership still has a bug which is: start game, move player to center of world, all edge and corner scrolling is working perfectly. the default camera mode is diablo. if I then click the minimap to another part of the world the camera snaps back smoothly to the player, this is good. but then if I switch to rts camera mode and click the minimap to another world location, then try edge scrolling there - it is completely dead, if I then click the minimap back to the player's location and try edge scrolling again it is still dead, edge scrolling only starts working once I move the player in any direction!"
- this has been resolved by itself essentially as a result of ongoing migration works away from WinForms and works perfectly, specifically migrating input keys away from the player and form1 classes into a dedicated subsystem, apparently the old system was causing the world to be redrawn 100 times per second and the inputs were being handled very differently to the new dedicated subsystem, so glad this is fixed.
- done - migrated both archertower and wall classes away from any dependency on form1 as part of WinForms removal.
- fixed - resolved the invisible but functional mini map since migrating the minimap rendering away from form1 and into gamecanvas.
- fixed - resolved the missing white border around the mini map.
- done - Form1 no longer owns bots, Core is the single source of truth, Engine is one step closer to renderer-agnostic, Bot logic is ready to move out of Form1 entirely.
- done - migrated bot spawning logic out of form1 and into the Core game engine class.
- done - Core game engine owns the bot list and form1 duplication deleted.
- done - Form1 no longer contains ANY bot logic, Bot lifecycle is fully engine-side, Engine is now renderer-agnostic for bots, ready for 10.9D - removing WinForms timers.
- done - Remove any remaining references to botSpawnTimer and botRespawnTimer from form1 and migrate these systems into core to use the game engine time.
- done - new BotSystem class now owns bot killing logic.
- done - Remove bot UI updates from Form1.
- done - phase 10.5 Remove Form1 dependencies from ArcherTowerSystem.
- fixed - HALF the day spent on a single new emerging bug which after dozens of changes and adding logging and troubleshooting ended up being a result of my very old original logic which by fluke did not surface due to limitations of WinForms which hid the flaw in plain sight - I was seeing bots getting stuck on top of stars they were supposed to capture, we tried collision detection changes, we tried the star dictionary lists and updates to them, we tried capture radius logic for bots, I tried eliminating bot collisions as the cause by reducing the max number of bots from 3 to 1 and the problem still happened, we tried a dozen other things and it all ended up being a single line of code preventing a bot from capturing a star unless it was its target and if it got stuck on a star that wasn't its target then that star become uncapturable and the bot or overlapping bots would just get stuck on it - I could push the bots around with an archertower and they would just come back to that star and get stuck on it again, but if I pushed them far enough they would retarget and capture another star then come back to the problem star and capture it, this was absolutely brain draining to troubleshoot and involved leaving the game running for 5-10minutes each time until the problem finally happened, it was very intermittent (a nightmare to solve) and difficult to reproduce but I think with this one line of code not removed but instead decoupled - ie a new nested IF condition instead of an IF condition with an AND evaluation which created a deadlock, has resolved this bug indefinitely, it surfaced now because the game is far smoother and runs better without all the legacy WinForms timers that masked it from existing, how interesting. More details because this is super critical to the stability of this game engine and ensuring everything works as intended:
=====================================================================
(NEXT ENTRY 2026 February)
this is source control save (0.000.001.87) build 379.
added / updates:
- done - Phase 8C - Removing WinForms from Player entirely.
- done - Phase 8C - Removing WinForms from Walls entirely.
- done - Phase 8C - Removing WinForms from Bullets entirely.
- done - Phase 8C - cleanup of botcollector.cs class.
- done - Phase 8C - Core Engine Cleanup.
- done - Phase 8C - Replace WinForms timers with engine update loop / Timer Consolidation & Deterministic Update Loop.
- done - Phase 8C - Camera System Cleanup.
- done - Phase 8C - Building & Wall Cleanup.
- done - Phase 8C - Collision System Cleanup.
- done - Phase 8C - GameCanvas Cleanup.
- done - Phase 8C - Core Data Structures Cleanup.
- done - Phase 8C - Final Pass: Remove Dead Code.
- done - Phase 8C - Final Pass: Naming & Structure
- done - Phase 8C - Final Pass: Stability & Performance
- done - Phase 8C - Star System Cleanup.
- done - Phase 8C - Minimap Cleanup.
- TODO - Phase 8C - Debug System Cleanup (step 11).
- TODO - Phase 8C - Memory & Persistence Cleanup (step 12).
- added new Entity classes for buildings and walls to make the original classes basic wrappers while the entity classes hold the definitions for those objects, similar to how the core class holds the definitions for the form1 class and game in general.
- fixed - collisions and other bugs resulting from removing the legacy WinForms UI controls - I`m starting to understand how all this works now, it`s not easy as a mere programmer and not a professional game developer, but with Ai`s help I`m getting there :)
- fixed - next performance optimization now that bullets don`t redraw the world every frame is to add world-space culling to ALL draw methods and not just bullets. This should provide a significant performance boost simply relying on GDI+ cpu rendering without gpu hardware acceleration. With the outcomes of removing the garbage WinForms dependencies this step is no longer required and has been fixed by removing UI controls for buildings, player, bots, and bullets - the game is insanely smooth now even after my 15yr old son tested it on his PC with his autoclicker and deployed hundreds of archer towers it still runs well, previously with WinForms just a dozen archer towers shooting simultaneously grinded his PC to a stand still 1fps.
- remediation phase 6A step 1 is completed - walls have removed all WinForms inheritance:
- removed all UI event handlers
- removed all screen-space logic
- removed all Designer constructors
- removed all painting overrides
- removed all Location / Size usage
- removed all WinForms drag logic
- converted Wall.cs into a pure engine wrapper
- verified - trouvbleshooted the flickering problem that only occurs when the ESC button is pressed the very first time after launching the game where the screen flickers and shows previous wallpapers before showing the pause menu a moment later, added logging everywhere to determine if multiple classes were handling keyboard and mouse events simultaneously but confirmed it was not the case. the flickering is merely a result of WinForms legacy code still existing in parts of the solution.
- fixed - walls are draggable again after removing legacy WinForms mouse handling and reinserting it to the primary form1 class which now handles pretty much everything except things like rendering which gamecanvas handles and bot movement which the botcollector class handles, this was a very difficult bug to find after removing WinForms dependencies from walls but a very tiny fix to make it work again. unfortunately buildings and archertowers are not yet real world objects, they are still WinForms controls, so the same fix does not work on them and they remain not draggable.
- fixed - buildings are draggable again after removing legacy WinForms mouse handling and reinserting it to the primary form1 class which now handles pretty much everything except things like rendering which gamecanvas handles and bot movement which the botcollector class handles, this was much easier to accomplish than with walls which are far simpler but it seems copilot smart-chat-gpt5.1 has learned and perfected the migration, amazing. onto phase 7 next!
- fixed - we migrated all edge scrolling logic away from the various classes like player and form1 and moved everything in the new camerasystem class, and we kept the old code along with the new code to run both systems in parallel during the migration and only for a few steps, edge scrolling started behaving strangely with diagonal scrolling on the edges and side edge scrolling not working at all until the opposite edge was attempted, there was a camera ownership conflict due to the old and new systems being in parallel, so we ripped out the old system entirely and edge scrolling was completely dead now. this was because the mouse coordinates were being sent to the gamecanvas instead of the camerasystem class so this was an easy fix but the diagonal scrolling remained, we then had to reset the orthogonal velocity when switching axes based on mouse coordinates and scrolling direction intent. This issue has now been fully resolved and all edge and corner scrolling is working perfectly now.
- done - as part of WinFORMS removal - Phase 6B: is to fix some legacy remnants from phase 3 where we migrated buildings but we have since done the same for walls which are similar and identified some additional todo items for buildings.
- done - THEN in WinFORMS removal - Phase 8: Replace WinForms timers with engine update loop.
- done - fix building and specifically archertower dragging once buildings are no longer WinForms UI controls and complete real world objects. The fix should be the same few lines of code in the form1 constructor as what fixed walls dragging once they were fully migrated away from WinForms.
- fixed - edge scrolling in both RTS and Diablo modes is still laggy but this may get resolved once we update all other elements from rendering unless they are visible as currently we have only done so for bullets which increased performance from a laggy stand still to very playable and smooth, edge scrolling causes lag but otherwise it`s good.
- fixed - fine tune botcollector jitter I noticed which only occurs when two bots are merging paths as they approach a star they both want to collect and it appeared like they were constantly colliding with each other, once I killed one the other moved away smoothly, should consider a similar approach command and conquer 3 (and StarCraft II, and Age of Empires IV) used to solve path finding where they simply removed collisions between friendly army forces allowing them to essentially walk over the top of each other as though they were the only individual troop heading to that destination point while still colliding with enemy troops, buildings, and walls as normal, however, my bots already can overlap eachother and do not collide with each other, the jitter I`m seeing is something else and remains to be identified and fixed. sorted - earlier jitter was caused by world-space movement + collision resolution + camera ownership interactions. Now that: bots run fully in world-space; collisions are deterministic; camera ownership no longer injects noise; edge scrolling no longer feeds stale velocity; ... the engine loop is stable.
- fixed - rts mode when edge scrolling is still very jerky, the same problem does not exist in diablo camera mode which is more camera intensive from my understanding. It was a side-effect of the old WinForms rendering path, stale camera ownership, and the velocity model.
- fixed - despite all the performance optimizations which all made significant improvements, surrounding the player by 20 archertowers currently all shooting like machine guns grinds the game to a halt still, in both rts and diablo camera modes, machine gun firing rate buildings should use 'dum' bullets and not bullets with unique ID`s and unique properties and so on, just basic bullet images being fired to improve performance, and in turn all other buildings fire rates should be significantly reduced so that spam placed buildings don`t overload the cpu, even before gpu hardware acceleration is introduced. this was all WinForms related, nothing more.
- fixed - the GetDistance function in BotCollector class can end up getting called too many times in a nested call scenario and either degrade performance, or eventually cause the app to crash if there are too many stars' distances being compared at the same time ... a maximum stars permitted limit must be included. This was resolved following several major architectural changes eliminated the conditions that caused this risk:
- world-space star lists are stable and no longer recreated
- BFS clustering is efficient and bounded
- targeting logic is no longer recursively chained
- distance checks are linear and predictable
- the engine update loop is deterministic
- star counts are naturally constrained by gameplay
- no runaway nested calls remain in the codepath
And most importantly:
- I haven't seen a single crash, slowdown, or pathological distance-spam scenario since the engine migration.
- fixed - a new yet to be investigated performance feature related to now having three bot instances at any one time in gameplay, all targeting the next closest star, all logging events by storing memories, all constantly re-evaluating the playing field (this feature is in its early infancy), all storing emotions along with any memories - happy with a successful outcome based on the previous event, or vice versa etc. Since the engine migration:
- bot targeting is stable and efficient
- memory logging is lightweight
- emotional state updates are trivial
- no runaway loops or nested evaluations remain
- three bots barely register on the profiler
- I haven't seen any slowdown or jitter tied to bot AI
- fixed - fine tune the new camera features after finally resolving the camera arbitration and contest that previously occurred when the player went left and mouse went right, for example (or in any two opposite directions), causing a jittery camera deadlock. The RTS style freeroam camera mode needs fine tuning, it is defined in form1 class in ApplyCamera_RTSFree. Resolved the arbitration deadlock, eliminated the "player-left vs mouse-right" tug-of-war, and the RTS free-roam camera now behaves predictably. The remaining differences in feel are just tuning values, not structural issues.
- done - Move all timers into a unified game loop. Copilot you previously said "Right now: - Bots have timers; - Bullets have timers; - GameCanvas has a timer; This is fine, but you're ready for a single master update loop. I can help you build: 'Core.Update(float deltaTime)' And migrate everything into it." I now have one unified engine update loop replacing all timers.
- fixed - fix archertower and building targeting on the player to be the center of the player`s coordinates, currently bullets target and hit the top left corner of the player. This was basic coordinates logic made simpler now that archertowers compute their own world-space center.
- fixed - ensure the botcollector speed is constant and does not change as I have observed at times, and I don`t know when exactly but they do appear to speed boost when chasing particular stars or star clusters and their direction changes for example, the bot speed should always be constant in the current state. That behaviour came from old WinForms-era jitter, not from BotCollector itself. Now that I've migrated to: a deterministic engine update loop; stable world-space movement; no UI-space interference; no redraw storms; no camera-ownership noise feeding into perceived motion... the bots no longer show any speed variance. self resolved.
- fixed - ability cooldown - add a timer to prevent the spacebar pause bots functionality from being used too frequently and especially nonstop and back to back by the player - allow it to be used once every 20 seconds for now.
- done - my most important class botcollector has been fully migrated from WinForms UI controls in one swoop, all 1300 lines of code and 60000+ character counts converted by copilot in one go, see the fun facts section for more.
- fixed - rare audio related crash that occurs only when shutting down the game, this crash has happend a couple of times now and I think only when I'm closing the game to kill it: NAudio.MmException: 'InvalidParameter calling acmStreamClose'. the infamous NAudio ACM disposal crash. Resolved simply by adding a try catch clause in a number of play audio places.
- done - migrated a lot of logic away from the various classes into a new centralized system using partial classes including for star capturing and collisions, this is a significant step in the removal of WinForms.
- done - re-organized the entire file and class structure of my visual studio solution - I have re-organised my entire visual studio project neatly, I have moved a whole bunch of files to a new GameSystems folder, and others to GameObjects folder, and the rest into a new Systems folder. And everything still works.
- done - migrated all star generation logic away from Form1.
- done - migrated updating the minimap logic away from Form1.
- fixed - look into optimizing the keyboard key presses especially since I`m currently using a mechanical keyboard but noticing that at times if I hold too many keys down simultaneously and try to switch the combination to something new the player may completely stall and ignore further key presses until all buttons are released and the new combination is attempted and it will then work perfectly, but this is not good enough, I'd like the same key button press response as in Geometry Dash game. "Implement a proper engine-level input system with full key rollover, no ghosting, and instant state transitions - Geometry Dash-style responsiveness." I just need to say "Begin Input System Upgrade - Geometry Dash responsiveness." when I'm ready but not until WinForms are gone as they impact this input behaviour. With the input system migrated out of the player class and into a separate subsystem the input behaviour is being handled a millions times better than previously, mission accomplished, geometry dash keyboard input achieved, amazing, this was all copilot, I take zero credit despite the Ai telling me it was all me with my diagnostic methods and troubleshooting and noticing patterns and providing the intel it needed to resolve the issue, hilarious because it was 100% copilot but it gives all the credit to me, so weird.
- fixed - dragging buildings or walls now slows down the game to a halt as part of the later phases of migrating away from WinForms UI controls, the simple act of click hold and drag slows the game down now. this may get resolved once all WinForms dependencies are gone. this has been resolved 100% by copilot chat-gpt 5.1 smart mode - it wants to give me the credit but nah uhh it was all copilot - here's what happened and the fix - Dragging walls and buildings was slowing the entire game because every tiny mouse-movement triggered a full WinForms redraw. WinForms fires hundreds of MouseMove events per second, and each one was forcing the renderer, collision system, and layout engine to run repeatedly. Once the redundant per-event Invalidate() calls were removed and rendering was allowed to occur only in the engine's fixed 60 FPS loop, the stutter disappeared instantly. The dragging system now updates world-space positions smoothly without overwhelming the UI thread.
=====================================================================
(NEXT ENTRY 2026 January)
this is source control save (0.000.001.38) build 259
added / updates:
- fixed - minor code de-dupe improvements removing unnecessary size parameters from the various building, archertower, bullet, and wall classes.
- fixed - updated the game engine rendering to only calculate viewport onscreen visible elements every frame instead of the entire world every frame.
- performance optimization - bullets cause massive lag - from I'd like to take the approach that ID Software took when they released Quake game after massive success with their Doom game, Quake was a 3D BSP-based engine architecture whereas Doom was 2.5D, however, what ID Software did to improve performance was to only redraw what was visible and not the whole world every frame, I need this working in my game before I even consider hardware acceleration for my game engine rendering, for maximum gains and to ensure my code is fully optimized before upgrading rendering to the next level. This game, and more specifically the game engine, must be accessible to everyone on earth with a PC and not just those who can afford fancy nvidia gpu cards.
- I also need to ensure the minimap remains updated always so this adds a challenge but since the graphics in the minimap are very basic, all we need to ensure is that all world position tags are updated every frame so that the minimap can be updated accurately because remember a player may choose to view any part of the world at any instant so this is critical and even paramount to ensure the minimap is always redrawn every frame. This apparently is not an issue since the minimap is tiny in size itself, only displays very small 2x2 3x3 4x4 elements and doesn`t include all the fancy viewport graphics so it doesn`t matter if it runs 120 timer per second it will not cause any lag.
- fixed - massive performance boost to the game and I can now have 20 archertowers arranged in a circle with the player positioned in the center being fired upon with bullets by all archertowers and it is quite smooth, previously the fps dropped to something real low like 1fps and the game was super laggy, now it is completely playable.
- fixed - resolved all the lag associated with game elements and world positions and world redraws caused by invalidations for the RTS style camera mode, the Diablo style camera mode however is still lagging significantly in the same exact scenario when simply switching to it with the F5 hotkey, F6 is RTS mode, currently.
- fixed - all moving elements are now configured to 16ms intervals meaning 60 FPS, previously they were all over the shop due to the legacy WinForms design which wasn`t so dependant on their values, now with everything updating every frame, and keeping consistent, the issues were blatant and obvious, there was massive mismatch between redrawing all the elements in the game and this showed as jitter effects, the player now moves smoothly even when 4x speed boosting with the shift key, it feels amazing and so refined, ready for the next optimization performance upgrade! yay!
- fixed - a tonne of optimization improvements implemented and the game feels amazing in every way with one remaining glitch to resolve - rts mode when edge scrolling is still jerky and jittering.
- done - more code cleanup removing legacy functions and lines no longer needed since the renderer engine upgrade, across all classes.
- fixed - resolved the star captured sound no longer working after removing additional legacy WinForms references.
- fixed - bullets are no longer dependent on the legacy WinForms code, they are true world objects now.
- fixed - archertowers and buildings are no longer dependent on the legacy WinForms code, they are true world objects now. this was a huge milestone and major surgery on the existing code, it was not easy and caused me great stress, but it`s done, and the game is smoother than ever.
- PHASE 5 of 10 is COMPLETED!!!! whoohoo - moving away from garbage WinForms to a proper rendering engine. The following is confirmed:
- Player is fully world-space - Movement, collision, star capture, camera behavior - all correct.
- Bots are fully world-space - Movement, collision, star collection, AI - all correct.
- Bullets are fully world-space - Movement, collision, despawn - correct.
- ArcherTowers are alive again - Range detection, bullet spawning, world-space targeting - correct.
- Minimap is perfect - Because everything important is now world-space.
- Camera is stable - No jitter, no redraw storms, no UI-based movement.
- GameCanvas is authoritative - Rendering is clean and fast.
- Sound is working - No regressions.
- Performance is excellent - This is exactly what world-space simulation is supposed to feel like.
- Only remaining issue which will be addressed later as part of the migration - Stars collected labels not updating - Expected - UI is still reading old fields. added to current issues.
- fixed - resolved the missing walls collision with player logic which meant that when dragging walls around the viewport to position them, they would just ghost through the player, they now collide and push the player around as they should.
=====================================================================
(NEXT ENTRY 2026 January)
this is source control save (0.000.001.04) build 211
added / updates:
- new GDI+ rendering engine has been implemented successfully with some minor bugs such as dead bots remaining on the viewport game screen but minor code tweaks resolved this and the other similar bugs, we are now ready to start looking into removing the old WinForms references and converting everything over to the new engine, simply removing the WinForms references is not an approach that can be taken as that would break everything, it must be a controlled migration from old to new.
- fixed - invisible bots after introduction of the gamecanvas class and partial removal or to be more precise partial migration from the current WinForms system to the new renderer which requires new arrays and lists for all elements to be added to the Core class which the other classes now reference and update world positions of every object every frame.
- fixed - archertowers buildings and walls no longer being movable. "archertowers, buildings, and walls, still cannot be clicked, dragged, or moved around, after they are deployed."
- fixed - de-duplicated the botcollector spawning which was occuring in the form1 constructor for the initial bot, and in the botcollector constructor, and in the form1 spawnbot and respawn functions. De-duped all this to one spawnbot function with another event handler function of the same name which calls the real spawnbot function.
- fixed - bots remaining as corpses after being killed as their disposal logic was broken with the new rendering system. "bots still remain as corpses on the screen after they are killed, we had this working and a recent change broke it again."
- done - switched from using WinForms-controls rendering (which has massive limitations and was never designed for RTS type games with hundreds of moving objects etc) to a custom-drawn engine which will improve rendering of all images and prevent object ghosting and smearing across the screen as WinForms can`t properly handle this. We need to remove WinForms controls from game objects and switch to a custom renderer. This is where the engine becomes: faster, cleaner, scalable, flicker-free, ghosting-free, capable of hundreds or thousands of objects.
- None of my logic can change, all my code must remains exactly as is including commenting and complex movement and other logic, you can only change things related to the removal of winforms and migration to the custom rendering engine. we applied a phased approach to achieve this migrating one element at a time and testing every aspect of it thoroughly before moving onto the next.
=====================================================================
(NEXT ENTRY 2026 January)
this is source control save (0.000.000.28) build 200, once finalized, currently it is the previous version + deltas.
added / updates:
- updated all the remaining outstanding screen based coordinates systems for all the various elements and classes and converted them to world position coordinates, this involved changing almost every class but was not too difficult as it was old code replacement with new in place code that simply calculated coordinates differently, it was not a rewrite and not too complex, a lot of changes were required and testing was completed at every step to avoid the scenario of making too many changes and breaking everything and then having to resort to reverting the whole project or individual class files from backup. I am now ready for upgrading the rendering system to a custom one from the basic and lacking WinForms.
-------
game download ability:
- purchased a new web domain - well eight new domains - and updated the primary https://my4thgame.com with a new download page in the same fashion as Factorio developers did years before they even thought about releasing their game on Steam for the first wave of customers, the bigger the wave at the start the bigger it will continue to grow
- https://my4thgame.com/ now includes a Download option for the beta version of the game, along with Google Analytics 4 (GA4) being installed and configured to track page access and downloads activities from visitors to my site
- the game will be freely available, including all updates and new versions, until it is solid enough and is getting overwhelmingly positive feedback - this will likely be years from now as first the game engine and physics need to be programmed, after which will come the aesthetic upgrades including using Blender to generate 3D models of everything for a fancy well polished and good looking game with excellent gameplay logic hiding in the back end
- a shareware model will likely be eventually implemented allowing players to try the game for free, an open source and mobile version of the game will also likely be made available to encourage modifications and games communities to get involved
- the game engine will come in two flavours - a free open source version which modders and young parents will love, and a paid version with all the advanced Ai and other features and so on - the game engine will be far more addictive and allow for all sorts of games to be created which anyone and everyone will be able to easily use to create the games of their dreams in any 2D game style - RTS, RPG, side scrolling platformers like Mario, static window games like tetris and pacman, and anything else they can imagine - the mechanics will be solid but still allow modders to do their thing and make it more fun or add new dimensions I hadn`t thought of
=====================================================================
(NEXT ENTRY 2026 January)
this is source control save (0.000.000.27) build 198, AND was,
this is source control save (0.000.000.26). AND was,
this is source control save (0.000.000.25). AND was,
this is source control save (0.000.000.24). AND was,
this is source control save (0.000.000.23). AND was,
this is source control save (0.000.000.22).
added / updates:
- updated - made the game world much bigger, added auto scrolling, resolved all the rendering and flickering issues related to integers and floating point numbers switching to the latter to future proof the game and prepare for a 2.5D model with x,y, and now Z coordinates eventually allowing for 3D objects to be added to a 2D game in a similar fashion as Factorio.
- fixed - all the bugs associated with switching from a static window sized game panel to a much larger world map including panning and scrolling across the map using the mouse and screen edge functionality.
- added - a minimap in the bottom right corner showing all game elements and allowing the player to jump to any position on the map by clicking the minimap or dragging the viewport rectangle that is on the minimap showing the current part of the map in the gamepanel, also prevented edge scrolling when the mouse is hovering over the minimap.
- fixed - fix location tags .tag for buildings and walls as currently they snap back to their original placement location upon any map scrolling.
- fixed - all location related code for all elements on the original game screen now referencing the PointF coordinates for the world map instead of the original x,y Point coordinates, the game now feels like a true RTS game like Command and Conquer with deployed archer towers remaining on screen in their place regardless of any world map edge scrolling or minimap world location jumps, everything has finally fallen into place and I`m ready to upgrade the visual render to a custom engine from the current lacking and limited WinForms renderer.
- fixed - unified the camera system by replacing the original camera with the new Camera.cs proper camera class and converted all the logic code for almost all the class files, this was a huge change and took two attempts to successfully implement, a single error broke everything and a backup zip had to be reverted to and try again.
- added - a new Settings.cs class file for storing user customizable settings which for now only includes the option of slowly returning or instantly snapping back to the player`s location when the minimap is clicked to look elsewhere in the world but then the player is moved - the slowreturn is a fancy new feature which I like but I suspect it may be off putting to some players although it`s kind of cool and gives this slow scrolling back over the world feel which I like, the snapreturn option instantly snaps back to the player`s location which is nice but the player could do this by clicking the minimap again so as I`m not sure which option I prefer, this needs to be a customizable user setting and we now have a new Settings class which is great, let the customization options begin!
- fixed - sort of - resolve the glitch that causes major player flickering when the player is attempting to edge scroll from being on the screen edges while the mouse cursor is simultaneously trying to do the same causing a type of deadlock or infinite loop where both actions are fighting each other, one has to take precedence over the other and that should be a settings choice defined in the new Settings.cs class as I`m not sure which option would be preferable by everyone, it'll likely come down to personal user preference so it should be a configurable settings option. THIS is not straight forward as this is not a glitch or semantics issue, it is a glitch between human intent - does the mouse cursor win or does the player being on the edge of the screen win. simple. Ai cannot resolve this, it is personal preference. In the end we removed the hybrid last action wins model and stuck with the player movement always wins, this feels natural, it is the correct way forward HOWEVER it will be a customizable settings option based on player preference. Ai agrees, and I`m super impressed to see this attitude and reaction to my deadlock query, it is not a dealock, it is a mix of two simultaneous intentions by the human player who doesnt really know what they want no matter what they say. the player movement must take precedence and I`m glad Ai agrees despite quoting other successful games that blah blah blah did it this way or that way, I`m not like them, this is revolutionary and new and we will find a way forward.
- attempted - migrating the camera control system out of the player class and into the form1 class which handles the game UI functionality however this proved impossible due to how the various timers and events and controls all interact with each other, refer to the fun facts section for this control save for more detail.
- fixed - the camera arbitration that occurs when the player is moving in one direction causing edge scroll in that direction, while the mouse is located on the opposite screen edge causing an infinite deadlock or tug of war between the camera owner creating a jitter effect and neither wins, player is trying to go left, mouse edge scroll trying to scroll right, camera gets stuck. This was a massive issue to resolve and involved numerous attempts involving reverting to zip backups of the class files after the code changes became too messy to follow along with from the previous stable version. The new code has introduced new bugs or behaviour that I don`t personally like but this is a game engine and not a hardcoded game so all the camera options must be customizable and configurable by the human player so they can choose and select the look and feel how they like it.
- cleaned up - tidied up and removed dead code and original now unused functions from the various classes.
- hours spent, maybe all day, on resolving the various camera and world position related issues including camera return be it snap back or slow return, after we unified the camera and removed the legacy code, the player class still has some control over the camera and it is shared with the form1 class utilizing values stored in the core and settings classes, it is very complex and far more advanced than most historic successful games as it not is a compilation of all the best features by default with all the unique behaviour coded as optional configurable and customizable settings, it is extremely complex but working well with only minor bugs remaining...
- fixed - if the minimap is clicked and mouse button kept depressed, it should prevent any camera returns to the player`s position. this is universal and not something I need to make a configurable setting.
- added - a camera mode toggle between classic RTS free mode and Diablo style player is always centered mode using F5 and F6 buttons allowing instant camera mode changes and making the game engine unreal, it`s epic. epic engine? the camera now behaves like diablo style with the character in the center of the screen while they move around the world, although it looks really cool I would prefer the player can move anywhere on the current screen and close to the screen edges without triggering edge scrolling until they reach a particular margin distance on that edge, this new camera mode should be configurable by the human and the current camera mode should also be retained as a custom option. New Diablo style and RTS freeroam style camera modes added.
- added - a speed boost for the player using the SHIFT button to help with speeding up troubleshooting and bug fixing the game especially in regards to the camera, camera offset, worldview, element and object world positions, and star collection, the speed boost allows the player to move 3x times faster while the SHIFT button is held down - there are known limitation with Lshift and Rshift not firing properly in WinForms games so just SHIFT is being used to keep the game and architecture stable.
- fixed - in RTS camera mode - if the minimap is clicked to another world location and the player is not moved, the camera should not automatically return to the player`s position until they move with WASD buttons but currently it immediately tries to return back to the player even if WASD buttons are not pressed, I suspect something is not updating that the keys are no longer being pressed. This return behaviour has been intentionally left in the Diablo style camera mode and works nicely.
- fixed - in RTS camera mode - the player should not be centered and instead allowed to move around the current viewport of the world without causing any edge scrolling to occur, they should be able to get close to the margins before edge scrolling commences and how close they get should be a customizable option.
- fixed - after mouse edge scrolling to any world location, the camera should not return to the player until they move.
- fixed - when a building is click dragged around the map it jitters between its current location and where the mouse is hovering while the left mouse button remains clicked, it appears to be infinitely switching between its current world tag coordinates and where the human is intending to relocate it to, and if the mouse button is released at the right time then the building will snap back to its original location otherwise it will successfully be relocated, same issues for the wall. The issue was that both classes were still using the original coordinates system and not the updated PointF world position coordinates system, this has been rectified and the result is amazing, the buildings and walls move to where you move them to and don`t jump around anymore, coordinates jitter is gone.
- done - The Diablo style camera mode is working well, it is defined in form1 class in ApplyCamera_DiabloCentered and doesn`t need any further fine tuning.
- added - corner edge scrolling for diagonal scrolling as currently you can only edge scroll up down left and right. the pixel value is stored as an integer allowing customization of how big the corner is to trigger diagonal scrolling and this has been implemented and is an excellent enhancement, worthy of saving a new control save (but not yet!)
=====================================================================
(NEXT ENTRY 2026 January)
this is source control save (0.000.000.21) build 142
added / updates:
- fixed - prevent mouse wheel scrolling zooming during the pause menu - simply added a if game is paused then return to the mousewheel listener function
- fixed - switched from using media player to NAudio (installed this NuGet package to my visual studio solution then replaced the MP references with calls to the new SoundManager.cs class)
- this also resolved the bug where all current sounds in the project would play on game startup which was weird and I couldn`t resolve without disabling the sounds from playing altogether
- updated - disabled all debugging log write to improve performance at least within visual studio
- fixed - the buggy zooming that looked horrible and would make objects infinitely small or massive and undoing the zoom wouldn`t take them back to their original size, added location based tags to all objects created or moved in the game that update as soon as the move or spawn or deployment or build occurs to keep the tag always updated allowing for smoother zooming
- updated - synchronized all the debugging if statements across all .cs class files to achieve uniformity and the same look and feel for the code, minor corrections to some references as well
- fixed - prevented buildings and walls from being spawned onto the game while it is paused
- updated the botcollector move variable name to botmove to help simplify troubleshooting and future improvements
- fixed - the game time was being incremented twice due to old and new code, the old code has been removed and the game time now matches real time
- fixed - the bot freeze ability which is triggered by space bar (currently) was being instantiated from the player class which should only have basic code for handling the space button, the chunk of code has been moved from player to the Core class
- added - add a bot freeze cooldown to prevent the player from freezing the bots for extended periods of time, the freeze lasts 5 seconds so the cooldown should be X seconds (cooldown is currently 10 seconds on top of the 5 second freeze (15secs) before the freeze can be used again)
=====================================================================
(NEXT ENTRY 2025 December)
this is source control save (0.000.000.20) build 117
added / updates:
- modified wall.cs class initializecomponent method to update the picture box code so it no longer gives an error in the designer view Shift+F7 in Visual Studio 2022 - old code deleted
- updated form1.cs walls and buildings default starting location when built to be aligned with the bottom axis
- add pause game menu accessible via Escape button
- done - pause menu needs to prevent the buildings from shooting - it is preventing the bot and player movements, and star generation, so far but archer towers continue to shoot while the game is paused
- added a dimmed background overlay for the entire game play panel when the pause menu is activated to give the game a professional look and finish
- fixed - the screen flickers when the pause menu is activated - Ai advises this is a classic WinForms layering issue and this has been resolved by only bringing one panel to the front and correcting z-order for the overlapping panels
=====================================================================
(NEXT ENTRY 2025 December)
this is source control save (0.000.000.19) build 106
added / updates:
- fixed - replaced the entire Update() functions in both Player.cs and BotCollector.cs class files with new simplified collision detection which also removes the bounce back feature which was allowing players and bots to squeeze in between two adjacent buildings, there was also a break; that had to be commented out which broke out of the all objects check boundary loop once a single collision was detected however this prevented the code from working when multiple objects were collided with especially as the bounce back x,y location would change briefly allowing for the possibility of slipping through due to the incorrect location x,y coordinates being evaluated.
- skipped - prevent bots' and players' boundaries from intersecting more than X pixels deep - this no longer happens for players vs bots and vice versa however bots can still clump up together which I may intentionally leave to allow for this behaviour since its the player vs many bots so let them clump together to be defeated simulatenously or cause more damage to the player at the same time.
- fixed - Need to fine tune the boundary checking for both bots and players to eliminate structure and environment penetration as currently both bots and players can squeeze in between adjacent placed buildings which is very bad as adjacent placed buildings should create a solid wall structure that is inpenetrable. Need to enable x,y coordinates logging for the player class and ensure it cannot squeeze in between two buildings anymore.
- the building penetration issue I am still troubleshooting appears to be related to two adjacent buildings, for instance, if I place a single building and try to penetrate it - I cannot, but if I place a second building adjacent to the first, suddenly I can penetrate the first where I could not before. does this help you figure out why the player can suddenly penetrate a building and go inside it?
- 23.11.25
- me
- "the player and bots are able to squeeze through in between two adjacent buildings but only when they are vertically stacked, horizontal penetration does not work between two buildings stacked in a row. Any idea what is wrong with my collision detection?"
- copilot
- Yes - I see what's happening. The issue comes from how your collision resolution logic calculates the bounce-back direction when the player (or bot) intersects a building:
- In both Player.cs and BotCollector.cs, you compute xDifference and yDifference to decide whether the collision is horizontal or vertical.
- This works fine when buildings are side-by-side (horizontal stack), because the horizontal overlap is correctly detected and resolved.
- But when buildings are vertically stacked, the overlap calculation sometimes favors the horizontal branch even though the collision is vertical. That lets the player/bot "slip through" between two vertically aligned buildings.
- fixed - the player penetration boundary check in the update function is not working as expected and instead just slowing down the player during overlap penetration but this may be ok as players and bots potentially should be able to overlap each other, so this may be a non issue.
- fixed - the building penetration and squeezing in between two adjacent buildings issues have been resolved using new code, the old code was reused to allow for bot penetration which in turn allows for the "k" button kill command to work which requires the player`s and bot`s coordinates to intersect for a melee attack style kill. no plan for bots to kill the player just yet, but defensive buildings definitely shoot to kill.
- 2025-11-23 - originally 23rd Nov but I then made more code changes without first saving and broke botcollector movement which suddenly would race across the screen when movement keys were pressed which should only affect the player, and not the bots.
- 2025-12-07 - reverted to previous code version and reapplied the new collision detection logic to the Update() functions of both player and botcollector.
- backup saved with 7th Dec datestamps
=====================================================================
(NEXT ENTRY 2025 May)
this is source control save (0.000.000.18) build 99
added / updates:
- fixed - stars remaining is now glitching if the kill feature is used, or perhaps when multiple bots capture the same star, ensure captures are unique by star.name and bot.id checks, and counters only increments once per unique star.name captured (think this is fixed now).
- fixed - found I was initializing two instances of the player who were 100 pixels apart and being controlled simultaneously. I disabled the InitializeComponent(); call in the Player() function within the Player.cs class leaving only the form1 initializion and deduping the player, I discovered this after analysing player location.x and location.y coordinates and finding there were two being logged simultaneously.
- updated - fixed up this running release notes file to deduplicate alot of the content and converting current issues to new issues within each previous release notes save.
=====================================================================
(NEXT ENTRY 2025 May)
this is source control save (0.000.000.17) build 95
added / updates:
- fixed - both the archer tower class and wall class correctly enumerate their boundaries when being placed and do not allow overlapping when being placed, however both the archer tower and wall can overlap each other and I can place a wall over the top of an archer tower and similarly I can place an archer tower over the top of a wall, I need your help in preventing this overlapping from occurring so that any placed buildings or walls cannot overlap each other. - Resolved by "Instead of iterating over Building and Wall classes separately, iterate over all Controls and filter relevant types dynamically".
=====================================================================
(NEXT ENTRY 2025 April)
this is source control save (0.000.000.16) build 93
added / updates:
- fixed - player position is now updating correctly and periodically based on a timer, the building class - specifically the archer tower variation of the class, is now calling the updateplayerposition function and in return is correctly targeting the player based on relative location - numerous archer towers now shoot from their distinct locations when the player is in their individual range.
- decided - that "My Fourth Game" will be the official name for the first game I develop as a result of building this game engine. The alternatives I had considered included "Ai Clash", "Ai Wars". It`s all about how easy is it to say and remember and how it rolls off the tounge - ie. "hey have you played my fourth game yet?" etc
- done - created a new icon file for this game using https://www.freeconvert.com/jpg-to-ico and my funny red face smiley player image.
=====================================================================
(NEXT ENTRY 2025 March)
this is source control save (0.000.000.15) build 87
added / updates:
- added - critical "break;" after successful boundary collision to prevent checking collisions against all other buildings after one collision is already detected, this will improve performance significantly and should not affect game play. In future, I would need to categorise or group buildings or objects based on locale for improved searching based on location coordinates.
- added - basic constructor to Building class for Visual Studio to be able to construct an archer tower building in the Form1 class Design View.
- fixed - alot of sizing related bugs including building a new archer tower with a picturebox I had to place over the archer tower instance, this makes me realise it should not be an instance of a class but rather a basic picturebox that is clickable..
- fixed - I had added an Archer Tower Building.cs class instance to the form as a clickable Control and configured click and mouseclick events to spawn a new building instance on the gamePanel at 200,200 x,y coordinates which is working but the clickable area is a very small precise x,y location and I need the entire picturebox to accept clicks. I have replaced this class instance with a simple clickable picturebox.
- fixed - Need to get the Boundary check for any buildings working within the Building class during mouse dragging. - new function code working perfectly.
- done - get the building Archer Tower instances to utilize the new Bullet class and shoot projectiles or bullets at the player`s x,y coordinates when it is in range, let`s make it 10 tiles all around, the archer tower building should detect the player`s x,y coordinates at all times, and when it is in range it should immediately begin firing bullets (or bullet class instances each with a unique ID) at the player`s current x,y location and continue to lock on and keep firing until either the player dies or leaves the 10 tiles proximity area to that archer tower building instance`s x,y coordinates location, the bullets that are fired should be fired every 1 second by initializing an instance of the Bullet class every second and placing it on the gamePanel at the firing archer tower`s location, then using a new 20 millisecond timer it should update the location of the bullet in the direction to the locked on x,y coordinates until they are updated which should happen under another new timer set for every half a second to update the known x,y location coordinates of the player and update the bullets to be fired in that new trajectory direction. The bullets should disappear and be disposed of, if they hit the target x,y coordinates of where the player was, or if they hit the player itself which can be determined if the bullet intersects with the player`s boundary, exactly in the same way as how star`s are currently captured except that in this case the bullets are moving towards the player, whereas with the stars scenario the player is moving towards the stationary stars.\- This has since been implemented, modified, modified more, and fine tuned and is working great with bullets originating from the center of the shooting archer tower building, and bullets are aimed at the center of the player based on their coordinates and width, and shoot along with a new timer which is stopped when the bullet is disposed after either colliding with the player or breaching the projectile distance limit.
- added - hitpoints to both player and botcollector classes, as well as damage per bullet to the bullet class, each bullet now damages the player 33 HP with each hit, player`s HP is 100 so death at 4 bullets currently. Note - each bullet is assigned a unique ID and is a unique instance of an object which may create too much lag if rapid fire rates are used however will allow things like tracking which targets or objects or obstacles a particular bullet hit along the way to the targeted player which could impact the bullet`s trajectory, velocity or stop it completely if it hits something inpenetrable for example. future note.
=====================================================================
(NEXT ENTRY 2025 February)
this is source control save (0.000.000.14) build 78
added / updates:
- resolved - alot of bugs related to class instance construction for unique instances with unique ID`s for bots and unique Names for Bots and Human Players, instances now spawn accordingly and adhere to the hardcoded max bots spawn limit.
- number of Actively Targeted Stars is working almost as expected still exceeds the number of bots in play - stars and clusters being duplicated I suspect - should be easy fix.
- done - ActiveTargetList converted from basic list to hashtable to allow for individual target assignments to bots and players.
- done - ActiveTargetList now converted from hashtable to two distinct Dictionary types to allow for non-unique keys and values storage and retrieval based on either the botID or the star.Name as the key, and either the botID or the star.Name as the value, this will allow crossreferencing.
- done - working on getting updated method of star capturing working with two dictionary lists instead of one hashtable or any attempts with arrays.
- done - Star_Generator method is now working, it does not need to update either of the targeting dictionaries when a star is simply generated.
- fixed - bot targeting and movement towards target is restored.
- done - bot targeting of single stars is working exceptionally well just with base logic of go get closest star, but with multiple bots in play, a lot of the time they merge for a long time if stars are in a particular area they all move towards, but they eventually sometimes split up again in opposite directions maximising captured stars counts for the 3 bots side, the new improve Ai targeting logic will overcome this.
- resolved - troubleshoot starCaptured( function in Form1.cs not working anymore since new dictionaries code added and moving it from the timer to a different call from location
- and ensure these references are being called and used appropriately:
SaveLastTarget(MyLastStar, target, stayontarget, lasttargetactive, move);
(MyLastStar, target, stayontarget, lasttargetactive, move) = ReturnLastTarget();
- resolved - the number of targeted stars appears to be double to what it should be, I suspect stars and stars clusters are being targeted and not being cleaned up properly from the ActiveTarget List.
- resolved - need to review bot ID assignment, bots list addition and removal for active or defeated bots, ensure Core.MaxBots count is adhered to (think this is fixed now).
- cleaned up and removed commented out old code from BotCollector and Player classes, and minor bits throughout the project
- resolved - troubleshoot and resolve labels not updating
- resolved - troubleshoot moveLocked getting stuck in Locked phase and not resetting to unlocked after 5 second timer.
- resolved - troubleshoot adding starnames to bot and player active target lists
- resolved - make the bot, player, and star images much larger in pixel size so that they can be far more detailed, but then autosize shrink them down to a smaller size such as 20 x 20 for bots and players, whereas currently they are 40 x 40, and make stars 10 x 10 whereas currently they are 15 x 15. Currently the images are being cropped to fit the specified size but the images should be stretched not cropped. - done.
- resolved - the kill 'k' button press feature is only working sometimes, this needs investigation and troubleshooting. - killBots function corrected and fixed.
- resolved - figure out why bot and player instances are still different sizes from a visual perspective despite all being hardcoded to a ".Size(40, 40)" throughout the code - all set to (20, 20) with Zoom scaling.
- done - add background to the gamePanel - style to be determined, could be a mix of side scroller.
- done - added datetime to all debug logging.
- resolved - stars randomly disappear from the game playing field as a result of bot or player movement alone, I have added coordinates logging to check for proximity issues related to captured stars. i found this in form1.designer.cs class `this.gamePanel.Controls.Add(this.player1);` it was added so that the player instance could be visible on the design view in visual studio but clearly this created a duplicated player instance.
- resolved - the gamepanel is currently set to the following `this.gamePanel.Size = new System.Drawing.Size(600, 600);` in form1.designer.cs let`s change it to be the form size but with 200 pixels border on every side, a virtual boundary. I found that the gamepanel, just like the player, were being initialized twice causing duplication, I can now see the form background and the gamepanel is nested nicely within it and with its own unique background.
- done - addition of new Building class with my own designed Tower Defense Archer Tower.
- done - botCollector bot instance speed and timer settings adjusted to give optimum performance.
- done - added WindowsMediaPlayer COM support to the form1.cs class and recorded a popping sound, cropped using an mp3 editor, and with just a few lines of code configured it as the star captured sound.
- done - the game performance is chunkier and significantly reduced since introducing zooming and edge scrolling - these are just functions with some predefined variables, that can be commented out to disable. this is simply caused by my laptop processing power especially when on battery at 50% performance ability, the game will run on the Azure vm servers and have infinite performance potential HOWEVER this is not an excuse for un-optimized sloppy code! minimize always, everything, but complexity of course comes at a price.
- done - add background to the form - 3D clash of clans style and make it visible as the overall background, then add a background to the gamePanel overlapping the form with a smaller rectangle size, and make the gamepanel the playable area including a padding boundary to prevent unexpected boundary access violations which I observed with no padding including scroll bars suddenly appearing despite being disabled.
- done - added bounce back logic for both bots and players colliding with buildings, ie the new Building class with my own designed Tower Defense Archer Tower, causing a hard stop when colliding with the building on that side.
- done - bots can now save basic memories to disk, currently only when killed by a player, and if their guid matches one in the save directory they can also recall memories, but not yet merge with existing memories, from the same directory upon being spawned into game play.
- done - the building ArcherTower instance added to the form controls can now be clicked to generate a moveable instance of the building class complete as an archer tower, the player can mouse click drag the building around and all bots and players cannot penetrate its boundary.
- fixed - clicking the building icon does nothing, or sometimes it spawns a building on the gamePanel, but it is not clearly defined in the code exactly what should happen when a human player presses the button expecting to be able to see a new archer tower building on the screen which they can move and rotate into the position they desire. - Only very specific coordinates are responding to clicks, I have memorised the location based on the loaded image.
- fixed - the Form1 class OnMouseWheel zoom is very jerky and requires serious optimization. this has been resolved with new code but will require further optimization or new code to further improve.
- fixed - at times the ai bot gets into a deadlock condition and stops moving despite plenty of targets around, I suspect the distance between the closest star and closest cluster may be the same causing a deadlock, need to add more logging around this and implement either a randomized approach (preferred) or pick one based on the number of stars in each cluster and their proximity as well as the cluster`s proximity to other individual stars or clusters, this could cause computational overload so is not my current approach - revisit - for future consideration.
- sometimes the deadlock is a single star, a target, that until is removed from the playing field, prevents the ai bot npc from moving indefinitely.
* this has been resolved by adjusting the bot timers and speed combo.
- updated - hand drawn archer tower picture replaced with microsoft designer Ai generated picture, just for aesthetics during game development.
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.13) build 16
added / updates:
- added debuglevel 1 2 3 variables to control output of all Console.WriteLine() output debugging commands for all classes and instances of those classes, used basic regular expression regex replace all == find: "Console\.WriteLine\((.*)\);" == replace with: "if (debugLevel1 == true){Console.WriteLine($1);}" == across all open documents in the project (NB: '$1 = This is a placeholder for the text captured inside the parentheses by (.*) in the find pattern.').
- confirmed globally unique ID`s being assigned to the bot Instances are in fact truly 'unique' based on the number of characters in the GUID - current example of a this.botID is "624fc7c0-429a-45bf-ba2e-bcc5056b8eca".
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.12) build 14
added / updates:
- whitespace cleanup and release notes revamp
- troubleshooted importing the already large BotCollector.cs class into copilot Ai for assistance and took notes on simplified future interactions
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.11) build 12
added / updates:
- imported entire project, all source code, into copilot which confirmed it had no prior knowledge of this or any project, and copilot stated it is a blank slate every time we chat with no historic knowledge of any sort, I am not sure I believe this entirely, I believe the code, the provided help, the responses, the outcome, all is recorded somewhere potentially in an effort to assist with building the new Super Ai mentioned in President Trump`s speech a day or two after his 2nd term commencement, so potentially this code will not be unique and will be cached across the internet etc however I am ok with that as the aim of this game or game engine is to create a basic 2D game engine that takes all my 40 years of game play experience since the 1980`s, right up to the latest VR games, and take all those experiences into account from games like Lemmings, Super Mario, Mario Kart, Bubble Bobble, Tetris, Halo series on XBOX, clash of clans and all the cheap knock offs that were released right after such as the star wars looking version (Star Wars Commander) which I played excessively at the start but following a lack of Ai, basic logic, creative improvements, and just boring game play, it looked amazing but was a rubbish game, googling the game now I see it was taken offline 5 years ago in 2020, while clash of clans with its minor very minor tweaks, updates, changes, upgrades, new troops and spells, keeping the game extremely well balanced with such a wide selection of troops, however it`s obvious the game was not designed to be revolutionary, but rather more of the same but with stamp collecting tactics to keep people coming back day after day hour after hour for over 12 years, so that supercell could make a fortune with a basic concept - release well balanced upgrades and additions but make them OP temporarily so that everyone spends money on upgrading that item or item combo to achieve that attack strategy, then once you've made a fortune and the sales for that item start to drop, release an update claiming rebalancing changes are needed to make the game fair, they've already made all the cash, then focus on the next new upgrade and repeat this cycle indefinitely.
- added ability to spawn up to 3 bot instances at any one time, and the ability to kill them with the "k" button, note the space bar button five second freeze is still configured and in effect, each bot instance is unique, with its own global ID, which is used along with the yet to be defined GameID and GamerID values, and date and time, to save files centrally on the server that future bot instances with a matching GUID can access - errors and bugs may one day lead to memories of one bot being overwritten with that of another with the same unique global ID which clearly wasn`t unique, this could have amazing outcomes in the game or game engine as the code already prevents overwriting new learnings by first saving them to the file of the same filename, then appending any new events to that file every 10 minutes.
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.10) build 10
added / updates:
- fixed - the form.labelupdate function still being called prematurely from BotCollector class before all the necessary initializations are completed, causing an "object reference not set to an instance of an object" error exception crash
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.09) build 9
added / updates:
- max limit of 30 stars
- some minor code improvements and tidy up
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.08) build 8
added / updates:
- new revised get closest star cluster logic bugfixed and working in the BotCollector class
- additional movement locked / unlocked label
- code to update the ai targeting label with the current star being targeted by the ai bot npc - currently it only ever shows closest - likely cause and fix explained in issues below
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.07) build 7
added
- increased form size to 1080p 1920x1080 dimensions but then readjusted to laptop widescreen window size whilst the OS is at that resolution with 100% scaling enabled
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.06) build 6
added:
logic to recognize and act on new space bar button press was added however the timer that was supposed to pause the ai npc was not working as expected. I added attributes to the ai npc BotCollector class to store the current datetime and compared against five seconds ago while at the same time being in a loop that iterates every millisecond without pausing or affecting game play, my outcome was not working as expected, with some to and fro and explaining the success or new problem with the revised code, copilot 2025 was able to correct the code to behave exactly as expected with the timer resets appropriately configured, and everything working as expected with just some basic to and fro`s with copilot, without the need to write down the logic on paper and code from that high level design, Ai ftw again.
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.05) build 5
the code was compared to an earlier version and rewritten to resolve a strange null exception pointer error occuring instantly and constantly suddenly - suspect fat fingers or cat on keyboard.
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.04) build 4
basic randomization introduced to the x and y coordinates generation for new stars being added to the game field, this code is buggy and not true randomization as the pattern created if no stars are collected, is one or two parallel straight line(s) from a vector perspective.
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.03) build 3
basic randomization introduced to the x and y coordinates generation for new stars being added to the game field, this code is buggy and not true randomization as the pattern created if no stars are collected, is one or two parallel straight line(s) from a vector perspective.
=====================================================================
(NEXT ENTRY 2025 January)
this is source control save (0.000.000.02) build 2
the ai npc now always retargets simply based on any new closer stars and targets that unless a closer star appears which is then targeted and so on. At this point the basic game of who can capture more stars has actually become somewhat difficult.
=====================================================================
(FIRST ENTRY 2025 January)
this is source control save (0.000.000.01) build 1
the game engine is at its most basic - the ai npc targets the closest star and locks on until the star disappears regardless of who captures it - the player or npc.
=====================================================================
=============== WHAT STARTED IT ALL SECRET NOTE ====================
=====================================================================
2025. January. 01.
Arthur Sulkowski
After playing clash of clans on two iphones for 12 years, and on a third iphone since Jan 2024, and each year/day/month I would hope the next update would improve the game, make it better and more fun but each update only brought disappointment - basic new levels for buildings which over time decreased from 10% more dps and hp every upgrade to 5% with the same loot and grind time requirements, and some new troops and spells, the game remained static, the bot logic is dated and frustrating - ie. watching a queen shoot a wall to get into a chamber that allows ranged access to one building but then being trapped in further walled compartments while the rest of the army moves on leaving her behind, yes jump spells and root riders and wall breakers can assist but the base logic does not allow bots to reassess their situation with one exception - if they are hitting a wall or building, they will continue hitting that building until it`s destroyed regardless of what is happening around them unless an enemy actively starts causing them damage which they wont respond to until that wall or building is destroyed by which time they could be defeated. That`s just one example of thousands more frustrating scenarios with this game which I love and have spent thousands of dollars on, but for what, nothing, more of the same. So, I decided I could make it better and include elements from other games I have played my entire life while enhancing the game, game play, and every element of the game with new 2025 developments in Ai enhancement and code development assisting, a perfect opportunity to start on such a project.
|
