|
 
|
"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 March)
this is source control save (0.000.001.161) once finalized, currently it is the previous version + deltas. Only upload fully patched stable versions.
- 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) once finalized, currently it is the previous version + deltas. Only upload fully patched stable versions.
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) once finalized, currently it is the previous version + deltas. Only upload fully patched stable versions.
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) once finalized, currently it is the previous version + deltas. Only upload fully patched stable versions.
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) once finalized, currently it is the previous version + deltas. Only upload fully patched stable versions.
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) once finalized, currently it is the previous version + deltas. Only upload fully patched stable versions.
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).
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).
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) 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). 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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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.
|
