next »

[GoatSkulls]

Oh man, these graphics are great!

Thanks so much, Indecom!


Today we have a short gif of the map editor in action! W and S keys go up and down in the list on the left side of the GUI, and the number keys swap between the categories of tiles / objects, like Environment, Player 1, Player 2, etc. Left mouse press places an object/tile, and right mouse press deletes it.


Just puttin random things all over. In the future, the categories will have numbered tabs viewable on the top of the screen so you can see what you can place / what number keys do what.

Note: The editor uses tile representations to show what is where, which is why it is so blocky looking in this interface. When you go to play the map it looks properly as it should just like in previous gifs (i.e. mush grows fungus around it, everything smooths out / overgrows, and everything autotiles as normal).


It is super basic but has some interesting quirks that I think some might find interesting: If you do not place any units or buildings, you can place a 'strtpos' tile instead, which stands for Start Position. When each game starts, it shuffles these positions and assigns one randomly to each player, and then puts a tech there. In this way, you could cover the map in these as you please to have players start randomly within desired constraints. With island maps or ones with unequal resource distributions, this could get even more interesting and/or silly.

At present, maps can only be made for multiplayer, but this will hopefully change in the future. I will get a better perspective on it once I get to creating the data storage / save and load code for the maps, which is practically the only thing keeping it from being done at present.
 

Onward!
The plan is to post once a week from here on out in the form of smaller progress updates, though this might stretch to once every two weeks if my day job situation is particularly hectic. I will talk about bugs, feature work, or whatever else I am fiddling with at the moment. Everyone feel free to request stuff or ask questions, code, feature, gameplay related or otherwise! I am happy to talk about how all this stuff works under the hood.

[nova++]

Ohhh. I miss good old RTS games. I haven't played any in way too long... I'll be keeping an eye on this one.

And I concur with compliments on the art, I really love the look and the unique color palette. A commitment to keeping the entire game feeling visually like it comes from another time (sticking to a strict palette, keeping pixels on a rigid grid, etc) is always great to see, too.

[strobosaur]

This looks amazing! The theme, the graphics, the gameplay, i love it all Keep up the good work and keep us posted!

[GoatSkulls]

Ohhh. I miss good old RTS games. I haven't played any in way too long... I'll be keeping an eye on this one.

And I concur with compliments on the art, I really love the look and the unique color palette. A commitment to keeping the entire game feeling visually like it comes from another time (sticking to a strict palette, keeping pixels on a rigid grid, etc) is always great to see, too.

Thanks NovaSilisko! You and me both. I hope Starmush helps ameliorate your old-RTS yearnings a bit.

This looks amazing! The theme, the graphics, the gameplay, i love it all Keep up the good work and keep us posted!

Thank you strobosaur! It means a lot. I will indeed.


It was a fairly unexciting week in terms of development, but I fixed several lingering bugs along with a couple of new ones, most of which ended up being quite silly. Two standouts of which I have put below if anyone is curious.

The first of these was related to how units position themselves when they are created, or when they leave a structure. All they do is run a loop searching surrounding tiles in a toroidal shape (i.e. check a random distance within a given range at a random angle, are you hitting anything? Whelp try it again then) until they find a spot, or the search is exhausted (usually at 1000 iterations, more than enough of a sample given how small the total areas are I think). This works great 99% of the time, but I discovered something odd on the edges of the map-- when units were mostly blocked in on all sides and up against a map edge, they would actually hop off the map! There would then be a terribly fruitless and buggy effort on their part to try to get back into the map, which is of course bounded so they cannot get out (or get in in this case as well). This was odd to me because I had bounding code in all of their collision checks to ensure this would never be an issue(make sure your x is less than the width of the map but greater than 0, your y is less than the height but greater than 0 etc. before you hop to your new coordinates). After experimenting for nearly half an hour, I notice that they are indeed clamping their x/y position to map bounds... but not their FUTURE x and y position that they are supposed to be checking. Woops. So with a simple change in spelling (local variable 'cx' instead of 'x', the c standing for collision of course), the problem is banished forever.

