Shadow Code

[sombresiles]

Summer news

Haven't given any sign of life in a while, but fear not, for this project is alive and well. I completed the exchange fuselage that will let the player move ressources between their regions. It took some awkward steps actually, with the culprit being once again the GUI. Basically listing the current exchanges is kinda trivial though the interface have to let you pick the destination, the resource and the amount and edit them thereafter. But those are only rhetorical values for of course you can't send anything that you don't currently own. Hence the need for separate updates, one for displaying your region status and another for actualization the real resource movements. My earlier draft had those updates joined hence the less to entangle this. I'm still kinda dissatisfied worth the result because the code is longer than I hoped and I'd really like to have both GUI and turn update follow the same pattern. Anyway I used my last me vacation time to fix an annoying bug in the map generation. The incoming steps are a bit of GUI cleanup and next oddly starting work on the hostile and combat parts.

[sombresiles]

Still not much too look at but a couple important features have been added

The region now feature a supply value (food, etc) that has a maximal cap. Some buildings can provide supply within that cap or even expand it. Other buildings may need to use supply to be active.

Basically those buildings are either Active (using supply and running), Inactive (should be active but lacking supply) or Shutdown (disabled manually to save supply for other operations)

The next step is either to have units using supply too (and thus attaching units to a region) or getting started with region colonization (making a unit able to build in a new region and doing the back end stuff to make it run smoothly.)

So far the GUI has proven to be the most annoying. I've already tackled down a few bugs but keeping it always up to date is quite annoying

[sombresiles]

Roadmap (II)

To follow my previous roadmap post, some precision about the game economy. I've finally settled (for the most part) on the rules I'm going to introduce in sucessive steps

Basic version (I hope to finish in a few weeks)

Region has got resources if it has an Center.

You can build extractor on resource points featured in a give region

A region feature a maximum agriculture value. By building appropriate buildings you can harvest it and have a manpower value available

Some buildings and units use that manpower value to be active. You can deactivate buildings or units to free some manpower.

Advanced version (later)

resource points can be known or hidden. You have to prospect for the latter

upgrading the center lets you have more building options and change some values

agriculture max can be upgraded

you can send goods from one region to another. These exchanges are capped to a travel capacity tied to the region

Advanced units and buildings use different manpower values

More advanced version

Resource points have several levels that allow higher level extrator to be used

which region does supply a unit can make a difference

letting a unit without support doesn't merely inactivate it but prevent experience (and may lead to loss of experience

Advanced units requires new kind of resources than basic supply

travel capacity can be upgraded. Higher levels require manpower too

What is this gameplay trying to simulate?

You don't exert absolute control on the general populationj like in Civ. There is no food storage and growing population. Food is only considered as giving you manpower for your colonial structures and units. This manpower cap means you have to choose at any moment between units and extractors (basically). you can stop your resource extraction when stockpiles are plenty enough but having deactivated units is a waste of experience at best.

The agricultural capacity of the region will vary a lot. This means only a handful of them will be able to support your workforce outside and you'll have to send goods from other regions. 

This is of course without taking into account any of the climate/experience/technology modifiers that will come in later

[sombresiles]

Done the basics of the resource system. It wasn't that straightforward actually. Since I want to use Unity as a level/game editor, I'm leveraging the interface even for something as abstract as resources. That's why I've got gameobject whose job is to hold templates for buildings, resources, etc. I could of course load prefabs at runtime but didn't want to touch that.

The resource flow itself is straigth forward. Buildings can have producer components that modify the resource "flow" of their region, and they are produced by the end of turn.

Resource usage for construction is a tad more complicated. Construction units have a work_power value. When asking to build something I check the maximum work that can be performed with the current resources available. That can of course be zero, but most of the time, the work simply slows down. Behind the scene each building as a total work cost and a resource cost for each work "unit". Of course the totals are displayed in the UI.

Next objective is debugging the UI. I've noticed issue with the orders and unit selection generally. So far to pick a unit you have to select its tile then the unit into a list... and if the unit moves you have to reselect it, which is not what peole want to do I guess.

[lephenixnoir]

Let’s give it a try :

So far what is done. :

Basic Map Generator

Unit Movement and Pathfinding

Basic Turn system

Tile and unit selection

Modular unit behavior

Basic construction menu

Resourceless construction

And now what I’m hopefully going to do

Resource system

Unit creation

...

[sombresiles]

Of Components and Interfaces

No screen today ;)

