Developing an RTS Game: Devlog (Updated: 2/19/22) and Showcase

Prrz

Member
- Nodify (name undecided) -



- DEVELOPMENT OF THIS GAME WILL BE TAKING A BACKSEAT FOR THE TIME BEING BUT IT IS NOT BEING FORGOTTEN -
Introduction:
Hello again Game Maker Community, I have been working on developing a real time strategy (RTS) game as my next project, and have figured that it was time to start writing a development log.
At this point in time, development is still in its very early stages, so before it is too late I would like to start sharing my progress with you in this thread. I know that making a functional as well as entertaining RTS is a massive undertaking (in any game engine), but it is a genre of game that I have a lot of passion for and would love to hear your thoughts, opinions, critiques, feedback - etc.

NOTE: Progress on this project will be slow and steady, I have many real-life responsibilities (sadly) that take priority. With that being said, I will still update this post whenever I get a bloody chance to make worthwhile progress (lmao) and continue developing this game in my free time! I hope you enjoy :D
NOTE #2: Down the road, I will be in need of alpha testers (and eventually beta testers) - please contact me if interested!

12/5/21:
  • Initial development begins, started with setting up viewports, cameras, and controllers. Added a grid, tile-based cells, and made some basic temporary sprites.

12/13/21:
  • Basic controllers have been mostly successful, pathfinding has been mostly implemented.

12/15/21:
  • Pathfinding improved and optimized, tested benchmark FPS values and started working on avoidance behaviors. Controllers improved upon and code cleaned up.

12/20/21:
  • Avoidance behaviors generally scrapped, basic implementation seems to work for now - might revisit later if I deem it necessary. Otherwise, pathfinding is mostly good to go.

12/21/21:
  • Decided to take a break from coding and start creating some basic GUI assets, spent a good amount of time perfecting the idea and trying to make the GUI look clean. I wanted to do this before I started implementing basic features so I did not have to work backwards down the line.

12/23/21:

  • GUI completed to my liking, with some basic tweaks that I want to make in the future. Added to the game and started working on making the buttons able to be interacted with.
  • Made working buttons and the ability to add any text when you hover over a certain button - pretty proud of how it works, uses just one variable to determine what to draw to the screen.

12/26/21:
  • Revised some of the buttons and how the text draws to the screen, not everything has been changed around yet but it is generally looking good to me. Added queue list for "building" units, the ability to remove the last unit from the queue, and added a visible indicator of how long the unit has left before it is fully "trained". Created a rally point system for building that can generate units, but no proper sprite has been created yet - as of now it is just a basic drawn circle.

12/27/21:
  • Realized a huge flaw in my pathfinding script, the FPS would tank seemingly without any good reason. After several hours of trying new things, I found a super simple fix and satisfying fix. The movement system has been changed slightly, and FPS is back up to the thousands even with many units pathfinding at the same time.

12/28/21:
  • After what seems like forever, I was finally able to successfully have the "worker" unit move to a "resource" node, collect the resource, and return to the closest "hub". At first I wanted to have a limited number of units available to collect a resource at once, but I found that idea to be rather cumbersome and generally... an over-utilized mechanic. Instead, I made it so the time it takes for a "worker" unit to collect a resource is a function of how many other workers are currently using the same node (with 5 or less not affecting the time what-so-ever). Optimized scripts for handling this behavior.

12/29/21:
  • Realized that I had not tested my code with more than one "hub" and with more than one "resource". Well... hindsight is 20/20 because everything broke. "Worker" units were completely confused, were moving faster and faster the more that were collecting a node, and the total "resources available" was not being split, ie, if resource 1 had 3000 and resource 2 had 3000... even if no units were collecting from resource 2, the resources available were also ticking down. Other issues were found as well.
  • Re-wrote the code and made it WAY better, and now it works as intended. Number of resources, number of "hubs", number of "workers" no longer has a noticeable impact on performance or functionality. HECK YEAH.

12/30/21:
  • Quickly made a dummy-system for having a worker be able to create new building, made the costs associated with this null for testing purposes, ie., you can build unlimited things despite not having enough resources. Successfully made a good prototype of this system, and figured out a way to make sure that the building is being placed in a proper location. Seems to work decently well for now, but adjustments will surely need to be made in the future. Added a timer and health bar to a building that is being built just to make it a little more snazzy and intuitive. Sprites and visuals are at a bare minimum, will create proper buttons and hover text shortly.

12/31/21:
  • Started polishing building creation code, making it more robust. Still have some kinks to iron out... like being able to send multiple workers to the same build zone - effectively "stacking" buildings on top of each other (not okay).
  • Added a "game messages" system to display things like "not enough of X resource", or "too many things trying to be made at the same time" and so on. Only issue is the "messages" can stack, so you can see the same message over and over again if you happen to keep doing the same thing to produce that message. For now, I capped the message's list to a size of 5, that should be good enough for now.
  • Reformatted and simplified buttons and their hover text, fixed typos, created hover effects for each button (well not really, but the others are extremely simple. All I need to do is add button1_color = c_silver; but for each button).
  • Minor bug fixes.
  • Started working on destroying a resource when it no longer has anything left to collect, should be relatively simple to implement.
  • Made the devlog more readable.

