next »

[Pandawan]

First of all, love the screenshots! This looks so awesome!

Anyways, I think making the cities be dependent on some variables might be a good idea, tho don't make too many or something since I'm pretty sure you don't want a SimCity...

Also, I don't think forcing the player to put roads is a good idea, tho it would force the player to travel to more planets, it might also prevent the player from placing "that one last thing before I can get to this new planet" you know what I mean. I guess you could experiment with them, and see if they are more blocking than they are an addition. Just make sure to test it, because you never know, it might be really fun and interesting to work with.

And lastly, will you make some water tiles? Anything that you can put on water? It could be good because it would allow for more resources/new gameplay mechanics. But it could be bad because it could clutter a planet.

Btw, love your logo!

[internationalfish]

This is awesome. You are awesome. Just... such awesome. Amaze.

As someone learning Unity, I'd be really keen to watch or read anything you've recorded or written as far as tutorials or in-depth technical dev logs. Do such things exist?

[Prodigga]

Hey thanks you two!!

@Pandawan The colonies will be dependant on you providing them with food and luxury resources. A well supplied colony will grow from a settlement in to a big city!

As for the roads, I only meant on a planetary scale. That is, the individual farms and such on the surface need to be connected to that colony's center.

@internationalfish I have a blog but there isn't anything too interesting on there. I should really start mirroring posts from here over to there. http://www.timaksu.com

Today I worked on the population growth system. I have a basic system in place now. The population will grow in number if it is healthy, and to remain healthy the colony must have constant access to food. I can add more requirements and stuff later, this is just the first pass on this system. This meant I had to rework my construction tool/system too. Now it supports different tools (ie one for selecting and constructing a factory, one for colonising the planet, and one for expanding your colony's border.). Nothing too exciting, but here is what it looks like:


Next week I will be working on a system to visualise the population count. Not entirely sure how I am going to handle this one at the moment, but it would be cool to see buildings start popping up, radiating outwards away from the colony centre, with the buildings increasing in density as the population grows. Anyway, I can worry about that next week. I did put together a high density tileset just to see what it would look like. It doesn't look bad at all. There is some clipping between the skyscrapers and the roads underneath but its not a big deal.

[internationalfish]

@internationalfish I have a blog but there isn't anything too interesting on there. I should really start mirroring posts from here over to there. http://www.timaksu.com

Yeah, that's what I do with mine... not particularly useful, and no one looks at it. More of a tradition and an attempt to keep myself paying attention.

Will definitely check out your Unity tutorials once I get the basics down.

[Prodigga]

Hey y'all, update time.

I'm really starting nail down the core mechanic's of planetary play. Almost everything is in, atleast to a level where I can upgrade it with something more sophisticated later!

I've put together a road system. Structures not connected back to the colony center by road won't function. That is, City tiles won't grow in population and factories will cease production. I played around with different ideas for road visualisation, and settled on a flight path idea. The roads are designated flight paths, and will have commuters flying back and forward on them. This is the future after all! Would be too mundane to have cars driving around the surface.

The flight paths generate a hanger where they meet with structures, indicating the structure is connected to the flight path. Check out these flight paths (I need a better name for this, "road" doesn't work, any ideas?) in the screenshots bellow.

I also added in some simple UI elements to display information about the planet the player is viewing.

• Top left is general information about the planet. I will eventually add more details here to show the player why the planet is at a certain Health% or why the climate is the way it is (climate system not yet implemented, so it is grayed out!)
• Top right is information about what the planet is currently consuming. Water and Luxury resources are not yet implemented, so they are grayed out, but food works fine. The planet will take food out of the inventory and put it in to the food slot. The green background is a progres bar which decays over time, until the current unit of food is consumed. Water and Luxury resources will work the same way.
• Middle right is a real-time display of the current inventory for this planet.

I've also added a very simplified version of the city growth system. As the colony grows and generates population, the new residents will actually be slotted in to a house. If now house is available, a new one will be constructed. If no room is available, existing houses will increase in density, slowly turning in to residential sky scrapers. The system is kind of "dumb" at the moment, in the future I want to add some more complexity to the system so it is a little more interesting to watch. (ie there might be a demand system for different densities a la Sim City. There might be areas that refuse to grow larger, and other areas that want to get taller quicker (maybe based on things like proximity to city center, proximity to factories, etc)).

Here is a time lapse of a settlement growing.

[badrobit]

This is looking absolutely amazing! Please tell me that you are planning on doing a steam early access or something so that we can get some play time with it and of course help you find bugs 

Amazing work so far!! 

[Prodigga]

Thanks, too kind. That hat gif makes me feel so good inside, haha, great morale booster!

The end game here is to release on Steam, as for early access.. most probably (bug fixes, balancing, etc), but it'll most likely happen relatively close to the release date. I have played so many early access games and have exhausted the fun out of many great titles that way, before the game is even released! I can't help myself, haha. That's sort of why I'm leaning more towards a tighter early access > release timeline. Id rather release with a bang rather than slowly trickle out.

I am pretty terrified of the process! I've stopped thinking about it since it is so far away, but I will admit I lost a few hours of sleep at the thought of my greenlight page being burried to obscurity and all my hard work going to waste!

Anyway that's sort of where I am mentally on the topic of Steam.

[badrobit]

I totally get where you are coming from! If you ever are looking for testers I will happily throw my (top)hat into the ring. Cannot wait to see what comes next for this project!

[Vilanat]

Your game wont be buried in Greenlight, it will get greenlit within less than two weeks.

[Greipur]

I like the name for the game, and the progress for these last weeks is really promising. Also, regarding Early Access, I understand your reasoning, but I do think that procedural games fares better, which I assume yours are. Anyway, maybe try out ith.io's Refinery? Making a small soft launch in the future might be the best from both worlds, if testing is needed.

[Prodigga]

Thanks everyone for the continued support!

@

maybe try out ith.io's Refinery? Making a small soft launch in the future might be the best from both worlds, if testing is needed.

That's awesome, I didnt know it was a thing! Also, steam literally just announced closed betas. I've been talking about early access with friends and im starting lean more in favour of an early access release. The continuous testing with progressive feature updates could be a good way to go. What you said about procedural games made me think of Rimworld, Factorio and other games, and yeah, I guess it could work pretty well.

Update time!

Started working on production chains and structures today.  Man.. this is a big challenge! It requires so much creativity (which I am running dry on) and lots of thinking. Everything is so intertwined. Each change has an effect on multiple other stuff. Also, this process so far is entirely "theory crafting". I have to imagine how the game will play out and design with that in mind. I have to constantly think about how products will interact with one another.

Anyway, I have some ideas down on. I have not yet considered space related products and structures, which has come back to bite me in the ass... All of my ideas so far are focused on planet side structures. I have some early ideas about what type of things will be required for space travel and colonization, but like an idiot I put them at the end of the "production tree".

At first this seemed like the logical way to move forward. The player starts with simple products - as an example, you will mine iron ore which can be refined in to iron plates. Then, with the iron plates, you can produce machinery. Machinery will allow you to build more advanced strictures to manufacture products higher up the production tree. This makes sense. So, following this pattern, It only felt natural to place "space travel" related goods, such as titanium/solar cells/life support modules at the end of the production tree, since they are some of the most advanced products you will produce.

What's the problem then? Well, to become a space faring civilization, it means that you need to have reached the end of the production tree. This means that you would have already built all the structures and produced everything there is to produce in the game. Uhh. It robs the game of one of the primary reasons to colonize other planets!

I will be shuffling around some items tomorrow to fix this design problem.

Firstly, I will move some space travel related items much lower down the tech tree (namely titanium). This means the player will have access to space much earlier on in the game, allowing them to colonize nearby planets and initiate trade between their colonies much earlier. This, combined with the need for more building space should drive the players to colonize more planets. The idea here is to encourage the player to colonize a lot. The game shouldn't feel lax enough to play the entire game on a single planet. (You could try, just to challenge yourself, nothing stopping you).

Secondly, I will make it so that some advanced products can only be manufactured in space (for example, carbon nanotubes), so that the player will need to build space stations to continue progressing up the production tree. Because of this, I want space stations to play a bigger role in the game. I haven't fleshed it out entirely, but I want space stations to be their own colonies. The player constructs a space station which acts as the colony center, and can expand on it by construction platforms around the planet. These platforms will work the same way as the tiles on the surface of a planet. (That is, the player can construct structures on top of the platforms). This will extend the game beyond planetary gameplay.

Anyway, lots of talk, time for pictures!

Spoilers, I guess? Here is the current list of structure and products. Remember, these pictures do not include any of the changes I talked about above, so this'll probably change a lot in the future. This is just version 1.

- Gray boxes represent structures
- The boxes ABOVE the structures are the products required to construct then
- The boxes BELLOW the structures are the products they can be configured to output. This does not show the recipes for the products, it just shows the output. (For example, the animal farm outputs meat, but it requires vegetables to produce meat, and that is not shown here.)
- YELLOW boxes are raw products, mined/extracted/grown
- RED boxes are manufactured products
- GREEN boxes are consumable luxury items
- BLUE boxes are an error, and should be Red (I'm on my phone, so I can't fix it here...!)
- GREEN, YELLOW and RED OUTLINES represent the 'tier' of the item in the production tree.



Bellow is the recipes for manufacturing all of these items. Sorry, I don't have a bigger picture. (I know you can't read any of it!) but I thought I would post it anyway just to give you an idea of how the different products intermingle

The group of boxes up top is consumable foods. The boxes on the right are just a key for my own convenience, and the main cluster of boxes is everything else.

[badrobit]

Out of curiosity what software are you using to create those diagrams? And I am pretty sure from previous screenshots it was clear you were using unity to develop but I was hoping to confirm that.

[Prodigga]

Unity is the game engine and draw.io with Google drive integration for the diagrams.  

[NineTattooedDragons]

Very cool looking. Reminds me of Little Prince.

[Prodigga]

Hey y'all, update time.

I started implementing all of the products and structures I have been planning out. I really need to play it to get a feel for it. I can only do so much with diagrams!

So I had to implement some new UI and some new features to make this possible. As usual, since this is a first pass, most of this has been hacked in just so I can start playing around. The end result looks relatively polished but the code - oh man. Let's just say I'm glad no one will see it in its current state!

First feature was to add an ability for a factory to have multiple recipes, and provide some way for my to selext which recipe is being used by the factory. Also, I wanted to be able to set the factory to idle, too, so that factories with multiple recipes will be constructed in idle mode and not consume any products until you decide what you want it to do.

Secondly, I needed a way for the user to actually select factories on the planet surface so I can spawn some sort of info dialogue through which the user could see the progress of the current job and change which recipe the factory uses.

Third I decided to add a whole bunch of UI to make it easier to play and test the game. I've added tooltips so you can hover over any product icon on screen and see which recipe produces that product. I've also added the factory info dialogue that I mentioned before.

Lastly, since the player can now manufacture products, I added the some code to make it cost products to construct buidlings. You won't be allowed to place it until you have enough resources and placing a building subtracts those resources from your inventory. Simple.

The UI is not final, I just went with the simplest thing I could think of (boxes), and added a simple blur effect to the back so it was easier to read. Icons are also not final, they are all from flaticon.com, shoutout to them again!

Also, the new structures are using the same models as before, but they are just tinted different colors. These are placeholders.

Screenshot time!

Here is the new factory construction menu. You can see the name of the factory, what is required to build it, and what kind of goods it can be configured to output


Here is what the tooltip looks like. You can spawn it by hovering over any product icon that is on screen anywhere.


And here is the factory info dialogue


Bonus gif! Here are some spaceships using a flyway (flying + highway = flyway? )

[badrobit]

Nice progress!

If I could add my two cents I think it might be good for usability if for all your GUI panels they have a bit of a blurring effect like your bottom one so that the player can see that they are there. Specifically, I am thinking of this part:



The icons just bleed a bit too much into the background (in my humble opinion).

It is also a bit weird when the ships on the left side of your flyway (awesome name for it btw) are spread out on the top part heading down but as they round the corner they group together. It would make sense if it were a road but where they are flying they could probably stay spaced out.

Again just my two cents which probably aren't warranted and don't take them as big issues just tossing stuff out there in case you find it worth thinking about.

Cannot wait to see further progress!  

[Prodigga]

Hey guys, so I reworked the entire product tree, I wasn't happy with it and it didn't feel very clean. Too many products interacting with one another. The current idea is to have a base set of products that can be produced on any planet, but also have planet specific products that need a certain type of planet to be accessible. (ie - forest planets will have access to wood, which can be a planet specific construction resource.)

Initially everything will be kept separate, with the player dealing with only one planet type at a time. Later down the product tree the player will be able to construct new buildings that require construction resources from different planet types (ie - Glass can be made on a desert planet, and wood can be made on a forest planet, maybe there is a new building type that requires both glass and wood).

I have also reworked the UI a little bit. Instead of selecting which structure to build, the player selects the product they wish to produce, and the game tells them which buildings are required to create that product. This is similar to how Anno works, I think. It is much easier to grasp than a big list of structures..!

Also, factories no longer have an array of outputs. They can only output one thing. It was way too confusing, especially if you placed a large number of a factory in one area and configured them all to output different things. It was too hard to keep track of which factory was doing what. There was no visual distinction between factories. This means I am going to have to have more structure meshes in my game, but I am just going to have to deal with it I guess, because the other way just doesn't work.

This is how the construction menu looks right now.


Lets say the player wants to create Meals (second last icon), they click on it and see this:


Oh and since each factory only produces one single thing, I can also show the recipe for the thing they output in this UI - for example, the Restaurant needs 1x vegetable, 1x meat and 90 seconds to output 1 meal.

And yeah, I've also started adding in some resource deposits, and I have restricted the building placement so that you need to build certain structures on top of resource deposited. There is some semblance of a game, finally, haha.

Here is a before and after pic for a planet with some ore deposits. Note that I use the same mesh for all the structures for now - new meshes coming later!






I have built up a lot of technical dept implementing all this stuff, since most of it is hacked it and not very neat. I need to upgrade my tilemapping system to handle more complex interactions (ie: which tileset/tile to use if constructed over water, which tileset to use if tileset is bordering a certain type of tileset, which tileset to use if one tile is constructed over another), I need a nicer way of handling placement validation, and lots of other stuff.

[Prodigga]

Not a big update today, rewrote the tile system to support tileset switching based on conditions. Now I deal with tileset 'groups' which contain multiple tilesets internally, picking the appropriate tileset based on the conditions. In the image below, check out the road tileset group and the forest tileset group in action. The road tileset group has a base tileset, and 2 conditional tilesets. First conditional tile set is the "bridge anchor" tileset, which is used if the road tile is overlapping water, and touching a cliff. Second is the "Bridge" tileset which is used if the tile is overlapping the water tileset. The Forest has 1 conditional tileset. It uses a version of the forest tileset with the middle strips of trees removed if it is overlapping with a road.

[pturecki]

Looks very nice so far!
Hope that in-game dependences (resources, buildings, etc) will be complicated and giving a lot of possibilities

[Prodigga]

Hah, well, this is an area I am playing around with and experimenting with now! Its gonna be a tough one, since it is like 50% of the game.

I think I mentioned before but the idea is to have a few planet specific resources. (Found on Ice, Forest and Desert planet) as well as a common set of raw resources found on all types. These will be used to construct an array of planet specific structures to manufacture planet specific goods. But in the late game, you will need raw resources from different planet types to construct more advanced structures. That's when itll get complicated. This should amp the difficulty greatly, but at the players own pace.

I've finished the final touches on the tileset system. Now I have even more features I want to add to the system, but I think I will hold off for a little bit and focus more on gameplay. To wind down and relax, I've been putting together some new structure meshes. I am only making meshes for structures that I know will be in the game, since I could end up removing some of the ones I have planned once I get further in to balancing.

I've also been getting into writing my own shaders. One of the biggest issues in ACHs is rendering everything efficiently. There is a lot of meshes! Each "cell" (hexegon) on a planet consist of 6 submeshes ("wedges" - one for each triangle). The largest planet has around 600 cells, so that means rendering 4800 unique meshes for just the terrain alone. I've gone in to detail regarding the tile system before, but to recap the meshes are unique because each tileset mesh has to be deformed to fit the target wedge correctly. Add another 600 meshes for a planet that is completely covered in structures - that's a lot of stuff to draw..! And that's excluding layered tilesets - for example, a forest on top of a land tile would be 12 unique meshes. (6x Forest wedges, 6x land wedges).

The obvious solution here is GPU instancing. But the issue is that you can only use GPU instancing to draw the SAME mesh multiple times. Since my meshes need to be deformed, I clone the source mesh and deform the verticies to fit the target wedge and that results in a unique mesh. This is why I have started to dive in to shader development. I am moving the deformation code in to the shader and performing the deformation at runtime in the vertex shader. This means that I can batch all the drawcalls together for a certain tileset mesh. This lowers drawcalls drastically, a huge improvement to performance. Unfortunately the GPU instancing features in Unity are relatively young, so I am waiting on Unity to release some more functionality to make it even better.

The other issue with the GPU instancing approach is that I can't animate meshes using traditional methods. Skinning is out of the question (1 drawcalls per structure, 600 skinned structure meshes per planet, yeesh!).

So again, shaders come to the rescue! I am putting together a handful of shaders that support some form of vertex animation. Currently, I have 2. Shader one moves a set of verticies back and forward between 2 points, and shader two rotates a set of verticies around a pivot. I mark which verticies need to move by setting the vertex color on the required verticies to white. Black verticies stay where they are. This means I can perform some limited animations per structure, and still batch the same structures together via GPU instancing.

Here is a gif of that in action. This is the copper/iron ore structure:



This is using the rotation shader. The blade verticies are marked as white, and the body as black. Body stays put, blade rotates, still a single mesh!

I want to take it a little further and "layer" some simple animations, but this is surprisingly complicated to do in a vertex shader. For example, it would be nice to have a shader that can bounce around a set of verticies. I could apply the bouncing effect to the blade and the girders holding it in place. Then I can apply the rotation shader on top of it. The result being a blade that spins while bouncing around a little. Oh well. I can look in to that later!

Here is a gif of the mine on a planet!