The second bug was very strange indeed: I made a time travel gameplay gif at the end of a work day, but it was a tad too long and could have been made a bit better. At this point in time I worked on something else (probably campaign writing, I forget), went to bed, and came back to the game a day later. Windows update! No problem. My Lenovo is from 2006, but it runs Windows 10 alright somehow, if terribly slowly at times (all the better for optimization testing though, yes?), so it took a bit, restarted a couple times, and then I was clear to work again. I decide to knock that time travel gif out real quick before doing other things, and get everything set up for recording etc. I go ahead and get the gif going, cast the first part of the time spell, cast the second part, annnnnd the game reduces to a resolution of about 10px square, but enlarged to the point that it fills the screen. It does this consistently in all tested conditions and is easily replicable. Hurm. Nothing in the codebase changed, especially not the resolution handling / shader stuff that has been there for a while, and that I hadn't worked on or had to mess with for ages. The solution, that which took all of 30 seconds to think up using my well-honed at-least-10-year-old-underpowered-and-obsolete-computer intuition, was as baffling as it was potentially embarrassing: I highlighted the relevant shader code, CTRL+X'd it, CTRL+V'd it back in the same spot from which it came from, and the bug was gone. This stuff makes me question my sanity at times / place my beliefs in phantom computer goblins (colloquially known as e-goblins, in my brain at least). (In retrospect, and for the record, it was likely related to an ill-managed cache that was promptly cleared after this, as every one of the rare weirdo 'makes zero sense' issues that have crept up out of the blue have been eliminated in testing this way, and triple-checked/tested against previous versions of the codebase of course)


I thought I would post a gif illustrating how that multiplayer match ended that I posted a gif from earlier. It was a tad silly, and actually led to finding a wily bug in target prioritization in techs! You can see it exhibited when the unfortunate second player tries to attack the blue techs with their tech, with depressing results:


HER:Go attack them! TECH:'You got it!' *starts repairing the dome instead* *KSHOOM*

[litHermit]

This looks and feels awesome in every way! I too miss something in the vein of War1/2.
I'm really curious about the story/drugs aspect, aside the mushrooms aesthetic. If drugs are really prominent in the story - the name is really good, evocative of both mushrooms and brain-mush

How long is a multiplayer match on average (or rather what time-frame would you aim for with the finished game)?

[GoatSkulls]

This looks and feels awesome in every way! I too miss something in the vein of War1/2.
I'm really curious about the story/drugs aspect, aside the mushrooms aesthetic. If drugs are really prominent in the story - the name is really good, evocative of both mushrooms and brain-mush

How long is a multiplayer match on average (or rather what time-frame would you aim for with the finished game)?

Many thanks litHermit! I am glad you think the title is fitting based upon your observations. It is a carry over from the early roots of the game when it was a much sillier and smaller scale project, but I thought it was recognizable / potentially interesting enough to just leave it.

In regards to match length, it depends on the map! For instance, the map that I made the gif from is actually huge, but we ended up being randomly placed right next to each other, so it was a 20ish minute affair. There are some maps that are very small in which you must scramble in a very short period purely through proximity to your opponent, and some maps that have multiple parts to it, like beginning on isolated islands, and attempting to quickly navigate to a central continent via worms in order to establish secondary bases and explore / fight from there. The bigger ones could be an hour or more depending on what strategies folks employ / how seriously they want to play. In this sense, I want to provide for a variety of match times so you don't have to just do quick or super long ones. To this end there is a relatively even mix of small, medium, and large maps available for multiplayer.

[Ohmnivore]

This stuff makes me question my sanity at times / place my beliefs in phantom computer goblins (colloquially known as e-goblins, in my brain at least). (In retrospect, and for the record, it was likely related to an ill-managed cache that was promptly cleared after this, as every one of the rare weirdo 'makes zero sense' issues that have crept up out of the blue have been eliminated in testing this way, and triple-checked/tested against previous versions of the codebase of course)