1/1/22:
  • Encountered a bug when creating a new type of unit, if you select the "worker" and anything else and then try to build something with a worker - the game gets extremely confused and tries to send the other unit to build a building instead, and then throws an error because they aren't supposed to be able to. This has been mostly resolved - still ironing out some bugs but it is 90-95% functional.
  • Units mostly move out of the way if you tried to build a building on-top of them, I tinkered with an interesting idea of having them dynamically move out of the way BEFORE you try to place a building but I think that would cause way too many potential issues down the line so I scrapped that idea.

1/3/22:
  • Added 4 more buttons (from 5 to 9 buttons).
  • Added a toggle-able debugger that shows a ton of useful information to the screen.
  • Started working on creating actions for units that are able to attack, and creating a system of upgrades for different buildings and units.
  • Implemented health bars for units and for buildings.
  • General brainstorming (^ . ^)
1/4/22:
  • While implementing a system that increases the gather rate of a resource when more than 5 units are gathering the same resource, I found a glaring issue. I realized that every time a "worker" unit goes into a "resource node", the alarm gets reset. Further, if a worker goes from returning a resource to collecting it again - the next workers will never come out of the resource. I didn't notice this before because the timing was just right for it to work, I'm glad I checked this more closely.
    • The problem was fixed, I gave the resource controller a variable called collection_time and that is what the controllers alarm will be set to (depending on the resource being collected).
    • To make sure it is only set when needed, I added the simple check of if(alarm[0] <= 0) .... Further, in the alarm[0] code I added if(ds_list_size(collecting) > 0) ... alarm[0] = collection_time;. This ensures that the alarm is only changed when a "worker" leaves the collecting phase, instead of every time a worker enters the "collecting" phase.
    • If no workers are using the resource, lists are destroyed.
  • Ensured that the buttons are perfectly aligned to where they need to be, used a method of calling show_debug_message() to display the x / y coordinates (based on the GUI layer) when the middle mouse button is pressed. This made it so I can easily check and change GUI coordinates.
  • Removed lazy code and got rid of all "magic numbers", used macros where reasonable, otherwise local variables - increase in FPS has been noticed.
  • Re-designed the way the "production line" is drawn, instead of using a long list of if statements, I used just one for loop to draw the entire thing properly.
  • Units will now add themselves and remove themselves from a "selected" list, as well as remove themselves from the "collecting" list for a resource if they are no longer doing so. These checks are ONLY made when the unit is told to do something other than what it is already doing - this makes it extremely efficient.
1/5/22:
  • Added a system that displays currently selected units, up to a maximum of 8 at a time. Looking to add "control groups" in the future, shouldn't be too bothersome.
  • Expanded the actions available to the "Worker" unit: Able to cancel a building before it has finished being built, added buttons and sprites for this action.
  • Expanded resource abilities: Able to remove all "Worker" units that are currently collecting the resource, added buttons and sprites for this action.
  • Expanded building abilities: Able to cancel the last unit in the queue (this was implemented before, but it broke and now it is fixed again).
    • Canceling building or a unit in the queue returns spent resources properly.
  • Added more shortcut keys for: Cancelling a unit being produced, cancelling the building of a building, removing all "Workers" that are currently collecting a resource.
    • Added button text to indicate the shortcut key (escape).
  • Note: Need to re-format button text due to UI re-designed, need to come up with a way to display the "hover" text of the buttons, currently it draws a rectangle but the positioning is a bit wonky with the new UI - coming soon.
  • In general: cleaned up code, removed old comments and commented out code, added new comments where needed.
1/6/22:
  • Fixed display for selected units, the list now properly displays the units that are selected. Fixed with: ds_list_add(global.selected_0_draw, id.sprite_index); and reading from this list in my draw_portraits() function.
    • Also added a check here to make sure no more than 8 units are displayed at once.
  • Added a check that ensures only 8 units can be selected at a time, the first 8 that are selected will be added to the selected list, all others will be de-selected.
  • Added a short timer in case a unit finds itself unable to find a target, it will then return to idle and display an error message instead of infinitely trying to find a target.
  • Added a variety of debugging tools to help improve bug fixing in the future.
  • Made it so workers cannot be selected while they are returning a resource (inside of the hub), and their build menu is disabled during this time.
  • Workers now properly remove themselves from the selected list upon entering a resource node.
  • Resources now display different messages depending on how many workers are currently collecting from it... "Collection Speed: Normal / Moderate / Slow / Very Slow / Abysmally Slow".
  • Ran into a bug with workers building a building, when they try to exit the building spot it becomes fairly unpredictable where they will end up - and they can even end up in places where they will be forever stuck.
    • For now as a temporary fix, the worker simply gets destroyed after it completes a building. I'm not opposed to this mechanic but if I can figure out a consistent way to have them re-spawn properly after completing a building... I would much rather have that be the case. My idea is to just force buildings to be at least 1 cell away from each other so an available space will always be there... but not ideal.
  • Changed the font to be more fitting, change some text colors to yellow because it looks way better, added the "carbon count" aka "food limit" to the top left corner of the GUI (looks pretty interesting, may tweak it again later), and fixed the button hover text so it creates a way better looking box with information in it such as cost of building a building and stuff like that. End ramble :p
    • Images added below.
