Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411279 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 03:33:31 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsWeathered Ambitions - Isometric colony sim, multiple z-levels, malleable world
Pages: [1] 2
Print
Author Topic: Weathered Ambitions - Isometric colony sim, multiple z-levels, malleable world  (Read 5780 times)
ashen
Level 0
**


View Profile
« on: December 21, 2015, 07:15:23 AM »

Weathered Ambitions  (working title)

A survival oriented, base building game set in a malleable and living landscape.  



In this game you will control the fate of a small party of travellers following a winding path into the deep wilderness for days.   With no clear destination their only desire is to escape some awful fate back in "civilization".  

Now, on the verge of exhaustion they survey the land surrounding them and decide that this has to be the place.  They step off the path...    


One of your people and 'a friend' (a deer grazing) on a bridge.



Same view at maximum zoom-out. The major river meanders past a lake and under two bridges.



A christmas style view of a mountain.  Notice the cascading stream on the right.




Lost in the woods at night.  Fully zoomed-in.


Animated gif showing one of your people walking across a bridge in front of waterfalls. (Choppy due to gif frame rate.)




Background:

I'm starting this dev blog to help me get this game to a point where it's playable and hopefully fun.  I've been working on this by myself on and off for about a year and so I'd really appreciate any feedback or constructive criticism you can provide.

It's a classic isometric '2.5d' view with multiple Z levels to represent the world.  Internally it uses a big array to represent a 3D world, so it could be called voxel, but the graphics are all fixed angle 2D.

The custom graphics engine is mostly complete and provides smooth scrolling, animated moving sprites/objects, 4 levels of zoom, 90 degree view rotation, basic lighting (static and moving)  and 'height slicing' allowing you to look inside constructions, mountains or down into the earth.

As for the graphics, I'm a programmer so I'm going for a 'plausible' look where individual objects don't need to look perfect.  This is a a game where, I hope the sum of the graphics is greater than the parts.  I'm doing the graphics using mainly Blender. So if you have any feedback about lighting, coloring, saturation  etc, I'd be very happy to hear.  

I'm taking inspiration (gameplay and/or visuals) from some classic games including Powermonger, Rollercoaster Tycoon, Dungeon Keeper, Stronghold,  Dwarf Fortress, Minecraft, Don't Starve, Gnomoria, Rimworld.

While it's not the best game in the list, one of the key things I'm really trying to capture is the feeling of amazement I got as a kid the first time I clicked on a tree in Powermonger and a popup window said something like:
   
   "An Oak in the forest of Tognoy, It is Autumn.  There are birds in the tree."

Then the birds flew off  because a warband of enemies was marching along a nearby road, heading straight towards my only village.



Partially complete features:

  • Trees, bushes, grass, animals are alive and react to the changing seasons and your actions.
  • Flowing and still water.  You can and must use water to your advantage.
  • Temperature and seasons.  Altitude affects the climate.  Light a fire to keep warm in winter or freeze.
  • Rain will refresh the soils and green drying plants.
  • Snow will fall and then melt as the temperature increases.  

Planned features

  • Build multi storey buildings, workshops and various furniture for the comfort of your people.
  • Mine the depths for precious metals and  resources.
  • Explore mountain caves and deep caverns containing wealth and danger.
  • The path and the river will be used by others including:  traders, those wishing to join you, and still others who have been searching for your party and may not be friendly.
  • Find and cultivate wild plants and animals.
  • The balance of nature is a fine thing.  Cut down too many trees, kill too many animals, dig too deep too often and nature may take actions to restore the balance.

Thanks for reading and once again feedback is very welcome!
« Last Edit: January 06, 2016, 07:20:08 PM by ashen » Logged

ashen
Level 0
**


View Profile
« Reply #1 on: December 22, 2015, 05:13:25 AM »

Z-slicing