Oh man, those are the worst. GPU/shader programming is in large part as frustrating/tedious as it is because of the awful tooling and all the black box things going on.

I had a case where I left for lunch, came back, and noticed subtle line tear artifacts in my application which suddenly started manifesting. I investigated for an eternity, I even swapped out the GPU for a spare I had lying around. Did plenty of reboots and other routine ceremonies we do to appease the e-goblins. Nothing helped.

Finally I re-installed the Nvidia driver (which had worked well for months - it was pretty much above suspicion), and that solved it. Was it thanks to a cache reset like in your case? Who knows...

[GoatSkulls]

Oh man, those are the worst. GPU/shader programming is in large part as frustrating/tedious as it is because of the awful tooling and all the black box things going on.

I had a case where I left for lunch, came back, and noticed subtle line tear artifacts in my application which suddenly started manifesting. I investigated for an eternity, I even swapped out the GPU for a spare I had lying around. Did plenty of reboots and other routine ceremonies we do to appease the e-goblins. Nothing helped.

Finally I re-installed the Nvidia driver (which had worked well for months - it was pretty much above suspicion), and that solved it. Was it thanks to a cache reset like in your case? Who knows...

Hah! Yup. I am embarrassed to say I am always a bit blindsided by anything related to shaders, but maybe someday I will have a firmer grasp on it. Driver issues are definitely a bit nightmarish on the older machine I work on due to the rickity cocktail of old/new things that it has running.


Past two weeks in summary:

-fixed a number of small issues in the course of the eternal bughunt (mostly boring underlying stuff like pause code discrepancies, gui stuff, etc.)
-created / animated several important assets related to chaotic dream stuff
-finalized some graphical tweaks / doodads and polish
-completed and playtested a couple of campaign maps
-completed a bunch of campaign writing / initial map comp
-did some informal recording and mixing on the side for sounds, mostly experimentation and brainstorming for several effects that I haven't nailed down quite yet

This notably brings me super close to having all the graphics done, barring some tweaks here and there related to fx and fancy stuff. This coming week I will be focusing on the campaign more, both in map composition and in editing the new writing I have completed.


Can't rightly post without a gif yes?


Enemy dreamers are particularly nasty in surprise assaults, as they can create a massive plume of acidic gas that burns everything it touches. By using more venium they may sustain the reaction if they wish, clearing units and eventually buildings from the area if they are not stopped.

[GoatSkulls]

Past two weeks in summary:

+completed playthrough testing of a campaign map
+finished a new campaign map comp. Still hammering out fine placements / vi through play
+completed designs for 4 new maps with distinct strategic themes related to breakouts and ambushes.
+fixed another couple of minor bugs in the pause system (dreamfires were being weird / lacking a variable)
+added a couple of changes to the vi system that allow certain attack cooldowns to be staggered in a more customizable manner (i.e. I can more easily make certain vi players a little more spaced out in their aggressions, independent of their overall attack/difficulty setting and their associated cooldowns)
+eternal bughunt

Progress has been pretty slow for the past month or so sadly, but I will likely have more time coming up soon to put more regular hours into it. Looking forward to it!

Apologies in advance for the 60 second long gif.

Creative use of the disease/spore dream (granted, it would have been more dramatic/creative if I had gotten away with the dreamer...). I use the debug interface to turn off the shroud once my lone units have been slain in order to illustrate how dangerous it can be to massed groups. It is a scary and effective manner of discouraging steamrolling / mass superiority in combat.

[GoatSkulls]

Hoo it has been a while. Holidays came around, then moving job locations combined / still is combining with a change in residence. Work completed for the past 3 weeks has primarily been writing and editing campaign dialogue, but the past couple of days have been spent on map comp. Nearing the halfway mark in the campaign! It will go a bit faster from here, as most of the later levels are already mocked up. The transitions between earlier chapters were what was taking so long thus far.