1/8/22:
  • Created sprite for the "Hub" and the "Ether Resource" and "Dark Matter Resource" (Will likely be edited and changed again in the future).
  • Added ability to upgrade the "Hub" to the next tier.
  • Fully implemented health bars for all buildings, only drawn when selected.
  • Started working on health bars for the list of selected units, as well as the ability to selected a single unit from the list.
  • Workers are officially "consumed" when building a building, with a warning if it is your last worker... you use all of your workers and do not have enough to train anymore? You're going to lose ;)
  • Fixed various bugs with selecting units, if you quickly selected a worker as it was starting to build a building - the menu would pop back up and you could instantly have it teleport to where you click without losing any building progress... this has been resolved.
    • Also fixed an issue where sometimes an error would occur if you tried selecting units quickly, it would either crash or not know what you had selected (ie, even if you had a worker selected, you couldn't build anymore).
  • Added a check to see if buttons and their hover text could be drawn to the screen or not (ie, if a worker is returning a resource... probably shouldn't be able to try and build something etc.)
  • Starting working on being able to upgrade the worker units (speed, health, how many resources it can recover each trip, armor).
  • More various minor bug fixes, almost at the point where I feel like I have done enough testing and fiddling to move onto the next major steps... developing a goal for the game - campaign levels, computer AI, then dialogue, then sprites, then sounds, then offline matches, and maybe eventually player vs player).
1/11/22:
  • Took some days off because I was feeling a bit stuck.
  • Overhauled a lot of the code so far, created functions for code that kept repeating itself... such as adding messages to the "game messages" list as well as a new list that I created which I am quite happy with (for the most part) that creates a cool effect for when you spend or gain resources. This feature will be highlighted in a video coming shortly.
  • Fixed a plethora of bugs associated with having building a building hidden under a "sub-menu", as well as some other bugs that popped up along the way.
  • Fixed a bug with collection time for resources, if the resource went from "normal" collection time (8 or less workers using it at once) to "moderate" etc.... and then back below 8, the collection time would still resolve as if it were more than 8. Basically, if too many workers are trying to collect the same resource it is supposed to be slower, but if it went too high then back to normal... it still decided it was too high.
  • Went through a lot of the code for buttons and their hover effects, I have realized that this mechanic is insanely annoying to code and I need to come up with a better solution to make it more streamlined.
  • That's about it for now, lots of ideas to come in the near future as well as a video!
1/13/22:
  • Started work on units being able to attack each other, both if the player clicks on an "enemy" unit or if the enemies units have gotten to close to the player units, they will automatically aggro.
    • Need to fine tune this mechanic, it is a bit clunky but it works at the very least.
  • Found anotherbug that I cannot seem to recreate, for some reason a worker decided to never stop trying to build a building... not sure how else to describe it.
    • I think I found the issue in the code, one of the checks to see what worker was trying to build what and where was being overridden in a piece of code that I have changed, but forgot to remove this part from it. Hopefully that was it.
  • Begun work on expanding the resources available to be collected, for a maximum of 4 different resource types with increasing rarity, and expanding usage.
  • Begun working on adding more building types and upgrades.
  • Started basic implementation on "win" conditions, ie. what needs to be achieved to win the level/defeat your opponent? Hint: It is not by destroying all of their buildings and units, although... you could do that too, but it will be quite difficult to pull off.
  • Begun work on basic enemy AI, mostly theoretical at the moment - I want to make sure that my plan is very clear before I start doing anything major.
  • Starting messing around with making tiles so I can make levels that look interesting, instead of just a gray background.
  • Unit movement speed is now individual to each type of unit, and can be upgraded (the buttons and costs associated with these upgrades has yet to come).
  • Updating the YouTube video in a further post. :) Stay tuned
1/14/22:
  • Spent a disgusting amount of time working on an idea I had for the soldiers attack animation… and I ALMOST figured it out. The idea is for it to generate a lightning bolt towards its target - which I have done using an array and “random” numbers to dictate the direction and length of each segment of the bolt. This works amazingly well, the main issue I am having is that the lightning bolt will rarely (visually) look like it is hitting its target.
  • Made all units able to share the same basic attack code and alarm (for their individual attack speeds). Individual attack mechanics can be added to their step events and called using unit_attack(id, attack_rate, target).

  • Otherwise, slow and steady progress lately. Family is visiting soon and the next semester starts up this Wednesday, so I have been busy preparing for that. Bah, doesn’t life know I’m trying to build a game here?! The audacity!
1/15/22:
  • Made final tweaks to the "lightning" attack of the "Photonic Soldier" unit. Added a GIF in the below post under the "GIFS" spoiler! Spent a lot of time perfecting this, it is done by using the path it is already trying to take to its target and drawing a bunch of randomly offset lines based on that path. It also has a little particle effect to make it a little more interesting to look at!
  • Finally implemented something that makes it so you cannot build a new building over a building that is currently being built.... or is planning on being built. Man that's a confusing sentence, so let me break it down.
    • Before:
      • When you sent a worker to go build something, only the target cell for their movement was marked as "occupied".
      • This made it so you could quickly take another worker and build something right next to where the other worker was going to build something - making them overlap when they were done.
      • You could also do this while a worker was building a building, you could build on top of it (if the building was bigger than 1 cell at least).
    • Now:
      • When you send a worker to build a building, it "occupies" a rectangle based on the size of the sprite of the building that is going to be built.
      • This makes it so no other worker can attempt to build something there, because they cannot path there.
        • Need to have a check for this so the player can visually see that they cannot build there.
        • Completely changed around how this whole check works, my code and how I changed it can be viewed below under the "CODE" spoilers.
      • If you move the worker before they reach the build site, the rectangle is cleared.
      • If you cancel the building of the building while it is being built.... the rectangle is cleared.