I've been working on a path-finding bug where the destination is an underground location.  I'm using indexed A-Star so the culprit is in the GetCost() function.  When it reaches an underground location it returns 'MaxCost' even though the location is passable.  GetCost() can be called thousands of times each search so I tried to in-line the code to optimize it a bit.  Unfortunately this makes the code a little less understandable which of course has probably contributed to the bug, oh well!

This reminds me that I want to show an essential feature in this type of game, Z-slicing, allowing you to see underground and inside buildings.

You turn on Z-slicing by first positioning the mouse at the altitude you want to slice at (often just the roof or location above) and pressing the Shift key.

Now only locations with smaller Z coordinates are displayed, in effect slicing off the top part of the world. You can then use CTRL mouse-wheel to move the slice up and down.  Shift will turn slicing off again.

When slicing is on, you may notice locations towards the viewer that are next to a wall are obscured and can't be easily interacted with.  You could rotate the view 90 degrees but this can often be a pain. 

Therefore I also provide an option to 'flatten' nearest wall locations, similar to Stronghold or Gnomoria.  You toggle this on and off by pressing the F key. When on the wall locations are replaced with an lowered empty cube.

A mountain with an excavated tunnel and room. The mouse is positioned at a good location to slice.


After pressing Shift to slice.


After adjusting the slice level upwards using the mouse wheel.



Zoomed in on the room showing the 'Flattened' walls allowing access to obscured locations.


Same scene rotated 90 degrees counter-clockwise.

Logged

RujiK
Level 2
**



View Profile
« Reply #2 on: December 22, 2015, 05:26:43 AM »

The bridge looks kinda weird. (It casts two shadows?) But the game looks pretty nifty. I'll be watching for updates.
Logged

ashen
Level 0
**


View Profile
« Reply #3 on: December 22, 2015, 05:50:07 PM »

RujiK, Thanks! It is a bit confusing right now but there is just one shadow.  The shadow is the shading running parallel to the bridge on top of the water.  The second diagonal shading is actually just  exposed dirt on the river floor, left over from world generation. As the water is translucent you are seeing the river floor. I need to fix this, it should be gravel like the rest of the river.
Logged

ashen
Level 0
**


View Profile
« Reply #4 on: December 23, 2015, 05:01:18 AM »

The AStar path-finding in action

I thought someone might find it interesting to see the indexed AStar pathfinder actually running in debug mode.  The goal is the white box (mouse location) at the top of the tower.

The displayed numbers are the calculated cost at that point in the search.  'X' means the location is un-passable.  All considered locations are shown, not just the final path.

The underground path fining seems to work for most situations now, notice how the guy correctly walks through the passage under the wall.

Anyway, merry christmas everyone!


Logged

ashen
Level 0
**


View Profile
« Reply #5 on: December 30, 2015, 09:49:53 PM »

Recently I've been working on some graphics for the rain and snow in the game.  The game is currently called 'Weathered' Ambition so I thought I'd explain why.  I envisage that an important factor in the survival of your people is mastering the effects of rain (or lack of it), snow and temperature.  

I've implemented simple clouds (circular) that move in a general direction from the North to the South across the map.  Each cloud is centered on a single location and has a circular radius that dictates how large the cloud is.  Each 'surface' location under the cloud is slightly shaded indicating the shadow of the cloud.  Currently you don't actually see the cloud, just the shadow and the rain/snow effects.

The cloud constantly rains on each location within it's circular bounds.  On every second game update, it iterates through a shuffled array of 'location offsets' and deposits afixed amount of water at that location.  Depending on the speed and direction of the cloud, a location can receive multiple rain deposits ( clouds currently move quite slowly).

Rain only occurs if the temperature at the surface location is above 0 degrees (celcius) .  If the temperature is less than 0, snow falls instead.  Snow builds up on top of the surface location as more is deposted (3 levels currently).  Snow will begin melting and deposit water to the ground below once the temperature rises above 0 degrees.

The temperature system is already dynamic in that temperatures rise as the day warm up and then drop again over night.  It is also affected by altitude, higher altitudes have a lower temperature than those in the valleys.  When seasons are implemented this will also affect temperatures, of course.