I have usually found that starting from the end and working towards the beginning of a story will often give you a better perspective on its strengths and weaknesses / where to look out for edits and comprehension problems in playtesting.

In regards to how the story is presented (apart from the mechanics of normal gameplay already exhibited, of course), your knowledge beyond your field observations stems from an automated internal deliberation between different components of the neural network of the entity. While it is not terribly pretty, it is a close approximation of how it will work in its final form. Stripped down like this, I hope to have the player focus on the words rather than the presentation. While it would be very easy to simply toss story at you as a player to help explain what the hell is going on, I have taken a different approach that ends up involving its own form of meaning outside of purely summarizing the upcoming gameplay; studying what is being said and how it is being stated is nearly as important as what your objectives are. More on this later. In the meantime:


Early dialogue when the system boots. Pressing up and down scrolls in either direction through the deliberation. When the game is paused during normal gameplay, you can review the deliberation at a much faster pace, showing entire segments with each key press. Also shown is the password for the current level you are on. More on the merits of passwords vs. save system at a later date.





This coming week or two is going to be lots more writing and level comp, so nothing terribly exciting to show visually. For this reason I think it is a great time to start going into code and how many of these systems work in the game under the hood. 'Til next time!

[GoatSkulls]

Today I will go into how the computer virtual intelligence (VI) works in most of Starmush at present.

Below is a visualization exhibiting the structure of the VI the CPU is utilizing when it fights against a human. For now, this system works best in the campaign, as player skill is more readily predictable, and the maps can easily have pathing built in that helps counter edge cases of players trying to cheese the computer into oblivion. This ultimately means it is far less work for me to make it function effectively. It can also work in unknown terrain / map editor maps, and can solve the most devious mazes of terrain to get at the player most efficiently, but it is presently very weak at base building and progression. For this reason, I will likely have to build a more robust and complex system if it is to function in a custom editor scenario environment.


The VI in STARMUSH! It is like a rainbowy primordial brain (brainbow).


Looking at it, it becomes readily apparent that I opted for a decentralized approach to VI, rather than try to script my way to victory like Warcraft I and II did. In those games, the CPU player was essentially following a series of commands from a script on a timer that matched its selected type, like LandAttack, SeaAttack, etc. Each of these was optimized to provide a generally challenging opponent if the terrain was suitable for its implementation, though they too were weak in the base building department. A simple shift in the placement of mud near a starting location for a CPU could mean the difference between a quick and murderous opponent and one that boxes themselves in in the first 5 minutes and grinds to a halt. While the building placement in my system is not super robust, it does help to provide for some edge cases that would otherwise trip up the CPU in normal play if they were playing strictly by a script.

Most of the descriptors in the diagram are self explanatory, though some of them are vastly over simplified. For example, the node certainly 'finds and evaluates build sites', but holy moly is there a veritable novel of code it has to go through to do such a thing. For this particular example it has to:

    1)figure out through checks that, YES, we need to build more domes to support our population

    2)check to see that you haven't already had this epiphany during the last cycle and added it to your job list

    3)double check to see that some tech hasn't already elected to take the job

    4)figure out if you want to site this thing independently, or grouped with others

    5)make sure the potential site is not colliding or intersecting with mud or anything impassable

    6)make sure the potential site is also not too close to any structures that produce or move units around

    7)make sure it is not directly in the path of any mines

    8)if all of this is cool, then place its x, y, and building type in the active job priority for techs

    9)THEN techs have to actually decide to take the job if there are enough resources etc.

    10)said tech swaps its active job to seeking a site / construction and tries to get to the site

    11)if the tech manages to find it, great, if it doesn't for a long time, it needs to figure out why / stop

    12)if the tech manages to survive the building process, also great, otherwise go back to step 9

    13)if we have gone back to step 9 more than a couple times, the player is probably targeting you

    14)if this is the case, try resiting from the beginning to find a less hostile spot

    15)only NOW, if the tech successfully built it, does it tell the Node, "we cool". And life goes on.