1/16/22:
  • Cleaned up some code (as usual), and fixed a few bugs (such as workers being spawned from the "Hub" could accidentally find themselves collecting a resource, but doing so automatically which obviously would create huge game balance issues - this has been ... i think ... resolved).
  • Sort of made it easier to add button text, but it is still more of a pain then I would like (because you have 9 buttons, and each unit, building, etc. needs its own hover text, so it is A LOT to write).
  • Started writing the AI for the opponent, man, this is a massive undertaking.
    • I have created some basic controllers to handle things like movement - but otherwise, I need to create a more solid game plan for how I want to handle this task before I go diving head-first into the void. ANY SUGGESTIONS ARE WELCOME!!
      • Side note: I wrote my scripts in such a way that the enemy units can use the same exact scripts as the player units, which is nice.
  • Small roadmap for AI development will be added sometime in the next week or so, school starts Tuesday (engineering) so I will likely have less time to work on this project, but I will still twiddle away as I can. :)
    • In light of this, I quickly added a variable that determines if you (the player) or the enemy has workers gathering a resource, and if you currently have units gathering the resource or no one is gathering the resource, you can collect it - otherwise, you cannot.
1/19/22:
  • Added: Including basic functionality for all listed below (placeholder sprites only)
    • Electron Swarm unit
    • Capacitor building
    • Energy Plant / Station building
    • Anti-Matter resource node
    • Uranium resource node
  • Expanded functions for drawing resources to the screen to include all resources (before it was just Ether and Dark Matter because the other two didn't exist yet).
  • Fixed up code for the Buildings parent object to only include things shared by all buildings.
    • For example: not all buildings can produce units, so not all buildings need unit lists for production lines.
  • Begun coding checks to see whether a worker has the proper upgrades to collect anti-matter and uranium - successfully does not allow them to collect the resource without the upgrade.
  • Added all missing shortcut keys and button text where appropriate.
  • Almost finished drawing health-bars for selected units as well as enemy units.
  • Added enums for upgrade types
1/20/22:
  • TODAY was a doozy, for whatever reason a plethora of bugs started popping up... My source control is a nightmare of "add this, remove that, change this - everything is the same as before but it doesn't work???"
    • I added a new building, and now every time I used a worker to build ANYbuilding the squares that were supposed to be occupied were not filling correctly.
      • What I mean is, if the building had a size of 3x3 cells, it would fill 3x4 cells or a 1x1 building would fill 2x2 cells... it was really weird and inconsistent.
      • I have NO idea what was causing this, but I changed the code and it works now?
        • Instead of using sprite_height etc. I now use sprite_get_height();.
        • I don't understand why it would work sometimes, and then not work other times, and then sometimes just flat-out refuse to work at all...
          • But using the built in functions has been MUCH more reliable so that is what I shall use.
    • Another bug with building, for whatever reason building the transformer and ONLYthe transformed would throw an error "object 17 does not exist" blah blah blah.
      • This made no sense, none of the code that it was flagging as an error was referring to an object...
      • Nonetheless, I fixed this too.
    • YET ANOTHER BUG where if I changed or added ANYTHINGto the game, everything would stop working the way it should and I would get a multitude of errors...
      • Yes I cleaned the game, no it didn't do anything.
      • Yes after deleting the new object or sprite or EVEN A NOTE OR A DOUBLE // ..... the game would work again.
        • WHAT?!?!?!?!?!?!?!?!?
      • Either way, this issue was fixed (thank you source control) by simply importing the entire game into a new project (if anyone has any idea wtf was going on please report back).
    • AND YET __ ANOTHER __ BUG __
      • The ID of the first worker you selected was no longer updating, so you could click on a worker, click on different worker and then try to build something.
        • The FIRST worker that you clicked would go to build, not the one and only one that was selected.
        • Fixed but it is not ideal, because technically the first worker you selected (of a group) is not going to be the one you build with... it will be the last one you selected.
    • On a happier note..... :)
      • I added health-bars to all enemy units, and to make sure that the game doesn't panic, they are ONLY drawn if the enemy unit is within the camera view.
        • Just a simple check if the b_box is within the camera view.