I've starting cleaning up a couple of things in my previous code, mainly because I tend to not overplan stuff and even if it can be annoying, rewriting things after gives you more insight. A good moment to start doing this is when you notice yourself copypasting way too much.

In the case of all those "lovely" menus that have been sprouting up in the last screenshots, one noticeable issue was that unity doesn't stop trying to raypick stuff under them, which is a good thing but actually messes up quite a lot the intended role of the GUI. The solution is asking each menu if the mouse is hovering over them whenever a tile says it has been raycasted. But so far all my menus were only components and I had to manually call them in a master script

The solution was either to use a common interface or create a manu parent class. I went for the former because in C# you don't have multiple inheritance, but that did cause it own set of issues. As all my GUI are component of a singular game object, with a parent class I would just use the GetComponents<ParentClass>() to get them easily. But they are implementing an interface instead, so I just get all the components and  have to check if they can be casted before trying anything. 

The next step will be creating the action menu that will let me, among other things, let units build those structures I've been placing into my tiles.

I'll try to use the component architecture leverage this time. Units contain all the required code to be named and move so far, but I think other basic functions should be separated. They will get UnitRole components that will all have in common a GetActions() and PerformAction(type) methods. 

When asked to show actions, the GUi will simply ask the Unit class that will then get all the components to add their own options to the mix. Will I use an Interface for them or use a parent class? I've yet to decide to be honest.

[sombresiles]

Construction menu done. Though the buildings directly appear on their relevant spot and are set into a special state (the greyed out one), I still need to code both the order panels for unit and the construction process itself. 

Basically it's a mix between the civ and the warlock approaches : you place building from your region/city menu and they cost resources but workers have to actually stay at the construction site and spend some time to complete it. The resource consumption process itself is based on continues usage : building have a work "cost" (think hammers from Civilization) tied to its resources cost. Units working on site complete that work whenever enough resources are available. That mean you can start construction way ahead the actual resources are available but your construction site can grind to an halt.

Another feature I'll introduce soon is the unit skill dependancy for construction. One building will require at least one skilled enough unit but the whole process can be sped up with other kind of units if you don't need them for anything else.

[lephenixnoir]

Turn system is done. At least for units. I didn’t expect to try my hand at coroutines so early but at least it worked on the first try. So basically, whenever you use the new turn button, any units with a not yet completed move and remaining action points will slide toward its destination, in the meantime the units and the program check for a turnDone flag to give us access to the button once again (later I’ll add some waiting cursor or something?)

It’s time for me to start handling region infrastructure. I could either implement resource, and resources production/usage or building creation next.

[sombresiles]

No images

Yep, I'll wait for some new graphical content. Slower progress lately, I've mostly added GUI element for selecting tiles/units and used my path finding to let them move.

Had to sort out an issue that made tiles being selected while clicking on GUI elements, now a "watcher" function checks that the mouse isn't hovering over those. (funnily enough, mouse coordinates are y up whereas pixel coordinates are y down as I found out)

I'm currently adding move points to units, a small addition that will let me build the start of the turn based system.

[sombresiles]

A first pass at pathfinding :)

I wanted to get rid of it before implementing the units. I'll work more on it later :)

[sombresiles]

Before going further, I've made sure to put the region generator to use. Now a proper Region class is created and assigned to each non sea tile.  Since I may want to create region GameObjects, I've made a prefab used by the generator. So far I'm still picking colors at random and giving region names from a static list.

To check this and getting started on the GUI, I've made a first info panel that displays basic information about the tiles. I'm using Polygon2D colliders to select the hexagons. The automatic version yielded a pretty concept polygon with 27 (!) vertices, I've manually reduced to 6 and set up as triggers.

I dunno what could be the impact of performances could be so I've chosen to disable collisions in between the default layer.

Tomorrow, I'll try to lay the base for the the building and unit systems, at least as static objects assigned to tles.

[sombresiles]

Working on Regions (1)

Done with a first iteration of the region generator.This one still has a few shorthands but I’ll talk about the implementation first. The SeedMapGenerator class will modify the value within the HexGrid and fill it with several region types, 0 being considered water.

First a “seed” hex is chosen at random within the grid (I take a neighbouring hex from the regions for quickness sake)

Then for each Region I do the following things

1 -> take neighbouring hexagons that don’t belong to other regions. If that list is empty, abort the procedure and return the incomplete region

2-> randomly add hexagons the region within this list. The probabily is a “coarse” factor that control the regularity of the growth