Outside of the more complicated processes like the one above, the decentralization of tasks really helps the VI stay focused on the important things in the game. Like for instance, if the player destroys a Node, and it was supplying Dreamers for attacks that an Assembly was requesting, the Assembly will carry on so long as it still has resources to draw on, but it will now operate on the condition that it no longer has access to Dreamers for Worm attacks, which will not affect it until it runs out of local Worms, of course. This helps to prevent complete crippling of the VI in single attacks. If a human were in such a situation, they would make the most of it. Having everything keep track of its own problems and solving them helps to simulate this in some fashion, super simplified as it may be.

Ideally I would combine this simple setup with master scripts to have the computer switch up on the macro level, though it is yet to be seen if I will get to such a thing, or if it is even necessary / worth the time. It is certainly tempting to think of, as there is a veritable wealth of variables at play that a computer could use to simulate counterplays, like checking the human player's resources against its own, and adjusting its unit composition or aggression to dynamically adjust, or simply taking an average of all unit death locations to figure out spatially where the fronts or chokepoints exist. The possibilities are truly endless and fascinating, but I think my janky little pooter brainbow will do for this game. Maybe in a future project.



In other news, I had a magnificent bug hunt this past week, and solved a couple problems that had been bugging me for over 5 months. I also got more writing done, and completed some sweet diagramming exercises for better organizing campaign progression and content. More on this later. Til' next time!

[Ohmnivore]

Thanks for posting the juicy details!
I've always been curious about RTS AI/VI implementations.

[qMopey]

Beautiful art! Following!

[bacon]

Oh man I seriously love the look of this! I do wish the fonts were more readable though, the pixel aesthetic is really cool for the map but it is kind of hard to read what the UI says!

[GoatSkulls]

Thanks for posting the juicy details!
I've always been curious about RTS AI/VI implementations.

Of course! I will make sure to go into greater detail on some things this weekend. I have always wondered about it too until I started making Starmush-- even as a youngin, I was always so fascinated / scared by the WC2 CPUs. Figuring out how to emulate and improve upon that sort of behavior has been an awesome learning experience.

If there is anything you are particularly curious about in regards to VI Ohmnivore, let me know! I will gladly cover anything and post code if you like.

Beautiful art! Following!

Thanks! Not coming from an art background, it is super encouraging to hear that.

Oh man I seriously love the look of this! I do wish the fonts were more readable though, the pixel aesthetic is really cool for the map but it is kind of hard to read what the UI says!

Thank you bacon! I am still on the fence about the font myself. The journey to get to / justify the current set was a bit complicated as far as type design goes at this scale:

I started making the graphics for the game, and realized that the primary font would have to be fairly small such that it wouldn't dwarf the average sized unit. With letters that are noticably  larger than a unit, the action seemed smaller overall after transitioning from a menu, and made everything else seem a little awkwardly undersized. Bearing this in mind, I set out to make the smallest possible font that is still legible, such that I could stick with the lofi-tiny-detailed type of art to match the rest of the game. Once I completed this particular font, I loved its aesthetic so much I kept it, for better or worse. The situation was also complicated by how fonts work at this size. Check it out:


The font currently used in game is the one on the top.

When you increase the width by one pixel (the 4x5 font), the even number means some lines are offset, like in the letters I, T, and Y. In a single word this looks okay, but I kept getting distracted reading a paragraph of it. Worse than that, the letters M and W are just as weird looking as they are in the 3x5 font, and V has now become stranger due to being an even number of pixels wide.

Moving up a pixel (the 5x5 font) brings us nearly perfect legibility, but at the cost of the slim DOS-like look I was going for. This might be the best option for increasing legibility though, as it would allow me to redesign UI elements without worrying about height changes. What do you think?

