Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1352669 Posts in 62406 Topics- by 54140 Members - Latest Member: reddarkwh

December 13, 2018, 10:17:47 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsCANTATA - Character-driven Empire Building [Advance Wars + Civilization]
Pages: [1] 2 3 ... 5
Print
Author Topic: CANTATA - Character-driven Empire Building [Advance Wars + Civilization]  (Read 10805 times)
bacon
Level 1
*


View Profile
« on: July 14, 2016, 03:30:10 PM »

CANTATA
A Character Based Tactics Wargame
programming/design by bacon, art by cobralad, design by munda, and writing by grayhaem



////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////

Latest Post




The Reign of Harmony and Prosper’s thousand-year peace lies in tatters and the galaxy is at war. With each day that passes, the empire loses more ground to a collective of sentient machines known as the Unified Spirit. Their only hope to turn the tide comes in the form of Shoal, an abandoned colony planet that hides a powerful and dangerous secret. Across the surface of Shoal, ten thousand guns sound at once. The keen of laser beams build, punctuated by the staccato thrum of orbital landings. A choir of voices rise as the armies of the galaxy’s oldest and newest civilizations gather for war. From the vast reaches of space, the chaos is almost musical—a symphony, drifting into the void.





CANTATA is a character-based tactics wargame inspired by a want for a synthesis between the immediacy and simplicity of combat and production in Advance Wars and the empire building feel of games like Civilization of Sim City. Players take the role of a Commanding Officer from one of three factions vying for control over a planet and work to spread their forces across a rapidly shrinking frontier. The game is being developed in Unity.

Gameplay is turn-based and centered around attacking/moving units, building buildings/units, and establishing supply lines.  The player takes the role of a commanding officer (C.O) in their selected faction, and sets out to build and establish a hold on a region of the planet in the middle of its turmoil. The goal is to build an infrastructure and standing army that can support a war against another player, players, or AI, leading ultimately to a victory by either territory control or player elimination.

Modularity is something I'm really striving for with this game. While the gameplay and setting are well-suited for each other, I really think the core mechanics translate well to other scenarios. In light of this, I'm designing the game from the ground up to be moddable, with an eye towards easy asset creation and integration via the Steam workshop. I believe in the game I'm making, but want to open up others to easily applying their own interpretations of what the game can be.




Media/Mockups




////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////

FOLLOW ON TWITTER @cantatagame
Tumblr Devlog (updated with devlog posts and WIP stuff)

I'm excited to finally bring the game to TIG after lurking for so long and keeping the game to close to my chest. I plan to keep this thread seeded with the latest devlogs, and expect Cobralad to posting his lovely WIP and final art in here from time to time. Thanks for taking the time to read this and I'm excited to hear any and all feedback!

« Last Edit: July 04, 2018, 03:20:26 PM by bacon » Logged

DireLogomachist
Level 4
****



View Profile
« Reply #1 on: July 14, 2016, 06:36:54 PM »

Looks fantastic, bacon! Loving the colors!

This world can never have too many tactics games  Hand Thumbs Up Left Grin
Logged


Living and dying by Hanlon's Razor
bacon
Level 1
*


View Profile
« Reply #2 on: July 15, 2016, 10:12:05 AM »

Looks fantastic, bacon! Loving the colors!

This world can never have too many tactics games  Hand Thumbs Up Left Grin

Thanks! The colors were definitely a big shift early in the process. We had initially sourced a lot of stereotypical cyberpunk images for reference, but then decided to just lean into a brighter palette after hearing what Jenny Jiao Hsia had to say about Beglitched. It definitely gives us a lot of latitude as well when designing COs.
Logged

Sitatop
Guest
« Reply #3 on: July 15, 2016, 10:53:10 AM »

