Jump to content


  • Please log in to reply
UI and Artwork / Feedback + Suggestions
4 replies to this topic - Started By owen, Sep 29 2015 08:18 AM

#1 owen

owen
  • Members
  • 55 posts
  • Pip
  • LocationCanada

Posted 29 September 2015 - 08:18 AM

Hello,

I've played this for about 30 hours now, reaching one month of game time on both Black Sands and Peaceful Forest. Both of those games are still going strong, with no end in sight.  So, I hope you'll value my feedback.

 

This topic is simply to list a bunch of unrelated suggestions that I had about the user interface and the artwork, but nothing about the game balance   (I'll do that in a separate thread).  If I make a claim, it is just my opinion.

 

 

Artwork

 

Overall, I like the pixely-vibe you have created.  Some of the artwork is great, but some of it is god-awful.

 

  • Sprites: Best artwork in the game.  The walk cycle and the slime animation are delicious.
  • Buildings:  They're okay, but the total bird's-eye perspective clashes with the  perspective in which the creatures are drawn.  I think that a C&C-1 type perspective (45-60 degrees from the plane) with no outlining would look more appealing.
  • Terrain: It's acceptable.  The base-layer terrain is nondescript as it should be, although the trees and rocks would look better if they were drawn as individual objects instead of as a giant blob.  Those too, would look better drawn at an angle almost from the top.  Maybe investigate palette cycling for the shore lines?
  • Fonts: Very nice.
  • UI: Decent to terrible.  Some of the icons are okay, like the heart, but others are rather difficult to interpret.  When I first played the game, I thought that the "no-housing" sign was a sandwich with an X over it.   I think more vibrant colors might work here. It's also near impossible to make out what's going on in the spell menu.  I would find it more appealing if spells and buildings were represented by pictographic icons rather than cropped screen shots.

I do wonder if you could find an artist for the UI icons.  A little bit would go a long way.

 

Side note: Smooth animations rather than the jerky mess that is Gnomoria.

 

UI

 

1.  It's hard to see anything in battles.  It's particularly important to see the individual user health bars, but all the sprites just clump up so I don't know if anyone is dying.  Perhaps the hitbars could automatically spread out if there is a battle, with lines pointing to the sprite they represent.  It would be nice if this interface would allow me to individually recall villagers as well.

 

2.  Particle effects are okay, in small numbers.  However, they start to get very distracting once I get up to 20 essence collectors.  Additionally, there is an absurd amount of blood and slime later in the game, and it's hard to make sense of anything.  I don't have the world's greatest video card, either (Nvidia GT 740), and I am starting to notice severe slowdowns at 300 population when large battles take place (of course, this might not be particles... I don't know).

 

3.  It's nice that the screen shakes when something is under attack, since this effect is also used for lightning, maybe there could be an additional "UNDER ATTACK" warning that pops up at the edge of the screen?  Click on the warning to focus on the action.

 

4.  Allow buildings to be placed over unformed terrain.  In other words, villagers who are employed in a resource industry can deliver their building materials to unformed terrain, but the builder still needs to terraform the square before construction can begin.  This would make clearing + building less of a PITA, and it would greatly speed up construction.

 

5.  HOTKEYS.  FOR EVERYTHING.  Much faster than having to click on stuff.

 

6.  Ctrl+Click assigns a worker to repeatedly harvest from a square.  Currently, you have to reassign work to farmers and crystalliers, which gets tedious.  A square to be repeatedly harvested could be indicated by an orange or blue dot.

 

7.  Alt+Click (or Shift-Click) un-assigns work of the particular type that is selected.

 

 

 

 


  • 0

#2 Rayvolution

Rayvolution
  • Developer
  • 1,892 posts
  • Pip
  • Steam ID:Rayvolution
  • LocationTexas

Posted 01 October 2015 - 01:55 AM

Sorry for the slow reply, I try to reply to everything within a day or so of seeing it. But I've been really busy getting InDev 16 U5 out the door, so I've only been replying to the shorter posts. :)

 

 

 


UI: Decent to terrible.  Some of the icons are okay, like the heart, but others are rather difficult to interpret.  When I first played the game, I thought that the "no-housing" sign was a sandwich with an X over it.   I think more vibrant colors might work here. It's also near impossible to make out what's going on in the spell menu.  I would find it more appealing if spells and buildings were represented by pictographic icons rather than cropped screen shots.

 

The GUI is definately not completed. Once the game gets closer to the end stages of development, I'll probably go crazy and overhaul all of it. Problem with GUI work in a really deeply in development game is it changes so often it's hard to ever really polish it. That's why almost all Early Access games suffer from really ugly interfaces. :/

 

 

 