Increasing the height further (the 5x6 and the 5x7 fonts) brings us closer to the original proportion of width to height (3:5~0.6), but now we are so much bigger that it has affected how everything is placed and how the size of the units is perceived. This being said, we are also now pretty much at a size that allows double width lines, opening a whole new world of design possibilities.


I am eager to hear other people's thoughts and criticisms of this.

[qMopey]

Personally I don't mind the odd W/H/M in the 3x5 font. I think in-context it will make sense to most people. You will definitely have some trouble with localization to Japanese, if that's ever a concern!

You definitely have a clear interest in aesthetics. To me it looks obvious you could become a brilliant artist if you wanted to! Your game gives me a very oldschool C&C vibe, but the art direction and aesthetic design (and animations) you have are way higher quality than in the old C&C games.

Exciting!

[GoatSkulls]

Personally I don't mind the odd W/H/M in the 3x5 font. I think in-context it will make sense to most people. You will definitely have some trouble with localization to Japanese, if that's ever a concern!

You definitely have a clear interest in aesthetics. To me it looks obvious you could become a brilliant artist if you wanted to! Your game gives me a very oldschool C&C vibe, but the art direction and aesthetic design (and animations) you have are way higher quality than in the old C&C games.

Exciting!

I am going to add a lowercase / differentiated option in the settings menu just to make sure. While it is certainly stylistically consistent, bacon is right in pointing out that it can be hard to decipher, especially if there is a lack of context in some GUI elements. Adding to this, it is likely a nightmarish font for any individuals experiencing dyslexia. The lowercase version of the font should work much better, as every letter is distinct, or at least much more so than the all-capital thing I had shown. We will have to see what further playtesting reveals.

In regards to Japanese, it is interesting you should mention that, as it is the only language I can converse in and write outside of English (though I am certainly rusty from lack of interaction in recent years). While there would certainly be many other complications for localization that places it outside the scope of this particular project, it actually fits most of the GUI constraints already! The width of characters would be increased by 4 (bringing it to 7x7 or so), but otherwise the hiragana and katakana alphabets fit within those constraints with a bit of creativity. No kanji at this resolution though, of course.

Thanks for the kind words! High praise. I will keep at it.




For today, I would like to go into a virtual intelligence subject that I came into the project completely blind on-- one which I could find practically no writing or documentation for from the games i grew up on, outside of my own observations and code doodles:



RESOURCE FINDING / MANAGEMENT

In a normal campaign or scenario map, the computer VI is tasked with finding resources, harvesting them, and managing the associated jobs among the tech population. This is arguably the most important component to the enemy VI, as without resources, the computer cannot produce units or buildings, and would therefore be limited in the ways it could attack the player.

While it would be easy to simply give the enemy lots of resources and ignore it, or cheat a bit like the VI does in Warcraft 1 (if you were unaware, it harvests gold as normal, but it only takes a miniscule amount from the mine despite its peons dropping off the full load of 100! This extends the match and prevents the player from starving the computer), I wanted a slightly more dynamic response such that the computer can bounce back quicker, and in a believable fashion if set back, and to lay the groundwork for a more robust custom VI for future projects.

The resource management loop is essentially composed of three components:

+ a Node's basic goals / variables
+ a resource mgmt script to reach these goals
+ the techs' independent actions and communication to the Node

From the top, and in order of when they occur:

NODE-----------------------------------------------
1. Set the variables 'idealminenum' and 'idealmushnum' to the global values for this particular level.
Number of techs to do each thing. These are set per level, but can also fluctuate based on difficulty. Just like Warcraft / Warlocked, there is an ideal number of workers to shoot for based upon spatial constraints. Obviously the closer the computer is to this, the more optimally they gather resources. If they have too many workers, they might experience gridlock and have trouble doing much of anything.