Each individual character has an amazing palette, but combining them with another palette (like the terrain - image #4 posted) makes it just look slighty odd in my eyes as a whole. But each individual character sure looks amazing though!
Logged
bdsowers
Level 3
***



View Profile WWW
« Reply #4 on: July 15, 2016, 01:34:17 PM »

I do enjoy a brightly colored strategy game. As someone who's developed my share of somber, morose strategy games, the shift in tone is.... welcome.

How are you balancing combat simplicity with empire building? It seems like every step you make toward one is a step away from the other if you're not careful.
Logged

bacon
Level 1
*


View Profile
« Reply #5 on: July 15, 2016, 03:11:58 PM »

Each individual character has an amazing palette, but combining them with another palette (like the terrain - image #4 posted) makes it just look slighty odd in my eyes as a whole. But each individual character sure looks amazing though!

Thanks! And yes this is definitely something we're working on. We're trying to find terrain palettes that complement whatever palette the units that are on it have. This means likely having reduced color range for a given faction and work more in shades of a given palette color. That way we aren't running into overlap with shared colors and making units "disappear" against the terrain.

I do enjoy a brightly colored strategy game. As someone who's developed my share of somber, morose strategy games, the shift in tone is.... welcome.

How are you balancing combat simplicity with empire building? It seems like every step you make toward one is a step away from the other if you're not careful.

Thank you! Yeah the setting definitely had a doom and gloom sense about it and we had a ton of images initially pulled from places like otakugangsta and sink00. I think it was discovering people like Kilian Eng and Simon Stallenhag that made a huge difference. The starkness of the cyberpunk stuff was appealing, but seeing the color of these other scifi worlds made the the places seem so much more rich. We're also really story-forward with this game, so giving us more color really felt like it gave more latitude to tell a wider variety of stories and really make the COs/Units "pop". I'll have to do an "influences" post eventually Smiley.

In regards to the strategy, it's a constant balancing act! A lot of it really exists just in theory right now and isn't implemented, but the biggest guiding light is that things should feel like they "flow". No system is added to just be a "layer" on top of the game, it needs to have a reason to exist inside the context of the other actions and interactions you can already take. It ends up being a lot of subtraction, trying to get at the core of what makes something appealing in a grand strategy game and making it act on a level thats appropriate for something of a small scale.

Logged

bacon
Level 1
*


View Profile
« Reply #6 on: August 05, 2016, 02:20:57 PM »

The Battle Arrow



In nearly all of the tactics games I can think of, moving a unit is done by selecting a unit and then telling it where to go. In ISO TACTICS, this is also the case! It’s a great way to tell what path a unit will move along to get to a destination, something that is especially important when units must move to each tile along the way to a destination and not just teleport to their destination title.

It’s a great feedback mechanism and knew it was important for my game, but I hadn’t seen any good documentation of implementing it from back to front, so I wanted to take some time to talk about how I did it.

To start, you may have seen a hint of it in the last blog post (on Tumblr). Watch for the small yellow line that appears after a unit is selected:



You can see a rough implementation of pathfinding there, but to zoom out a bit before moving on, here’s that bit demonstrated specifically:



The biggest thing to notice is that, when I select a unit, it gives me a pathfinding arrow that looks like a a big “L-shape”. This was surprising to me, because I thought I had implemented the algorithm in question (Dijkstra’s) quite well and with a lot of help from Amit’s tutorial on A* over on his blog Red Blob Games (which you should definitely check out).

I was somewhat confounded, because my paths looked nothing like Amit’s nor the “diagonal” path that you get in something like Advance Wars or Fire Emblem. I ended up tweeting at Amit and asking him what was wrong, and he advised I do something pretty simple. Basically, when doing the step where you establish a movement frontier for the algorithm to crawl, check to make sure the tile you are about to add to the frontier as having come from your previous tile isn't in the same direction as the previous tile you added.

The “L-shapes,” despite their “ugliness” are valid paths. The frontier, before modification, would search for new neighbors to the North, East, South, and West (as it should) each time it reached a new tile. Because tiles would almost always have a tile neighbor to the North of them, nearly every tile would resolve to have “come from” a tile to the North or South of it. This means that the process of getting to any tile would be a combination of either East or West movement, followed by either North of South movement, never alternating.

But as we said before, that’s not what we want. We want those nice diagonals, even if tile movement is restricted to cardinal directions. What was confusing about Amit’s tutorial is that he does get diagonals, but obscures the parts of his algorithm that allow it. If you look closely at the breadth first search section, you can see a bit of what his underlying algorithm is doing.



In the above picture, the number in each tile represents in what order that tile will be visited to search for further neighbor tile. The 1, grey out above, was the first tile, the 2 to the east was the second, and so on. When a tile is visited (indicated by it being grey), new neighbors are added to be searched. So when the 1 tile was visited, the 5,6, and 7 tile were marked. If this is confusing, check out his page. The demo is interactive and you may be able to get a better sense of how it works.

Already though, there are oddities. The red blob, after it’s first placement, looks for a tile to the North, East, South, and West, in that order, indicated by the 1, 2, 3, 4. But even as tile 1 is visited, the neighbors are not added in that order! Instead we see that the next tile added is the tile to the East, 5, followed by West, then North. South is occupied by the reb blob, so it makes sense that it isn’t visited, but why wasn’t the tile to the North again the first tile?

This goes back to Amit’s suggestion. Internally, he’s checking to make sure the first tile to be visited in any new step is not also in the same direction the previously visited tile was to its previously visited tile.

So, when implementing the check:



Ta-da! We’ve now go diagonal movement paths. For those that know Unity though, you likely notice that right now the pathfinding indicator is just a debug line. This work great if you are testing internally, but I need an actual sprite line to show the path. So next, how do you stroke the line?

Well first, we need art. Cobralad sent me over some arrow sprites:



There are two ways to go from here, and I’ll admit I’ve chosen the easier one for now. To render a sprite on the screen in Unity, it needs to be attached to a GameObject. Right now I’ve got two options for this. Either make a new GameObject for each needed arrow segment, or leverage a preexisting GameObject to render to through a shader. I thought for right now it would be best to just implement the line through GameObjects to make the coding a bit easier, but now that I’ve got the logic in I can port it to shader code by leveraging Unity’s Material.SetFloat to point to a texture offset of a loaded in texture (namely, the arrow one above), and just render it directly on top of the corresponding map tile GameObject.

To actually stroke the path, a function, strokePath(), is called every time a valid path is found. What stroke path does is take in the “valid” path, and then process the tiles in the path to figure out the corresponding sprite that must be placed at a given path tile. To process the path and find the right sprite, you need to know the direction between two tiles, then apply the sprite that corresponds to that direction. To find the direction, it’s a simple matter of subtraction. If one tile is at  [2,0] and another is at [2,1], then the direction from the first tile is [2-2,1-0] or [0,1], aka, one tile to the North. That means that you can place the Sprite that goes North/South. Implementing that directly though gives us this:



That’s close, but obviously not right. What’s the issue? The problem is that, because you can only, by design, move in cardinal directions in the game, the “direction” finding never resolves into a diagonal heading like [1,1] or [-1,1], etc. despite the movement itself being “diagonal”. What we actually want isn’t the direction to the next tile, but instead to the tile after the next tile. So if we start on Tile A, and are trying to find the sprite to place at Tile B, we have to actually find the direction to the tile after Tile B, Tile C. This gives us the proper indices into the arrow sprite array!



A final note here. Notice that, along the diagonal paths, the sprite for a given direction alternates between a flipped version of itself! If you just implemented the diagonal checking above, you would, similar to the “L-shapes” above, only get one sprite that matches up to every other tile in the found path. This is the same issue as the “L-shapes” problem — you need to check and see if your current direction is the same as your previous direction. If it is the same and is a diagonal path, you pick the opposite sprite!

Hope this helps other people looking to program the battle arrow in their games!
« Last Edit: May 06, 2017, 08:16:04 AM by bacon » Logged

JShrum.Composer
Level 0
**



View Profile WWW
« Reply #7 on: August 05, 2016, 08:32:49 PM »

Wow, I have to agree with previous comments that the colors here are fantastic.

I don't feel like it's too often that we get a modern/futuristic tactics game either, so I'm curious to see what kind of combat strategies and tricks are available with all the sci-fi machinery running around.

Looking forward to more!
Logged

I make music! Take a listen:
WebsiteSoundcloud
bacon
Level 1
*


View Profile
« Reply #8 on: August 06, 2016, 07:33:39 AM »

Wow, I have to agree with previous comments that the colors here are fantastic.

I don't feel like it's too often that we get a modern/futuristic tactics game either, so I'm curious to see what kind of combat strategies and tricks are available with all the sci-fi machinery running around.

Looking forward to more!

Thanks!! Yeah the scene definitely seems to veer most often towards Fire Emblem/FFT style, which is totally great, but I also want to see a re-imagining of Advance Wars that isn't a carbon copy of its mechanics.
Logged

Shnurbs
Level 0
**


heyo


View Profile WWW
« Reply #9 on: August 06, 2016, 04:35:00 PM »

The robots remind a bit of Simon Stalenhag, which is never a bad thing. Love the color palette in the environment on the first and third environmental images in the first post, although the second one looks a bit off to me. Overall pretty great tho!
Logged

Graphicalgeek
Level 0
***


Explosive


View Profile WWW
« Reply #10 on: August 06, 2016, 09:24:38 PM »

Excellent! I always love a good tactics game.
Logged

Working on Fantasy Conquest Tactics
https://forums.tigsource.com/index.php?topic=53617.0
bacon
Level 1
*


View Profile
« Reply #11 on: August 07, 2016, 08:23:26 AM »

The robots remind a bit of Simon Stalenhag, which is never a bad thing. Love the color palette in the environment on the first and third environmental images in the first post, although the second one looks a bit off to me. Overall pretty great tho!

I'd definitely be lying if I said I don't have both of Simon's Kickstarted books near the desk where I do all the programming. Discovering his stuff was a major shift in the trajectory of the game, seeing how the worlds can feel very alive with color vs. the typical black/grey/neon sci-fi (which I do love!). Thanks for the feedback on the environments too! They are definitely mockups, but I wonder if you know why you're drawn to the first and third more? Could be important for figuring out terrain gen algorithms...

Excellent! I always love a good tactics game.

 Smiley
Logged

foofter
Level 4
****


MAKE THAT GARDEN GROW


View Profile WWW
« Reply #12 on: August 07, 2016, 10:19:42 AM »

I love the graphics, characters and mechs (and I'm not even a mech person!) AND I lovvvve grid-based SRPGs so I really wanna play this! And I love SF. Great style. Smiley

But when you say character-based, what do you mean? Developing each unit is a major part of the game? Or a lot of story? Or that you fight with individual characters and not generic Advance Wars units?
Logged


@_monstergarden (game) and @williamzwood (me)
See Monster Garden progress here: https://forums.tigsource.com/index.php?topic=56012.0
Shnurbs
Level 0
**


heyo


View Profile WWW
« Reply #13 on: August 07, 2016, 11:01:14 AM »

The robots remind a bit of Simon Stalenhag, which is never a bad thing. Love the color palette in the environment on the first and third environmental images in the first post, although the second one looks a bit off to me. Overall pretty great tho!

I'd definitely be lying if I said I don't have both of Simon's Kickstarted books near the desk where I do all the programming. Discovering his stuff was a major shift in the trajectory of the game, seeing how the worlds can feel very alive with color vs. the typical black/grey/neon sci-fi (which I do love!). Thanks for the feedback on the environments too! They are definitely mockups, but I wonder if you know why you're drawn to the first and third more? Could be important for figuring out terrain gen algorithms...

Excellent! I always love a good tactics game.

 Smiley

Well... I can hazard a guess. For the first and third ones, while the palettes aren't exactly clean, the colors seem like they complement each other more. And while there are basic tiles and variations on the basic tiles for every environment, the variations in the second and third are subtle enough that they don't really contrast too much. I don't think that made a lot of sense, so here's a picture:

I think it's also that the color palette you chose for the snowy level details is a dull white and some brown, which makes it look like the snow is dirty, which to me doesn't look that great.
Logged

bacon
Level 1
*


View Profile
« Reply #14 on: August 07, 2016, 11:03:28 AM »

I love the graphics, characters and mechs (and I'm not even a mech person!) AND I lovvvve grid-based SRPGs so I really wanna play this! And I love SF. Great style. Smiley

But when you say character-based, what do you mean? Developing each unit is a major part of the game? Or a lot of story? Or that you fight with individual characters and not generic Advance Wars units?

Thank you! Cobralad's pixel art is too good. I was browsing the TIG image crawler and all the stuff I liked belonged to him and I saw some of his mockups and thought this is what this game looks like. I'm excited he's on-board.

"Character based" means that there is a big focus on the COs that will be in the game, both in the story and the mechanics, as who you pick has a lot to do with how you play. In terms of mechanics, think Advance Wars COs, but going just a bit further. You aren't locking yourself to a "path", but when you pick a CO, even if it's one inside the same faction, the "play" should feel a bit different for each. Every faction CO has the same ingredients per faction, but think of COs as the chefs  Hand Fork Left Hand Knife Right . They mix it their faction in their own unique way. Each Faction has their own mechanic, and each CO plays with the faction mechanic in a different way. COs are also (single) units, so their presence on the battlefield isn't just an eye in the sky situation.

The units are more Advance Wars style and less Fire Emblem, though right now they do gain bonuses across matches so there is local progression. But you aren't, say, switching out a units tank treads or something. The local progression though should make you feel "close" to the units though as you play though, and when you lose a battalion that you've been fighting with since the beginning of a match, it will feel like a "real" loss, as there will be tangible investment in them.
Logged

bacon
Level 1
*


View Profile
« Reply #15 on: August 07, 2016, 01:03:06 PM »

Well... I can hazard a guess. For the first and third ones, while the palettes aren't exactly clean, the colors seem like they complement each other more. And while there are basic tiles and variations on the basic tiles for every environment, the variations in the second and third are subtle enough that they don't really contrast too much. I don't think that made a lot of sense, so here's a picture:

I think it's also that the color palette you chose for the snowy level details is a dull white and some brown, which makes it look like the snow is dirty, which to me doesn't look that great.

Thanks for this! I definitely see your point — I think it's also kind of up in the air right now about how to actually tile the environments. What you're pointing out though is what I think is the predominant mode of thought for the project though, basically have 1-3 base "colors" per level, and really bring the color in based on the environmental details of the map vs. making all the base tiles varied. This is something I was thinking about as well via perceived scale. If things are all locally visually similar, you likely identify them as connected and contiguous. Whereas if they are varied, they look disjointed, or possibly abstract.

Like this:



Triple Town looks like an abstraction because of the variety of tiles that appear next to each other without order. So in a sense, you could see the world as "zoomed out". One church may actually represent a small town if you could "zoom into" the tile.

This:



With the Road Not Taken, looks more contiguous — where the visible tile distance from the player to the Boar or other landscape tile maps to the "real" distance from the player to the boar. This is the route we're going a bit, though more in the middle. The visible unit is an abstraction of a squadron, but the terrain still scales nicely next to the units. This is also why doing "stepped" terrain isn't often done in "large scope" games because the stepped terrain doesn't make sense if Units also take up a tile of space.

Something like this:



Looks really good, but imagine if a soldier is on one of those tiles — is the soldier as tall as a cliff?? If they are, can't they just walk up it? I realize it's a design decision too as people could be whatever size, but I definitely think aligning on unit size/terrain size is important. For stepped terrain to be nice, you've usually got to "zoom in", which gives us lovely things like FFT.

Logged

Kayzaks
Level 0
***


Blimp Pirate


View Profile WWW
« Reply #16 on: August 27, 2016, 04:23:35 AM »

Very very cool! Reminds me a lot of Deadlock aesthetic wise Smiley In a good way of course
Logged

bacon
Level 1
*


View Profile
« Reply #17 on: August 27, 2016, 11:27:32 AM »

Very very cool! Reminds me a lot of Deadlock aesthetic wise Smiley In a good way of course

Woah I had never seen Deadlock before! I'm definitely inspired by games of a similar aesthetic though with stuff like Civ 3. I love the isometric perspective Smiley
Logged

freank
Level 1
*



View Profile WWW
« Reply #18 on: August 27, 2016, 11:44:38 PM »

nice work !
Logged

My last game:



Supporter of
bacon
Level 1
*


View Profile
« Reply #19 on: August 29, 2016, 05:08:33 PM »

Overthrowing The Tyranny of the Update() Loop with Event Systems

In most Unity games/tutorials, logic is often placed inside of the Update() loop. It’s a great place! Because the update loop runs every frame, it ensures that logic is always run, updating whatever you need to update about as soon as possible. This can be a great way to quickly get stuff done and ensures that whenever you change something its change is almost instantly recognized. Over time though, you can grow to despise Update().  Angry  While it’s great when you’re making a small game or program that lacks complexity, constantly placing logic inside of update is a sure way to find yourself on the dark road to code spaghetti. Placing logic exclusively inside of Update() is bad for at least two reasons, namely, that it encourages the coupling of code through multiple stored references, and distributes the locations from which potentially game changing code is executing.

If you actually start thinking about it, most code doesn’t actually needs to be run on every frame. Most methods/actions are casually related to other known method calls, so why not just execute the code from those methods instead of update? Often, the answer is because we want a lot of other things to happen when that method gets called, so instead we’ll often set the state of little flags that are then checked against ever frame so we know when to (or not to) run other code. This is a good first step, but you can a lot further. This sort of flagging paradigm will still often necessitate knowledge of the state of other objects outside of a given class, meaning you’ll need to be checking or calling references every frame as well.

This means that classes that rely heavily on Update start accruing references to objects they may only ever check once in the scope of the game, but are forced to hold their references throughout their lifetime as objects. These cached references will take up serious space in memory, so if you’ve got a multitude of objects that all have a lot of references, you’ll quickly find your game chugging, even if nothing is going on!

How can we go beyond this then? Through beautiful freedom that is Events! Though not a catch-all for everything, events are a great way to untangle your code by decoupling classes through the use of a centralized logic/command system. An Event is literally what a colloquial “event” is — an occurrence, a happening. An Event centered paradigm shifts the context of what an object “knows” from being ambient knowledge about other objects/variables through references, to instead “listening” for the right moment to act, regardless of who is telling it to act.

It’s best to use examples here, so for an easy one, imagine you’re making a gardening game and you want a plant to grow when you water it. To water a plant, you must know: what is watering the plant, what plant is being watered, and what to do when the plant receives water (Grow()). Update()-centric code would do something like this:

Code:
class Plant  {

   bool watered = false;

   void Update() {
if (watered) {
grow();
}
    }

    void Water() {
watered = true;
    }

    void grow() {
         //grow!
     }
}

Every frame, this plant, no matter its state, is checking to see if it has been watered. However, we know that, for now, the plant will only ever be watered through a very discreet action, namely, one that calls the Water() method. So the value of “watered” would only ever change in the event of a “watering” where this method is called. Why then, do we need to check it every frame? Because in this paradigm, we don’t know when Water() will be called.

Also, what if a can wanted to water three plants instead, or maybe ten? What calls the Water() method would need to have knowledge of all these plants!

How can we know when Water() is called, but also not know the specific plant we want to water? Enter Events. Instead of some random class needing to have a reference to the Plant so it can call that plant's watering class, the Plant is instead setup with an Event that listens for a “Watering” event. Any Plant that then listens for a Watering event would then interpret that "Watering" event in its own way.

These events are handled through a centralized bus that ingests the Event calls, and then dispatches the called event to anyone who may be listening to it. And the beauty is that nothing that "Waters” needs to know about what is getting watered. All it cares about is that it is watering.

Without diving too far into specifics here, here is a basic, pseudo-code implementation of an Event listening Plant and an Event dispatching Can.

Code:
class Can()
{
    void OnMouseClick()
    {
        //send off a "Watering" event when the mouse is clicked
        EventManager.Dispatch("Watering", true);
    }
}

class Plant()
{
    bool watered;

    //respond to a "Watering" event by calling the respondToWatering method
    EventManager.Listen("Watering", respondToWatering);

    //accept the eventParameter as a bool
    void respondToWatering(bool eventParameter)
    {
        watered = eventParameter;
        if (watered) {
            grow();
        }
    }

    void grow()
    {
        //grow!
    }
}

Look at that! We can grow without ever needing to call Update()! You can hopefully see how you can use this for nearly anything. You can move objects, trigger UI, spawn new objects, etc., all without needing an Update() loop! It may be hard to see the benefit of Events in this small example, but as code grows and needs to accommodate more and more scenarios, you’ll find that events enable you to stay lean, while Update() centric code often leads to a lot if/then checking and reference holding that will slow down your gamedev in the long run. Hope you all enjoyed!

For a few more references, check out:
Game Programming Patterns - Event Queue



My preferred EventManager class

///

For an update on ISO TACTICS, I recently went to Unity Dev Day in NYC! I attended a great talk on networking, and am moving forward with that so I can get two people playing against each other sooner than later. I've also been spending time working on the way supply flows around in the game, which is a core part of the way the game works (if not the core-iest). Unfortunately, a lot of this is all under the hood, so there isn't quite much new to "show" yet. All in good time though!

Logged

Pages: [1] 2 3 ... 5
Print
Jump to:  

Theme orange-lt created by panic