1.  It's hard to see anything in battles. It's particularly important to see the individual user health bars, but all the sprites just clump up so I don't know if anyone is dying.  Perhaps the hitbars could automatically spread out if there is a battle, with lines pointing to the sprite they represent.  It would be nice if this interface would allow me to individually recall villagers as well.

 

I agree, I need to figure out a cleaner way to handle combat. A common complaint I hear is "what are my villagers doing?" when I watch youtubers/livestreamers play the game. They can't see the monsters, and wonder why their villagers are randomly getting hurt. They usually figure it out, but it's still a problem. It needs to be much more obvious. One short term solution would be to make them avoid standing on top of each other so often.

 

As for the recall, it's actually designed to be random on purpose. But, if it wasn't how would you recall specific villagers in that mess anyway?

 

 

 


2.  Particle effects are okay, in small numbers.  However, they start to get very distracting once I get up to 20 essence collectors.  Additionally, there is an absurd amount of blood and slime later in the game, and it's hard to make sense of anything.  I don't have the world's greatest video card, either (Nvidia GT 740), and I am starting to notice severe slowdowns at 300 population when large battles take place (of course, this might not be particles... I don't know).

 

The slowdowns actually aren't the particles, it's the AI. But I've improved that in Unstable 5, so you should see a great improvement now (If you're using the Unstable builds). :)

 

I also plan on redoing how blood splatters work, because as you found out, later in game the blood gets a bit over the top. This is mainly because everything simply has higher hit points and hits harder, so there's naturally more blood because the fights are just lasting longer. I plan on giving every mob a sort of limited "blood pool" that slowly regenerates. If the pool empties, they stop releasing blood when they're hit. This would all be invisible to the player, but the results will basically mean in huge fights things won't bleed so much. :)

 

The alternative is to simply detect how much blood is in an area and reduce the rate more is generated, or alternatively, make it decay faster. Pretty common tactic you see in a lot of games with this problem. (Some reason bullet holes in old first person shooters come to mind)

 

 

 


3.  It's nice that the screen shakes when something is under attack, since this effect is also used for lightning, maybe there could be an additional "UNDER ATTACK" warning that pops up at the edge of the screen?  Click on the warning to focus on the action.

 

Lightning screen shakes removed as of Unstable 5, another user asked me to remove it a few days ago. :)

 

As for the under attack message, how about instead a small red arrow that rolls around the edge of the screen, always pointing at things being attacked?

 

 

 


4.  Allow buildings to be placed over unformed terrain.  In other words, villagers who are employed in a resource industry can deliver their building materials to unformed terrain, but the builder still needs to terraform the square before construction can begin.  This would make clearing + building less of a PITA, and it would greatly speed up construction.

 

Actually already planned, just right now the entire object placement engine would have to be rewritten to do it. That's not a big deal, I've always intended on doing it, it'll just take a while to code. It's on my "Someday" wishlist when I have time. :)

 

 

 


5.  HOTKEYS.  FOR EVERYTHING.  Much faster than having to click on stuff.

 

Totally agree! I'm long overdue a hotkey overhaul. There are a bunch of hotkeys already though if you didn't know, you can find them all in the settings menu.

 

 

 


6.  Ctrl+Click assigns a worker to repeatedly harvest from a square.  Currently, you have to reassign work to farmers and crystalliers, which gets tedious.  A square to be repeatedly harvested could be indicated by an orange or blue dot.
 

 

Sort of a "Just keep harvesting everything in this region" selection? That's planned too. :)

 

 

 


7.  Alt+Click (or Shift-Click) un-assigns work of the particular type that is selected.

 

Not sure what you mean? Sort of a unassign tool that works while you're using the assign mode, only on the currently selected assignment? (IE; hit Assign Wood, shift click and it unassigns wood instead?)

 

Sounds like a good idea, I can add that to the list of things to add when I work on hotkeys.


  • 0
Rise to Ruins Developer

#3 owen

owen
  • Members
  • 55 posts
  • Pip
  • LocationCanada

Posted 01 October 2015 - 09:47 AM

I agree, I need to figure out a cleaner way to handle combat. A common complaint I hear is "what are my villagers doing?" when I watch youtubers/livestreamers play the game. They can't see the monsters, and wonder why their villagers are randomly getting hurt. They usually figure it out, but it's still a problem. It needs to be much more obvious. One short term solution would be to make them avoid standing on top of each other so often.


As for the recall, it's actually designed to be random on purpose. But, if it wasn't how would you recall specific villagers in that mess anyway?