2. Set up the idle list, and the mine and mush job lists to keep track of who is doing what.
Techs add themselves / delete themselves from these lists whenever they swap jobs.


3. Call nearby techs to you and add them to your idle list.
Simple check based upon distance to the Node


4. Set the interval for, and start the timer for tech / base management.
This determines how often the node checks what is going on. essentially shorter interval = harder VI.


RESOURCE MANAGEMENT SCRIPT-------------------------
5. If the idle list is empty, search for mines/mush tiles that are navigable.
Whether or not you find some flips a couple binary variables (minecheck and mushcheck) on or off. This determines a number of things, like whether or not you should bother making more techs at the moment, if you should try searching a different way etc.

It is pretty tough to determine if something is 'navigable' in code.

The way it tries first is to put an ID for each mine/mush in a list ranked by distance to the Node. It then takes the top one off the list (the closest, based upon its ranking) and runs the A* algorithm to see if an obstacle-free path exists between itself and the resource in question. The path is at a resolution of 14x14 (the size of a mush) and is therefore really cheap in terms of CPU in comparison to using a 7x7 resolution (the size of a unit).


The highlighted resources are the closest of their kind, and happen to be navigable. Note that the mush shown is the closest one to the particular tech that is being given the job (the one in the bottom left of the group).


If you are unfamiliar with A*, check out this resource: 

https://www.redblobgames.com/pathfinding/a-star/introduction.html

It is super useful, but also needs to be used as little as possible. While it is cheap in terms of CPU to run it every once in a while, excessive use will bog down the game. The techs only really use it when they are checking for a new resource that they don't already know is navigable. Even with hundreds of potential techs, their computations will rarely overlap at the same exact moment, so it works out nicely without bogging things down.

So if all went well with the Node, it will change the states of all the techs to their respective task.


They will then set out to find the resource they were given the ID of. More on how they handle this navigation in the tech section further down.


If the Node doesn't find a navigable resource, it needs to figure out a better method of navigation. There are obviously cases whereby the closest resource is not navigable for one reason or another, such as the following:


The closest resources are not navigable by A*, as there are solid tiles (shore/acid) in the way! This is a tiny map, and the river extends from the top to the bottom with no crossings.


When it comes to mines, it is easy to brute force through them, adding them to a list and checking if there are any that are navigable at all, as there are only so many mines you can fit on the average map, and the CPU cost is negligable. When it comes to mush though, things get a bit difficult. We could go down the list of nearby mush and simply check if each one is navigable, but the list for the average map is huge, even bearing in mind that only the edge tiles of mush are added as entries. We therefore need to space out the calculations and optimize the list a bit, as we don't want to be searching for every single dang mush on the map. The list is culled by distance to the Node within a reasonable radius (something like 150 pixels). Now the list is far more manageable and requires less calculations. It is good enough most of the time to catch edge cases such as the one shown above.


6. While the idle job list is empty, check your ideal numbers of workers for each resource, and assign jobs to techs based upon how many are working at each task
(i.e. if you your ideal number of miners is 8, and you have 6, that is obviously a job that is needed), with mines getting priority, as it is the resource needed for making more techs and prots. The tech given the job is assigned the ID of the navigable resource that is closest and they are sent on their way.

If there is nothing available or navigable, just chill out.


7. If resources exist that are navigable, and you are below your ideal numbers of assigned techs for a resource, make a tech!
Obviously you need to have enough remnants and food/population to do so.


8. Check your overall population and assign build jobs as needed.


TECHS----------------------------------------------
9. You have just been given a job, and an ID of a resource to find. Check your range to the resource, and if you are not touching it, move towards it.
Movement in STARMUSH, like Warlocked, is based upon a simple script in which the unit rotates until they are facing their target coordinates. Once they are facing it, they move towards it in a direct line. If something is immediately in front of them, they rotate several degrees and try again. That's it!**

If you are looking for mush, and you are still a ways off, but you are also close to an ally who is harvesting, just pick another that is close. This prevents techs from trying to get to resources that are blocked by other working techs, and allows them to spread out.