1/22/22:
  • Added basic pathfinding to enemy units, they just pick a random amount to move and a random direction to go.
    • This is just for testing purposes, to make sure that the movement code works for enemy units as expected (it does :0).
  • Re-oriented the way that units path to an attack target.
    • Before they would just set their target to the attacking targets current (x,y) position. While this works, it's not ideal because they will constantly find a target that is behindtheir target (if the target is moving at least).
      • Now, since all units use the same basic pathfinding scripts... their path target when attacking a unit is set to that targets next (x,y) position. Basically they "predict" where they will be next so that they can properly follow their targets.
      • Not only that, but now if they are within range of their target they will stop moving - I have done this so units do not try to keep moving as close as possible to their target.
        • This is even more important for units with a ranged attack, they only move towards their target if their target is out of their range of attack... otherwise they would keep getting closer - thus eliminating the point of having a ranged attack.
  • Decided I had way too many things in the "controller" object, and have created a struct to hold all the good-ole global-scoped variables and what not.
    • Will likely eventually move all of the scripts into their own struct with constructors to keep it all tidy and in one place (and because performance?).
  • Put game messages back into the middle of the screen, just below the resource indicators.
    • Changed the color to be more red, to command your attention!
  • Made is so a worker building a building doesn't have to be clicked on to view the buildings progress... now you can click anywhere in the building zone and you can see the progress.
    • This is because the workers image_alpha is just set to 0 while they are building, and if they are selected it will display the building progress bar.
    • However this is not intuitive, because you cannot see the worker and if the building is bigger than 1x1 cell you may not think to click directly on the center to view the progress (where the worked technically is while the building is being built).
  • Added a video to the "Videos" spoiler to give you a peek into the "chasing" behavior when trying to attack a unit (Worker attack animation hasn't been done yet, it's just a tiny placeholder for now so I can visually know that they indeed have attacked).
1/26/22:
  • Added a dynamic upgrade system for the Hub (expandable to anything really) that allows it to be upgraded up to 5 times.
    • Added sprites for some buttons associated with upgrading.
    • Added ability to upgrade workers speed (from 3 to 4).
  • Changed the way that building production lines work, it now properly sets the production time no matter what is next in the line.
  • Added 4 more lists for buildings....
    • A list to keep track of how much each type of resource is being spent when training a unit, so if you cancel it, you get the right amount back.
    • This seems cumbersome, although I wrapped it fairly neatly in its own function... you just call cancel_last_in_q() and it does everything for you.
  • Fixed a movement bug...
    • Previously when units were finding a path, their target cell would be marked as occupied so that no other unit could path there.
      • See the problem? If you had 5 or more units selected and you set them to path near an enemy, they could block the enemy from moving.
      • Obviously that's extremely broken, being able to block unit movement from all the way across the map would be ridiculous.
    • Now, they still mark their target cells as occupied but only for the frame or two that they are calculating the path, then the cell is cleared again.
      • To double up on this, a unit will automatically re-path if the next cell is occupied to prevent any two units from overlapping.
        • This is done because now the target cells are not occupied, so before the unit arrives that cell is "clear" so you can path to it....
  • In general: Lots of small fixes, improvements, code cleanup, and slight performance modifications.
    • Adding sprites and stuff slowly but surely, and making sure basic as well as unique functions associated with each type of unit and building are being added.
      • It can be a lot of work, and a lot of fiddling due to how many things need to be considered at once - which is why I have been mostly working on compartmentalizing my code so it can be re-used very easily and modified when needed.
  • That's all folks, slow and steady wins the race!
  • Late night edit: Wouldn't you know, something else broke with my new movement implementation (but it was an easy fix).
    • If a worker was returning from a resource that was recently destroyed, they would get stuck under the Hub that they were returning the resource to.
      • This was an easy fix, in the code that determines whether or not the unit should find a new path (when the next cell is occupied) I just added a check to see whether the worker was in the "return_resources" state, if it is, ignore the code to find a new path!
1/29/22:
  • Small update for now, with a massive update coming soon (will make a separate post about it which will contain details about what the game will end up becoming because for most of this time I only had a vague idea, but now that idea is much more concrete).
    • Now you may only build in an allotted area, which can be expanded after reaching certain milestones and doing the proper "research upgrade" in your Hub.
      • This area is a flashing green rectangle and that be toggled On/Off with "Z".
1/30/22 - 2/2/22:
  • Began making the transition to using lightweight data structure as opposed to the build-in data structures (such as ds_lists, maps, etc.)
    • Implementation can be seen in the "Code" Section.
    • This is 99% done.
  • A lot more information to come relatively soon!