Okay, fair enough about Recall and Banishment working in that manner. I was hoping that I could warp-out individual villagers right before their death (by selecting them and then clicking a recall button on their stats panel, or simply by selecting them and pressing a hotkey combo), but the existing method is a valid combat mechanic as well. (On the other hand, I'm not fond of the send-to-Limbo spell operating as an area-of-effect spell. It seems like the ratio of the cost of influence to things sent to Limbo would be something that should be tightly controlled.)


As for combat, yes, it should be cleaner. In RTS-games like Starcraft, worker units typically ignore collisions with other units while they are ordered to gather. Fighting units, on the other hand, always collide with one another. So, I think that simply limiting one fighting-unit to a tile would be a perfectly valid solution, not just a short term solution. In this way, only four (or eight, if you count diagonals to be adjacent tiles), melee units could attack a single target at once. Resource gathering or fleeing units should still ignore collisions as they seem to do now.





 

As for the under attack message, how about instead a small red arrow that rolls around the edge of the screen, always pointing at things being attacked?


Yes, that would be great, and if I can click on it in order to centre my screen on the action, that would be even better.
 
 
 

Not sure what you mean? Sort of a unassign tool that works while you're using the assign mode, only on the currently selected assignment? (IE; hit Assign Wood, shift click and it unassigns wood instead?)


Yes, that's exactly what I mean. It would be useful in situations where I want to execute a remove-terrain order over a tile with Resoure A that already has a gather order, without disturbing orders to harvest different resource types B and C on adjacent tiles. (I do this when I want to motivate land).


  • 0

#4 Rayvolution

Rayvolution
  • Developer
  • 1,892 posts
  • Pip
  • Steam ID:Rayvolution
  • LocationTexas

Posted 01 October 2015 - 01:42 PM

Actually I think in Starcraft and Warcraft the units are never allowed to overlap, but they can get a little closer to each other when moving around. I remember times where I had some units blocking others, or big unit movements bottle necked because of a small passage they all had to get through. I would actually prefer RPC's AI to work that way. I never liked how mobs overlap each other.

 

It'll take a lot of playing around with pathfinding to find an optimal way of doing it though. From a coding standpoint it wouldn't be hard at all to detect the tile positions of the mobs on the map before generating a path. Although without some tweaking it might cause some really strange behavior.


  • 0
Rise to Ruins Developer

#5 owen

owen
  • Members
  • 55 posts
  • Pip
  • LocationCanada

Posted 02 October 2015 - 04:07 AM

At least in StarCraft 2, they definitely can overlap, and a couple micromanagement techniques have been devised to exploit this ability.

 

Nevertheless, the reason I suggested that fleeing and working/harvesting units shouldn't be able to collide are that:

  1. Normal village-building operations will be a lot smoother if villagers don't collide (and pathfinding should be less complicated, too, though I don't know if that's a concern).
  2. Fleeing units won't get boxed in by their comrades-in-arms, and melee units will work more dependably.  That is, melee villagers will fight until they are in red health, then they will flee backwards through their ranks, and the next melee villager will push up.  If four level 6 guards are fighting a level 9 skeleton, the skeleton will always target down one guard, who will flee before he dies.  We should either always have a dead skeleton or four guards at 5% health.

 

So, taking those two points together, I predict that the outcome of a lot of basic operations in the game can be made at lot less uncontrollably variable through the clever use of colliding and non-colliding pathfinding.  I say "uncontrollably," because, as a developer, you might decide that you want some variation in the outcomes of 100 identical battles or how fast a building constructs, but it would be nice to have some way to control that variance.  As a player, you don't want your stone shack to build twice as slowly because you placed it one square too close to something.  Non-colliding fleeing and working eliminate these concerns of variable outcome due that result from pathfinding.  Variability can than be modified by adding an additional

 

Looking at it in context from the rest of the game, if you're coding the pathfinding in such a way that the same battle between 100 soldiers results sometimes in 90 deaths and other times in 60 deaths, well, it might be an interesting mechanic in its own right, but it then becomes difficult to balance such a large and complicated game when the simplest systems are so variable.

 

As a concrete example, a soldier could be programmed to always flee at 10% health and to collide with comrades while fleeing so that ends up dying 3% of the time in battle, or he could be programmed to have an x% chance of fleeing (without colliding with comrades) when he's below 10% health such that he ends up dying 3% of the time.   Now say you want to increase the chance of death from 3% to 7%.  In the second scenario, there is a very well defined relation between x and the chance of death, which should be easy to calculate, and you only have to modify x.  In the first scenario, you have to modify the threshhold health at which to flee (10%), but there's no way to calculate the death percentage that results from your modification, because fleeing is entirely dependent on the terrain and the battle conditions when collision is a factor.


  • 0





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users