3-> if maximum region size is reached, stop the procedure

4-> if region size is within constraint, set the type for each hexagons and disable them for future selection. If region is too small, set the type to water

The most noteworthy thing is the neighbour search. I have a simple method for getting a list of hexagon neighbours (or only active neighbours). As my hexagons are stored with only 2 coords (instead of 3), this method is a little different for even or uneven rows.

Issues :

-> I’ve flagged the map borders as unactive for this search but that leads to rather straight coastlines. This could be changed by setting the border width at random

-> the procedure can yield rather isolated hexagons or even “lakes”, though that’s not necessarily a bad thing

->by taking seeds within borders of existing regions I can’t create separate “continents”. Picking seeds at random could avoid that but a technique must be devised to pick it only amonst available hexagons (for instance picking a number within the “rest” of available tiles then linearily search of that position. For really huge map sizes, hexagon sets would be needed

-> I don’t check for the possibility of “snake” regions that could be created by taking seeds at random. To avoid that some criterion could be used, like the average neighbours of each region tile, if that number is < to some threshold, the region could be discarded.

[sombresiles]

I'm getting into the process of creating varied regions inside my map. So far my first genertor just set random types to tiles, and I color them with a list of randomly created colors - though checking they aren't too similar.

What I've done though is organizing the code a bit better and add some utility classes that will be super useful later. Oh and add some camera script to check the results of course!

So far I have a Land GameObject with 3 script components :

MapScript is the manager that calls the other. I set the number of regions there. It is this class that will use the hex infos and instanciate actual hexagons and color them.

HexGrid is a container for hex info, a small class with hex coordinates, type and status. This class holds these info to be used both my generator scripts and the MapScript instance to draw the map. Among other things, this class allow to get lists of hexagon neighbours or even neighbours of an hexagon collection.

Finally MapGenerator is a basic class that creates the color set to use and just does the random type attribution thing. My aim is to derive it into a more powerful kind of generator. I have two main directions for this :

The first one is simply to let regions grows by getting neighbouring hexagons from a "seed", until a region maximum size is attained

The second is the simulation of realistic biomes with temperature, altitude and humidity. From these initial condition, I'll be able to define biome homogenic regions that I may expand, contract or slice to meet average size requirement

[sombresiles]

The first of many many steps. I've starting by designing a couple classes in Unity : A Tile and a Map.

I could have gone through the mesh generation path but I wanted to start with simply sprites and offset that possibility for later.

The Tile script so far only makes one useful thing : it uses internal X,Y coords to compute it's position with regard to the map. Having a Tile member doing this lets me either position them by entering the hex coords or letting a generator doing this.

The map script takes a desired grid height and width and creates an children array. So far I use the transform hierarchy as local storage array to acces the hex, with ad hoc getter.

[sombresiles]

The start

While I work both with C++ and python for a living, I've decided to give a try to Unity3d and using C# scripts.

This means it will be a double discovery for me or rather triple: the language, the framework and the whole game making thing. So far I'm used to work on specific APIs in somewhat larger projects, with a more narrow scope, with a focus on performance and new features.

That said, the first piece of the incoming project is a world prototype. As it is going to be turn based 4x game set on land, I've chosen the classical but efficient hexagon grid for a starter. But nested in the gamedesign is the concept of several areas that play a rather important role, thus the map should be both made of tiles and areas.

So the initial question is what kind of dependency should build within the game? That each tile should belong to a specific area is a no brainer. This will let them have access to important attribute such as ownership, climate, and all kind of area dependant effects.

But should the areas themselves nest some kind of tile array? Any effect on a tile can be bound to it's local area reference but if I need to get sums and global areas statistics I'd better keep such an array, even if I could consider that any effect modifying a tile could instantly modify its area variables.

All considered, we're not dealing with rather huge numbers here (a 100 * 100 tile grid would be quite a thing) so I should avoid being thrifty at this stage

[sombresiles]

Shadow Isles

This blog will be about my journey into game making. The yet unnamed project I want to achieve has been a quite oldish idea that has slowly matured from a reimagined multiplayer RPG to something more akin to a single player strategy game.

Why a dev diary? Well for one thing I'm used to interactive storytelling and I think I'd miss on this aspect throughout what is certainly a more solitary endeavour, and I tend never to write down my ideas or reflexions and this would be the perfect excuse.

And of course whatever the result will be there could be piece of programming and gamedesign useful to share along the way.