2/3/22 - 2/12/22: A LOT
  • Implemented a brand new game mechanic -> Carbon Tax: Every ~2 Minutes the game automatically collects a tax based on how many units/buildings you currently have.
    • Created a rough visual for this (can be seen in one of the videos).
  • Created an automatic spawn point system that creates the player and the enemies -> Location can be done randomly or at specific locations (per room).
  • Spent a lot of time converting to the new system of lightweight data structures using structs and constructors. That's a lot of confusing words.
  • Updated my button hover mechanic to split it into different functions for each building / unit that needs its own button hover.
    • In this way, if nothing is selected that needs a button no scripts run and the call is ignored.
    • Further, it is much easier to keep track of what is what and what goes where.
  • Workers now keep track of how many and what resources they are carrying
    • Before if you moved a worker after it collected a resource... as far as the game was concerned, that worked was never there in the first place.
    • Further, workers change colors depending on what resource they are carrying.
    • Silicon / Copper / Silver / Gold
  • Added quite a few new sprites and well as updated some old ones - taking a new direction with the game.
    • I bet I will change everything again before I am satisfied, I'm not 100% sure exactly what I want everything to look like.
  • Adding all the buildings to the workers building menu and added hover text for all of them.
    • Needs to be tweaked still (with exactly what is written at least, the code is fine otherwise).
  • Added a function called check_costs() which returns true if the player and or enemy has enough to build something and false otherwise. I did this because this check needs to be done for a lot of different reasons, and having it all wrapped into one function makes it way easier to write.... One line instead of ~ 70.
  • Made a struct that keeps track of what upgrades the player has taken / researched.
  • Added functionality to be able to shift_click and select more units without de-selecting what you already have selected.
  • Removed everything from the font that I use to display costs except for numbers, periods, and the +/- symbols.
    • From 256/128 to 64x32.
  • Added "instance-culling" but instead of deactivating instances they just aren't drawn anymore when they are off screen. Deactivation would have caused to many weird problems and would have needed way too many different things to keep track of.
    • Ultimately, it works and does save FPS -> the deactivation solution is more trouble than it is worth in this case.
  • Underwent massive optimization for all units, especially the way they handle path-finding behaviors.
    • Before: ~100 Units and the game was impossible to play, frame-rate was ~10 and it was unbearable.
    • Now: Over 400 units, most of them pathfinding or engaging in other behaviors, FPS was steady and consistent.
    • How did I do this?
      • Well, before each unit was under an umbrella parent object which contained all of the code that they used for just about everything they could do. This includes pathfinding.
      • Now, each unit is still under a parent object but that parent object is blank and contains no code. Instead, relevant code to each unit is contained in a struct which stores and keeps track of the information that is shared between each unit.
        • Specific units have code contained within their own objects.
        • This struct also keeps track of pathfinding behaviors, storing all path data in an array that is apart of their struct.
  • Added a minimal minimap as well as changed the UI layer a bit.
    • Now the first selected unit or the selected building displays its portrait as well as information about that unit/building.
    • The new UI layer can be seen here!
  • Fixed the way units were drawn to the screen while they were selected.
  • Changed it so my add_resource_msg() script doubles as a way to increase or decrease the amount of resources the player / enemy has.
  • Various minor bugs that came up along the way have been resolved, turns out when you entirely switch the way your system works.... some things stop working as intended!
    • Thankfully they were all easy fixes.
2/19/22:
  • Minor tweaks to the movement/pathfinding system to make sure units do not overlap. It's a very simple and intuitive approach, which means it does not look perfect. But heck, it works really well and does not cause any major performance spikes! You can see this new behavior in a following post under the "GIFS" spoiler.
  • Been doing a lot of work trying to convert my game to an isometric perspective, which I have ultimately decided is way too much of a hassle.... (sad) ... instead, it will be a forced isometric perspective by which the sprites will be drawn isometrically, but everything else will remain in standard coordinates.
  • Always tweaking, always changing, always coming up with new ideas! I think once I get this next idea fully figured out - you will all have something really cool to look at!
    • PS. If anyone actually reads this, PM me and I have a surprise for you (and you're a legend).

What We Have So Far:
Note: Some features are changed to make testing easier, such as resource costs and build times - if you are interested in the actual numbers I will post them as a part of the development log.
-- You can see more information in the next post --

(Sorry my videos right now are somewhat long, and not very interesting - they are purely for documentation purposes at this point!)


THANKS FOR LOOKING!
Prrz
 
Last edited:

Prrz

Member
Misc.

// Note: For some reason these imgur links do not seem to show up on the forums, so instead I have added links to the images... Please click them to see! :)
// PLEASE NOTE: If you decide you like what I made (which I doubt) -> sprites are for personal, non-commercial use only!
*** NOTE *** MOST OF THESE ARE STILL JUST IDEAS, FEEDBACK IS VERY WELCOME!
RESOURCES:

  • Silicon: Used in nearly every computer component, widely available and easy to collect and store!
  • Copper: Extremely vital component for anything that requires electricity: highly conductive, and fairly plentiful.
  • Silver: Somewhat rare, used for circuit boards and advanced computer chips.
  • Gold: Rare, expensive, but extremely useful. It is the best resource for relaying accurate and fast information between components, and is required for everything beyond the most simple.

BUILDINGS:
  • The Central Processor: Your main base, where everything is handled, stored, and computed.
    • This is where you train your "workers", upgrade your "workers", and deliver many commands to all of your other units.
  • The Power Supply: Needed to build more units and buildings, can be upgraded to be more efficient or less costly.
  • The HDD: The Hard Drive is your main data center, this is where you can upgrade certain units and even expand your build-able area.
  • The SSD: The Solid State Drive is a faster and more aggressive data storage center, allows even further upgrades.
  • The RAM: The Random Access Memory dictates how much you can upgrade just about any other "building" that you own.
  • The Motion Sensor: Place this anywhere on the map to scout what the other team(s) are doing.
  • The Resistor: Place this down to help protect your units and your buildings from harms way.
UNITS:
  • Electron Infantry: Your primary offensive unit, capable of many tiers of upgrades.
    • Electron Soldier, Knight, General.
    • Specialization into Gold conductivity.
  • Voltage Discharger: Capable of ranged electrical attacks, can be upgraded to hit multiple targets.
  • Virus Injector: Every time this unit attacks another unit, it rolls for a chance to make that unit "frenzy" and attack its own team. Can be upgraded to slightly increase that chance.
  • Watt Disruptor: "Siege Unit", does heavy damage to buildings and can be upgraded to decrease the enemies available power (while idle and close to a Power Supply).
  • Hertz Manipulator: Attack has chance to cause confusion, causing the target to start trying to find a random path (so if you're not paying attention, this unit is going to go somewhere you probably didn't want it to go).
~~CODE~~
NOTE: This is not the entirety of the code, but only relevant portions.
// OLD CODE FOR CHECKING IF A BUILDING CAN BE PLACED
// sp_h is the sprite height of the building
// sp_w is the sprite width of the building
GML:
var in_rect_resources = collision_rectangle(mouse_x - 0.5 * sp_w,
                                                mouse_y - 0.5 * sp_h,
                                                mouse_x + 0.5 * sp_w,
                                                mouse_y + 0.5 * sp_h,obResources,false,true);


var in_rect_buildings = collision_rectangle(
                                            mouse_x - 0.5 * sp_w,
                                            mouse_y - 0.5 * sp_h,
                                            mouse_x + 0.5 * sp_w,
                                            mouse_y + 0.5 * sp_h,obBuildings,false,true);

           
var in_rect_units = collision_rectangle(mouse_x - 0.5 * sp_w,
                                        mouse_y - 0.5 * sp_h,
                                        mouse_x + 0.5 * sp_w,
                                        mouse_y + 0.5 * sp_h,obUnits,false,true);
                                   
if(in_rect_buildings != noone or in_rect_resources != noone or in_rect_units != noone ) {
    can_place = false;
}
else {
    can_place = true; }
}
// NEW CODE FOR CHECKING IF A BUILDING CAN BE PLACED
GML:
var ds_grid = noone;
if(!ds_exists(ds_grid,ds_type_grid)) {
    var ds_grid = ds_grid_create(room_width / CELL_SIZE, room_height / CELL_SIZE);
    mp_grid_to_ds_grid(global.grid, ds_grid);
    var in_grid = ds_grid_value_exists(ds_grid,
                                      (mouse_x - 0.5 * sp_w) / CELL_SIZE,
                                      (mouse_y - 0.5 * sp_h) / CELL_SIZE,
                                      (mouse_x + 0.5 * sp_w) / CELL_SIZE,
                                      (mouse_y + 0.5 * sp_h) / CELL_SIZE, -1);
}