Once you get there, start harvesting the resource.

If the resource you are looking for doesn't exist anymore, find another nearby.


10. If your bag is full, return to the Node!
Once you get there, if you are holding more than one type of resource for one reason or another, just plan to seek out the one you have the most of. If you have a resource in mind already, leave the node and go find it. If you don't have one in mind, or the one you did have in mind no longer exists, look for the next closest and check its navigability.



**(Just using this means units are pretty unintelligent, and can get stuck easily around corners without guidance, but looking on the bright side as per usual, I always enjoyed micro and unit management over perfectly navigating units. It makes combat a lot more hands on, and makes certain things like building placement and the firespell dream useful as a defensive strategy in themselves. This all being said, the enemy computer is afforded A* for finding the player and making unit paths along with some extra prioritization/reprioritization scripts to make up for the fact that the player is capable of far better spatial micro.)





WHEW. Yup. Even simplified, there is a lot that goes into something that is super easy for a human player to do. I held off putting code here, partly out of embarrassment of my code quality, and partly out of mercy for how much there would be to sort through. If anyone wants any, just holler and I will put some up.

This week I finished up a lot of texture work, and solved several VI edge cases that had been plaguing the system I talked about above. The next several weeks will be real slow (up to March 10th), as I will be participating in a competition for the newfangled NESmaker tool that has been floating about. It is a nice little framework for making games in 6502 assembly, and seeing as how I have always dabbled a little bit in 6502, and that I love the NES, I relish an opportunity to finish a game demo that is playable on the hardware.

The current prototype I have cobbled together from my own scripts is a tiny game called MOMOC in which you are a combat engineer in a fantasy Meiji-era Japan. You have to get past enemy defenses by digging, harvesting materials, building, and platforming, and then destroy or steal certain things from different enemy fortresses. As of now, everything in the basic engine works except enemies and screen transitions. I will write a little blurb about it (hopefully with a gif or two) when I post next. Not strictly relevant, but it is certainly fun. Til' next time!

[GoatSkulls]

Long time no see!

Finished up that 6502/NES competition on March 10th (check out my entry @ http://nesmakers.com/viewtopic.php?f=51&t=2441 if you are curious), and have been back at Starmush working on level design ever since. Participating in the competition really made me rethink some of the campaign maps, and led to several revisions and additions.

This stems from the mining and building mechanics in my entry for the comp, as the limited space I was afforded forced me to pack as much learning, gameplay, and story into what is practically a 16x13 grid for each screens worth of puzzle. Coming back to Starmush after the absence, I was more perceptive of wasted space, as well as better potential means of mechanic teaching.

Obviously, this is a really good thing, and it exhibits why competitions and game jams are so important, even when in the middle of larger projects. They not only help in keeping things in perspective, but they can also yield lots of goodies and insight from other genres.





With this in mind, the past couple of weeks have primarily been level design / revisions, and more writing. Next couple weeks will likely be more of the same. Sort of in the doldrums in this regard with nothing super flashy and exciting visually to exhibit, but I think the levels will be all the better for it.



Also, in the next month or so I will be pinning down a release estimate, since I have passed the halfway mark on the main campaign, and have a pretty good idea of remaining time commitments at present.

[jb]

Project looks really cool. I like the unit special/magic stuff a lot and the rewind mechanic seems super unique. The idea of split screen in an RTS is very interesting to me - it is something that I have wanted to try before but it is hard to tell how well it will work. Will there be options for humans vs. cpu and interesting team compositions? You've inspired me to start thinking about RTS design again. How big is the unit tech tree going to be? It looks like quite a limited pool of units right now, is that by design or do you plan to expand it? Looking forward to being able to try your game!

[Sustrato]

Thanks for sharing the technical breakdown! I'm impressed you have the stamina to jump from full time dev into a jam and right back again. Keep at it!