In this picture you can see the snow falling in colder higher altitudes and rain falling in the lower ground to the right.  You can also see the cloud shadow as it moves across the hill.


Once the rain or melted snow water is deposited into the ground, the water system takes over.  Each land location has a capacity to contain a certain amount of non visible water.  This water gradually seeps from one land location  to it's neighbours each game update.  In this way locations that were not rained on but are next to rained on locations will receive water (likewise with locations next to rivers/lakes).  

Grass growing on dry soil will slowly 'brown off' until it is completely dry and then it will start to die.  When water is deposited to a location containing grass, the dryness attribute will reduce and the grass will gradually appear more green and lush.  Currently grass has 4 levels, seedling, short, medium, long.  Grass only grows when temperatures are warm and there is a reasonable amount of water/moisture in that location.  Grass will be fundamental to feeding animals, building materials and other furniture.

Soil locations also have a soil quality attribute.  This will affect plant growth also and will be important for growing crops and other domesticated plants.

Temperature/altitude will have an effect on the type of trees/plants that grow in certain places.  
The Oak trees already have a winter, spring, summer, autumn style) and will change over time.  Of course I need to add seasons to really make this feel alive, but  I may hold off on that just yet as I really need to get the basic survival game-play working so I have something that looks more like  a game.
 
Anyway that’s a ridiculously quick summary of the weather/nature system right now.  
« Last Edit: December 31, 2015, 06:09:31 AM by ashen » Logged

m4s0n
Level 0
*


View Profile
« Reply #6 on: December 31, 2015, 04:42:29 AM »

Hey ashen. I'm enjoying your devlog. We're taking inspiration from similar titles so I'll be following this with interest. You're quite a way down the road! Thanks for posting that visualisation of pathfinding, I'll be tackling that in a few days. I think your goal for the visuals is working. It's cohesive and, while pleasant, gives a tone that will suit a survival game. Thanks for sharing Smiley
Logged
ashen
Level 0
**


View Profile
« Reply #7 on: December 31, 2015, 06:07:24 AM »

m4s0n Thanks, I really appreciate the feedback.  Yes, I've been working on this for a while and it's something I really want to push further.  I hope this dev log will help me do that by having a few more eyes on what I'm doing. 

If you need any tips/links on my approach to the path finding, feel free to ask.  I'm not an expert but in my experience the A-Star algorithm is pretty straight-forward (even in 3D it's still just a graph of connected nodes, except each node has more links than 2D), the harder part is optimizing it, if you need to.

Thanks for the feedback on the visuals, it's an area I am less confident about so any tips are welcome.

Have a great new year!
Logged

ashen
Level 0
**


View Profile
« Reply #8 on: January 04, 2016, 09:35:49 PM »

Design of the AI System in Weathered Ambitions

Just thought I'd write about the AI system I've implemented for Weathered Ambitions.  I hope it's not too technical/boring but if you need to do something similar it could be useful.  