if(in_grid) {
    can_place = false;
}
else {
    can_place = true;
    ds_grid_destroy(ds_grid);
}
GML:
function lw_list() constructor {
    data = [];

    static insert = function(val, pos) {
        array_insert(data,pos,val);
    };

    static append = function(val) {
        array_push(data, val);
    };

    static find_last = function() {
        var size = array_length(data);
        if(size == 0) { exit; }
        var last = array_get(data,size - 1);
        return(last);
    };

    static find_first = function() {
        return(data[0]);
    };

    static del_pos = function(pos) {
        array_delete(data,pos,1);
    };

    static del_last = function() {
        array_pop(data);
    };

    static del_first = function() {
        array_delete(data,0,1);
    };

    static clear = function() {
        data = [];
    };

    static delete_list = function() {
        delete data;
        data = -1;
    };

    static size = function() {
        return(array_length(data));
    };

    static find_value = function(pos) {
        return(data[normPos(pos)]);
    };
    // THANK YOU FROSTYCAT FOR THIS ONE RIGHT HERE
    static normPos = function(pos) {
        var length = array_length(data);
        if (pos >= length || pos < -length) { exit; }
        else { return (pos >= 0) ? pos : (length+pos); }
    };

    static find_index = function(val) {
        var length = array_length(data);
        for (var i = 0; i < length; ++i) {
            if (data[i] == val) return i;
        }
        return -1;
    };

}
 
Last edited:

Stra

Member
Good going on the devlog. (Personally I write short telegraph-like points.)
Fingers crossed that you will see your project through.
How much code do you write per week? (1k lines is probably a decent average.)

Btw, added comment: in the UI, the zig zag production line might look cool, but as it is a production line I think a straight line would be clearer for the player.
 

Prrz

Member
Good going on the devlog. (Personally I write short telegraph-like points.)
Fingers crossed that you will see your project through.
How much code do you write per week? (1k lines is probably a decent average.)

Btw, added comment: in the UI, the zig zag production line might look cool, but as it is a production line I think a straight line would be clearer for the player.
Thank you!! I am very determined to see this project through, even though I know it is going to take quite awhile to get something fleshed out.

That’s an interesting question though, I haven’t thought much of how much code I am writing per week - but if I were to estimate I’d say anywhere from 500-1000 lines. The first week or so that was much higher though, it’s been mostly small tweaks lately to make sure everything works as intended before I move on and end up in the pit of “I wrote a bunch of new code and now my old code has completely broken”.

As far as your comment goes, I appreciate the feedback! I think you’re absolutely right, and I’m going to change that to something more readable - and add more buttons. I realized that even though the 5 button layout looks great, I’m definitely going to need more buttons!

I’ll update a post when I complete that if you’d like to take a look, and update the devlog as well (probably later tonight)!

cheers

Edit: New UI can be found in above post under "screenshots" spoiler!
 
Last edited:

Prrz

Member
Here is an updated progress video (which will also be in the first post of this thread).
  • Updated UI
    • For example:
    • "Costs" being displayed where the number of resources you have are. Both when you gain, or spend them.
    • Multi-layered button menus
    • Units in the "selected" area
    • Proper camera panning
    • "Game Messages" / "Warnings"
  • Updated button hover text and boxes
  • Shortcut keys being used
  • Health bars and building timers
  • Resource collection timers
    • As well as the display for how fast the workers are collecting them
  • Resource destruction mechanic (when it runs out)
  • Upgrading the "Hub" (with small bug found where it wasn't sure what to do at first)
  • Trying to select more than 8 units
  • Having the resource be the "way-point" of the "Hub"
A whole lot ;) See the dev-log for more details.
 
Last edited:

Prrz

Member
Added a new spoilers section called "CODE" where I will be periodically placing code that I think is worth sharing.
Added a GIF of the lightning attack I have been working on the last few days :)
 

Prrz

Member
Added quite a bit more information to the "Numbers, Units, Buildings, and Resources" spoiler up above. (Needs to be Updated)

Please note:
  1. Most of this has just been planned and not yet implemented, any feedback or ideas are welcome!
  2. This is an incomplete list, and more will be added to it as time goes on.
 
Last edited:

Prrz

Member
Added a short video to the "Videos" spoiler in the first post. This short video just shows the script that handles chasing and attacking a target in action, I will post it below as well! :)

// NOTE: Fps values in this video are quite low because I have the debugger on, which draws the cells in the grid... I had it on so you could see the paths being created and all that jazz. Here is a screenshot of FPS values without the main debugger on (after leaving the game running with stuff going on for ~5 mins):
fps.PNG


 
Last edited:

Prrz

Member
Another updated video on some progress, however it seems minimal a lot has gone on under-the-hood.

  • On the top right corner you can see a (currently) minimalist "clock" that is ticking, as well as two numbers: "Carbon" and "Predicted Tax".
    • What the heck is this? Every ~2minutes (time may change or vary) the game will "tax" you based on how much carbon you are currently using up.
      • This is your "carbon tax", where carbon is a measure of how much material you have used to create any buildings / units.
      • Where "Carbon" used to be the measure of how many units you can create.
      • Now your "Available Power" is your measure of how many units you can create.
  • What is this weird blinking green square?
    • That is the area in which you can build, and it can be expanded with certain upgrades and buildings -> up to a maximum size.
    • What's the point? To facilitate more strategic building placement, and to have a measure of how well you are doing vs. the opponent.
  • WOAH different sprites?!
    • See some of them here: Link to New Sprites
    • Yes, I have decided that the route I am going down with this RTS is that you are controlling the inner workings of a computer (with more details about what that entails to come in the future).
    • The little LED diode thingy as the building rally indicator is a personal favorite...
  • New Buildings:
    • Central Processor
    • Hard Drive
    • Solid State Drive
    • Power Supply (Fan)
    • Resistor
    • Motion Sensor (that has stayed at least)
    • Random Access Memory
  • Proper sprites and button_hover_text for each building, as well as text to display how many more resources you would need / what upgrades if you do not meet the requirements.
    • This will be slightly re-factored in the future.
      • Especially the costs, those are just arbitrary numbers that I have assigned for now.
  • NEW RESOURCES?!
    • Yup that's right, now the resources are as follows: "Silicon", "Copper", "Silver", "Gold".
    • Each resource node shares the same sprite at the moment, simply re-coloured.
      • This will change don't worry
  • What's up with the workers changing colors?
    • Well, each worker will change colors based on what resource they are carrying (if any) as a quick visual indicator!
      • The video also shows taking a worker away from returning a resource, and then sending them back to the Central Processor to return it.
  • Shift-Click unit selected.
    • Oh boy, good stuff!
      • Except maybe the minor bug when it comes to drawing the portraits in the bottom-right portion of the UI layer... but that should be easy to fix.
        • Fixed
      • I also want to have workers display what they are carrying while drawing portraits.
  • For the keen observer: Strange number in the top left of the screen?
    • That's just simply how many workers are currently idle, for now it just draws a number but the game does keep track of how many and who!
  • Oh boy... well, I used to use a large quantity of ds_lists to handle a lot of different information... such as...
    • Who is selected?
    • What kind portrait should we draw for who is selected?
    • Who/what is in a building queue?
    • What resource message (the scrolling text towards the top) should we display?
    • What game message should we display?
    • Who is collecting what resource?
    • If you cancel something in the production line, how much should the game refund you?
    • And... a few more.
  • NOW, everything has been merged to lightweight lists using structs and arrays oh my... it feels so much better.
    • Why? Because automatic garbage collection, faster iterations (which I have to DO A LOT to keep track of everything), and just general better re-usability.
    • I added the script to a post above, the function is called "lw_lists".
      • Thank you @FrostyCat for the normalize_position function... I didn't understand why my version of "find_value" wasn't always working until I saw his code here.
        • As well as the general idea for this whole lightweight_lists thing :D Many thanks for having that available as a resource to the community - it helped me out a lot.
  • And honestly, a whole lot more that I will add to the dev-log eventually, I have been tinkering away in my free time like crazy but have not had the time to properly update the post as well.
Addition Video: Stress test with a TON of units --> Some optimization needs to happen ;)

Thanks to @Karlstens I decided to do some quick optimization focused around the way units operate - especially when it comes to finding and maintaining paths. In the video you will see many units overlap and become stuck on each other, that is because I made the spawn-time for workers almost instant (for testing this) and my current path-finding scripts work under the assumption that units are not going to be stacked prior to moving to where they need to go, which is why they ended up stacked! I'm looking to add some simple behaviors to make sure that doesn't happen regardless, but for now it works and I would like to move forward with the game before over-tweaking the pathing behaviors!
 
Last edited:
Top