Also, the act of writing it down really helps me get things straight in my mind.  It's amazing how you spot flaws in your own design/code as soon as you have to explain it to someone else.   If you see any fatal flaws or other feedback in the design/approach below I'd be extremely happy to get feedback (I'm not an AI expert).  

This is a colony simulator / base building game.  So each character needs to be able to make decisions for themselves and be able to meet their immediate needs (where possible) autonomously.  I intend to support reasonably large settlement sizes such as 100 or more people as this fits in with the largish world map and detail of the world.    This means I need a pretty flexible and efficient AI system.  

Behavior trees, not this time

When researching AI last year I quickly came across Behavior trees.  They seem to have become the standard approach for AI in modern games largely due to the following advantages (from my reading):

   • The tree structure is very flexible, it supports composing more complex behaviors from simple behaviors.
   • Good possibility of reusing simple behaviors in many higher level behaviors.
   • It's simple to build GUI tools for designers to let them visually construct behavior trees.
   • Good performance, depending on implementation.
   
However the more I read about them the more I realised that when it comes to actual implementation everyone seems to have a different view on how to do it.   The major question seems to be: do you process the entire tree on every AI update, or do you give the tree some state that remembers the current behavior node and  only process a maximum of nodes per game update?

I think there's  no single answer to this.  It depends entirely on what the specific requirements of your game. Maybe this is premature optimization,  but for Weathered Ambitions I immediately felt a bit uncomfortable at the idea of processing a possibly large behavior tree entirely for every entity  on each AI update.  I know that in many cases the behavior tree may only process one branch of the tree (maybe only 3 or 4 nodes) and then finish, however in other cases some branches can be quite deep and it concerns me that 100 entities (or more) may all be executing similar trees.

Action Lists to the rescue

So instead I have decided to go with a flatter 'Action List' style AI system.  For a decent overview of Action Lists see https://docs.google.com/presentation/d/1kzxp8jfO3GvQsfWo3JHW2b44l9rC9g0jEDJzmU5I_No/edit#slide=id.p

Now, instead of a tree of behaviors I now have the concept of Tasks, Actions and Lists.

   • A Task is a higher level concept such as 'Chop down a tree' or 'Warm myself up' or 'Satisfy my hunger', 'Wander around doing nothing (Idle)'.
   • An Action is a lower level, specific thing, that can actually be done, such as 'Move to location' , 'Eat food', 'Find path to location', 'Cut tree trunk with axe' .
   • An Action List is owned by a task and simply contains the group of Actions making up that task.


Here's a diagram showing the main classes:



Each task class is initialised with a list of actions.  These Actions are added to the tasks action list in a specific order in which they must be completed.  Once all actions in the list have been completed, the Task is complete.  

An entity can be assigned one or more tasks, actions are never directly assigned to entities.  Each entity contains a 'priority queue' (a binary heap data structure) which supports efficiently getting the current highest priority task to work on.  New tasks are just added to this queue and may then become the current task if the priority is high enough.  Completed tasks are removed from the queue, allowing th next highest task to be worked on.

All tasks are designed to be restartable.  If another higher priority task  is created, the current active task is 'suspended and will simply wait to be resumed when it becomes the highest priority again. This means a task contains task state information to support this and it also means that a Task object can't be shared between entities and needs to be created for a specific entity at runtime.  

Actions however do not have any state and are completely re-usable.  I currently create them as static objects that are then added to the action list of many different Tasks.  

Actions are the key

The whole point of most Actions is to change the state of an entity (eg Move to a location),  therefore when a new task is created and assigned to an entity, a reference to the entity is also passed to the task. Then, when the task steps through it's action list, it passes the entity to each action allowing the action to change the entity state as needed.  

As a task steps through its action list, some actions will take longer  to complete.  We can't just wait for them as some may even take seconds to finish and need to be spread out over game updates (eg path finding).   Therefore an Action can return a Success, Fail or Incomplete status code.  A long running Action will normally return Incomplete .  When it does, yhe task will stop processing the action list at that point.  Then, on the next AI update, it will start the Action list by calling the long running Action again.  This will repreat until the long running task returns Success of Fail.

There are also 'conditional' and 'grouping' Actions such as AndAction, OrAction, JumpIfFailedAction etc.  These Actions are created with one or more child Actions .  When one of these Actions is run, it first calls it's children and checks the result of each to determine what status it should return.  This provides similar flexibility to the Selector, Sequence and other compound behaviors in behavior trees.

In summary

So, overall this system seems to be working quite nicely for me so far.  The biggest benefits are the flexible and re-usable group of Actions.  I only have about 25 Actions right now and I am already re-using almost all of them across multiple Tasks.  Creating and initializing Actions once at startup, as static objects, is also essential to avoiding a huge number of allocations and garbage collection operations at runtime.  

I also really like the cleanness of keeping state in Tasks and only in Entities where necessary.  I think that as it grows this will become even more important in helping keep AI organized.  From what I've heard this is actually the hardest part of game AI, ie. managing the complexity of it as you get into hundreds of tasks / behaviors.

A lot of this may sound a bit of overkill, after all it's just a game.  However this is a colony simulator, base building game where the ability of your people to react plausibly to the world around them and not do too many 'stupid things' is very important in determining if the game is fun or not.  You will get some direct control over them, but at other times they will need to make their own decisions. The graphics in this game are nothing special and the story may not be incredibly original, I am well aware of that.  So in my mind it's the plausibility of the AI and the how fun the world systems are that will make or break this game.

Thanks for reading and once again if you have any feedback or questions feel free to ask.
Logged

Jasmine
Level 5
*****

Boop


View Profile WWW
« Reply #9 on: January 05, 2016, 05:06:27 AM »

Oh, the benefits of Behavior Trees seems exponential and extremely easy to follow along with (at least through your devlog). It looks like Weathered is turning into a very solid game.

Also, don't stress out over the skin - the artwork (in my opinion) is solid and not detracting. I was talking to a friend of mine about how some of the most popular games (albeit rpgs) were made by musicians. Perhaps lacking in one area instills a desire to make up for it in other. Plus, gameplay is the most important facet of a game, and you seem to be nailing it.

Keep up the good work, man!
Logged

ashen
Level 0
**


View Profile
« Reply #10 on: January 06, 2016, 01:23:41 AM »

M4uesviecr, Cheers for the encouragement on the artwork (and game in general). I find it a bit weird calling it art as it's currently just 2d rendering out of Blender, but I guess there is some artistic skill in deciding what looks ok and what doesn't at least.
 
Still lot's to do though, I'm hoping to update with more features soon.
Logged

RujiK
Level 2
**



View Profile
« Reply #11 on: January 06, 2016, 08:54:58 AM »

I like the water! Flow physics/pseudo-physics are always awesome.

Does the water evaporate too? If it doesn't, eventually the whole map will be flooded!
Logged

ashen
Level 0
**


View Profile
« Reply #12 on: January 06, 2016, 06:53:38 PM »

RujiK, yes water currently evaporates from each surface location (if it contains water).  Evaporation is currently a constant rate but I may change it to evaporate more when it's warm and less when cooler.  Water also seeps into neighboring land locations.  

Water 'flows' to neighboring locations using an averaging algorithm at the moment.  To avoid performance problems, water flow is updated during the normal location update cycle which means regardless of how much water there is on the map it should be reasonable constant performance.  This works, but it means if you destroyed the wall of a dam, the water would not exactly rush out of the gap as in real life.  

Each world location has 2 bytes (0-65535) to store a water value.  A value less than 500 is considered non-visible water level and represents the natural moisture in soil/rock. This is what plants will use to grow and is how the grass can dry out and refresh depending on water level.  

If the value is greater than 500 it is visible water. I subtract 500 from it and then divide by 1000 capping the result at 5. This gives 6 visible levels of water (0 to 5) that you see in the game.  A value of 0 is displayed as a flat water tile with no height, 5 is a full visible cube of water.

The capping of the water at level 5 is actually very useful as it means water will almost never overflow the banks of a river or lake because a water location needs to contain 30000 (iirc) before it is considered 'full' (a water location id displayed as full from 5500 up).  Only when it is full can the location above start filling with water.  This is a actually a *really* simple modeling of water pressure I suppose, but like the rest of the water system it is slower than real-life.  

This and the evaporation is why the world should not flood.  In fact it seems to be generally drying out in my testing, but then again I only create one or 2 clouds at the moment.  There will be a lot of tweaking required to get a sort of balance to the water system.   Fortunately I can easily calculate the total world water amount and perhaps create more or less clouds to keep it within a certain range.  There are also water source locations (eg at the top of streams) where I can adjust the rate of water generated too.

Right now, I see water as a resource primarily and then a game mechanic.  I'm happy with being able to, for example, dig a moat and then fill it with water in a reasonable time, but the main point of it is to support your people, plants and other wildlife (fish etc).  Also a landscape without water features is unnatural so it's important in the natural state it should look plausible and pleasing to watch.  

I might look at 'improving' water in the future, but I really need to focus on game-play now.  The goal of fun game-play will  dictate and make clearer how the water system really needs to work.  (You can spend forever working on systems like Water if you're not careful).

 
« Last Edit: January 06, 2016, 07:11:59 PM by ashen » Logged

ashen
Level 0
**


View Profile
« Reply #13 on: January 15, 2016, 03:09:23 AM »

Just a quick update. I'm working on name generation for the in game characters at the moment.  I hope that by giving them names it will help make them more like people in a harsh world rather than instances of classes in my code.

I've implemented a Markov chain based name generator to do this.  The great thing about Markov generators is that you give them a bunch of input words and it will create any number of randomly generated names that have a similar 'flavor' to the input names.  

Right now I'm using popular English names as input but I could just as easily add another generator using elven or dwarven names and the generated names will be random but recognizable as a dwarvish or elvish style name.

The central idea of the Markov chains to pretty simple.  It analyzes a set of input words by processing each letter in each word and recording the fact that this letter follows the previous 2 letters.  For example in 'derek', r follows de, e follows er, k follows re). So while it works through all words it builds the probability of each letter following any other sequence of 2 letters.  To generate a random word it then uses these probabilities to get the next likely letter until it reaches the end of the 'chain'.

In Markov terms the example is called an chain with Order 2.  It works with other orders too, for example order 3 chains check the 3 previous letters.  The higher the order, the more familiar the generated words are, the lower the order the more random they appear.  I've found that I really only use order 2 or 3 for english words/names. Order 1 gives completely random words, order 4 or higher often just generate words from the input set without much randomness.

The main drawback I've found is that the Markov algorithm needs to build 'models' of the data, one for Order.  This means it is relatively slow to generate names.  With a big input list of say 600 words it takes about 2 seconds on my PC to build the models.  Then to generate say 2000 random words of say 3 to 12 characters it takes about 30 seconds.

As a result I'm currently generating big batches of names and saving them to files once only at initialization.  It would be interesting if anyone knows of any tips to speed the Markov generation up a lot.  Or maybe you know of a quicker algorithm that also generates decently plausible words.

Here's a screen shot showing the names of 10 people with generated names.  The first name is generated using the Markov algorithm (order 3).  The surname is a random adjective-noun combination.



 
« Last Edit: January 15, 2016, 03:16:36 AM by ashen » Logged

ashen
Level 0
**


View Profile
« Reply #14 on: January 30, 2016, 11:21:42 PM »

Just a quick progress update this time.  Since the last post here I've been working on:

- AI, more flexible task allocation system that tries to assign people closer to the task and allows multiple people working on the same task.  This currently works for the chopping down a tree task and will need to be added to all other tasks.

- Unique settler clothing colors.  Each person is drawn using a simple 'paper-doll' approach where I draw the naked body first, followed in order of shoes, pants, shirts, jackets, hair, tools/weapons.  This means I can customize both the color and later on more styles of clothing etc.  See the screen-shot.

- Settler needs (eg 'I'm cold', 'I'm hungry') are now displayed as floating text above their heads for a short period of time. I originally used icons for this but really like the way 'Airships: Conquer the skies' provides text comments to let you know what your crew are thinking.

-  Made the pathfinder use much less memory per search node.  Still need to come up with a search node pooling approach as the 3d nature of the world map means there can be very large numbers of nodes allocated.

-  Worked on a few 3d models in Blender such as barrels, chests etc.

Next I plan to really get stuck into enhancing and improving the 'person list' window.  This will give feedback on what they are doing/thinking and provides the entry point to many of the other screens such as professions, skills, inventories etc.  I also plan to revise the hunger/health mechanic and add some food sources so I can actually start playing the game and keeping people alive.





As always, one of the main reasons I'm posting here is for feedback, not just positive feedback.  So if you think something is not great (and maybe why) I'd really appreciate your comments too. 
 
Logged

marcgfx
Level 8
***


if you don't comment, who will?


View Profile WWW
« Reply #15 on: February 14, 2016, 03:16:47 AM »

interesting stuff. I really like your slicing idea and the water approach/simulation is a really cool idea.
I don't really like the visualisation of the clouds and the water and was thinking they could likely be improved with not that much effort (I might be wrong).

clouds: i dislike the blinking effect you get when the cloud moves, it's too sudden. I don't believe its important that you can see exactly with tile/triangle has the shadow on it. So why not just use a kind of shadow-overlay that moves at the actual pace of the cloud. it could have a real cloud shape. it's not that realistic that its always raining below a cloud anyway. you could also add clouds that don't have rain.

water: instead of using this blocky visualisation, why don't you connect neighboring tiles directly. so you would have actual slopes where the water is running down. maybe you have already planned to do this, as your environment already has some nice slopes.

overall I think there is too much blinking caused by state changes in the visuals making it quite distracting.

keep up the good work!
Logged

ashen
Level 0
**


View Profile
« Reply #16 on: February 14, 2016, 04:31:24 AM »

@marcgfx

Thanks for the feedback, really appreciate it.

The clouds are still at an early stage of development and definitely need more work.  I've deliberately avoided spending much more time on them until I get the core game-play working i.e. keeping your people alive.  Once that's in place (working on it now), the needs of how often it should rain, how many clouds at any time, etc will become much more obvious.

Good point on the blinking effect when the clouds move.  I could possibly use a frame buffer object to render a more smoothly moving shadow in an overlay, but rendering is all just 2d textures from a texture atlas, there are no 3d meshes whatsoever.  I'm also not using a z-buffer so I have to render visible locations using painters algorithm.  I'd need to think more about this.  This could complicate a shadow overlay possibly.  I don't have a lot of experience with shaders either, unfortunately, so not sure if they might an option.

Interesting point on the smoother water.  I hadn't actually considered that, I guess you mean sloping water similar to Minecraft?  For the smaller differences in water height I could probably add sloping water over 1 tile, but as the engine is 2d it would likely require lot's of different 'tiling' transitions between adjacent water, if you see what I mean.  Still I guess that's why I've been using Blender as it can automate a lot of that.  

I wasn't overly happy with the using same waterfall effect for all water differences, even small differences, it is a bit distracting.  I'll probably have a look at this again later, thanks for the suggestions.

I've been heavily focusing on game-play and improving usability recently.  People will actually become hungry, cold, tired and tell you about it.  I've been adding food sources, containers, fires, tents etc.  I've also greatly improved the way you interact with the world (click on things etc).  My next proper update should show most/all of these new things.
Logged

ashen
Level 0
**


View Profile
« Reply #17 on: March 16, 2016, 06:08:09 PM »

I'm still working steadily on Weathered Ambitions.  Here are some of the more important things I've added over the past few weeks:


The game now actually has a basic survival mechanic.  By this I mean people now have hunger, fatigue and body temperature needs that need to be maintained by the player or else they will lose health and eventually die.  This doesn't seem too amazing but it is the central game mechanic that everything else will revolve around.  With this in place I have a simple way of knowing how best to add or update other game systems such as weather, wildlife, temperature, water enemies etc.  Simply: If it adds fun/interest and does not make survival too hard (or too simple) it can be added.  

This is best shown i the new 'People' list I have added.  Graphically it is still incomplete so don't worry about that however the basic functionality is there.  It is a tabbed window, the first tab (shown in the image) displays settler vital statistics. Clicking on a settler jumps and selects  them in the main view.  Clicking a column heading sorts on that column.  I'm not sure I like how the Health bar is 'good' if full, but the other bars are 'good' when empty.  This can be confusing so I may change this.



To support this basic survival loop I've been working quite a lot on AI tasks and actions. For example settlers will see to their own hunger by walking to the storage barrels and eating from them.  They will also pick up an extra meal worth of food so they can eat 'on the job'.  They will also gradually become tired and when fatigue is above 50% will look for a 'sleeping place', move to it and sleep until Fatigue has reduced.  Currently the only sleeping place is a tent,but there will be many more eventually.  

They also become cold/hot depending on the temperature of their current location.  If too cold they will look for a campfire and go stand next to it until warmed up.  All of these tasks are interruptable and have a priority, so for example if a settler is sleeping and their body temperature drops below a certain point they will wake up, go to the campfire, warm up and then return to their tent and go back to sleep.

Tents and campfires are construct-able entities that have specific material requirements to build.  When you request say a campfire to be built, a build task and two delivery tasks are created to find and deliver rocks (for the campfire edging) and branches (for kindling).  Settlers currently Idle will take a task and attempt to find nearest materials either in storage or in natural resources that have been 'permitted' by the player.  They then go and pick up the material and deliver it to the building place.  Only once all of the required materials have been delivered will a settler commence the building task.  When the campfire is complete it is automatically lit and provides heat and light to neighboring locations.

A tent is constructed from a 'packed tent'.  Once built it is a 'sleeping place' for settlers.  A settler sleeping in it will reduce fatigue and lose less body temperature than normal.

Another big addition to support the above AI is a simple entity component system.  This allows me to create components such as Container, Stackable, Edible and add these to any entity to give it more capabilities and features.  I quickly realised that this sort of game could have a large number of entity types that require all sorts of custom attributes/behaviors and the inheritance tree would just not allow this to happen in any sane way.  It works quite well as it uses a simple map (hastable) for each component type that contains references to entities that have that component using an ID field (common to all entities) as the  key.  

The barrels and chests are Container components and you can see the contents and the Entity info window in the screen shot.

Seasons and day length are now more fully implemented.  Deciduous trees such as Oaks and apple trees now have seasonal graphics, bare branches in Winter, bright green growth or blossom in spring, fuller and darker green leaves in Summer, reds/oranges in autumn.  Trees now also spread and provide resources such as acorns and apples.  I also plan to add a few more tree types with different gameplay benefits and growing preferences.

There are fish in the river.  Currently just trout and they don't move very realistically yet, but fishing will be an important source of food eventually.

Anyway that's probably a good summary of the main work done since the last update here.  I'm planning to add more graphics for the settlers such as carrying materials and more tools.  In fact the tool system is probably next up it is currently just a placeholder which has no effect on gameplay yet. Wood axes, picks, fishing rods etc.  

I almost forgot, the deer now move in herds and have a herd leader that they follow.  They will eventually be a hunt-able resource, by your people and other animals.
« Last Edit: March 16, 2016, 06:20:30 PM by ashen » Logged

RujiK
Level 2
**



View Profile
« Reply #18 on: March 17, 2016, 06:52:40 AM »

Deer herding reminds me of stronghold. Neat!

One minor thing: The lighting from the fireplace looks a little odd since it seems to highlight the seams between the tiles. The lighting would look a bit less tiled if there wasn't an outline.
Logged

ashen
Level 0
**


View Profile
« Reply #19 on: March 17, 2016, 07:32:59 PM »

RujiK,

Yes, you've noticed the primitive lighting system I currently use Wink.  I may look more at lighting soon, although until I get some real gameplay happening it is a lower priority for now.

Lighting is currently per location (tile) only.  Each location has a lighting level based on time of day and any light from a nearby light source such as the fire.  As the engine is really just 2d, I just do a setColor(lightLevel) before drawing the ground and objects which gives that seam effect. It's not an overlay or second render pass.

To get smooth lighting, maybe this could be done with a shader but I'm not experienced with shaders. Libgdx actually does all rendering with a shader, but it handles all the setup etc for you. I'm guessing each location would need corner lighting values instead of just a single value, to allow a smoother transition.  Also, I will be adding walls, fences that sit on the edge of a location and would block light from things such as fires. This complicates things a bit I think.

If you (or anyone) has any suggestions on implementing lighting i'd love to hear them.
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic