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

Login with username, password and session length

Advanced search

1055315 Posts in 42848 Topics- by 34775 Members - Latest Member: Fridgecrisis

October 20, 2014, 02:49:12 PM
  Show Posts
Pages: [1] 2 3 4
1  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: October 16, 2014, 06:39:39 AM
Forgot to mention: for movement paths and outlines we'd like to go with smooth, curving lines over sharp, angular ones. Quadratic bezier curves can be used to achieve this look, and here's our first shot at it going through a colour-cycle:

2  Feedback / DevLogs / Movement Indicators on: October 15, 2014, 11:53:10 AM
Over time, Tactics games -- or just games with turn-based combat -- have adopted a few common interface concepts. Here are a few conventions we're considering for Trudy:

1). Player's team is colour-coded blue, the enemy's red, and NPCs green.

2). Movement ranges reflect team colours, are often represented with filled in tiles.

3). Alternatively, movement ranges are represented via an outline that traces the edges of the movement range.

4). Multiple ranges are used to indicate that a unit can travel further but at a cost, e.g., can't attack, extra resources need to be spent to attack, etc.

Blue/Red/Green team-colouring seems like a no-brainer so we'll probably keep with that convention. We'll also most likely go with outlines instead of filled-in tiles to keep UI real-estate to a minimum. However, a bigger factor for using outlines is our desire to save filled-in tiles as indicators for areas from which a unit can attack.

Tom Clancy's Ghost Recon: Shadow Wars is the only game I know of that did this and it worked rather well:

Granted we won't be defaulting to green tiles but potentially stick to team colours. This, however, brings up another issue --  secondary ranges are often colour-coded yellow:

This always seemed a bit counter intuitive to me as gold highlights are standard indicators for something that's interactive. The association in my head is that yellow == can act, team-colour == can move, but not necessarily do anything else.

We might just flip the convention here -- make move+act outlines gold, and move outlines team-coloured -- or simply go with white outlines like Shadowrun Returns:

I think I have a slight preference for coloured ranges as they're easier to parse, but I'm not sure if our approach would be counter intuitive to XCom players; what do you guys think?
3  Feedback / DevLogs / Re: WARBITS - Classic Turn-Based Strategy on: October 15, 2014, 09:47:04 AM
Nicely polished visuals. The game screen doesn't feel cluttered, but I still appreciate the icon-based minimap.
4  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: October 10, 2014, 06:21:34 AM
Thanks! Hopefully we'll be able to fully realize this world in-game given the usual constraints.
5  Feedback / DevLogs / Re: Trudy's Mechanicals (New Art!) on: October 09, 2014, 12:57:50 PM
New art!

Decorations for the luxurious Aerie. The floating hot-air balloon gondolas are the preferred method of conveyance for the rich.

The ramshackle Warrens, where most of Trudy's populace live and work.

Generator-level sketch for a map in the sewer-like Underworld.

Concepts for an alarm station that summons friendly NPC Constables and a healing station which recharges the HP of all surrounding units.

Initial sketches for a Constable, the default non-Mechanical law enforcement unit of Trudy.

Coloured Constable sketches. The high-tech plasma rifle was replaced with an energy baton to better suit the setting.
6  Feedback / DevLogs / Re: [SRPG] Ars Tactica: Dragon Tournament on: October 09, 2014, 12:22:02 PM
Hype Bar: When attending tournament matches people will be watching and reacting to your teamís performance. We want it to have an effect on the battle. The crowd, depending on their mood, will react differently to the events. Having the guts to attack with a low health unit instead of healing it or delivering an impressive blow to an enemy will make the audience get more hyped or less. Understanding the crowd becomes crucial for your success as they might react by throwing healing items, currency or dangerous objects. The more excited the match gets the crazier the reactions will get, some viewer might even join the battle!

That's actually something we're planning on implementing in our tactics game as well. It worked fairly well in Gladius:


Granted Gladius only provided stat boosts, and it sounds like we're both looking to get the crowd involved via item drops (both positive and negative). Based on the arena layout, we also want to introduce map-modifiers initiated by flow of the battle itself, e.g., a sluice gate opens up drowning the lower reaches of the map.

It's something we've yet to prototype, though, so we'll see whether it'll make sense to have different audiences react differently to combat events.
7  Feedback / DevLogs / Re: Fallow - Trailer + Greenlight! (Gothic Americana) on: October 09, 2014, 10:27:06 AM
Cool vibe and overall aesthetic, voted!
8  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: October 03, 2014, 02:03:37 PM
While on the topic of movement, I'm curious as to what people think about our hybrid approach to ranges.

In most typical tactics games, there is no diagonal movement resulting in a diamond shaped movement area:

Since we have diagonal movement, assigning the same cost to diagonal movement as cardinal movement would create an awkward square shape:

Since we're committed to squares rather than hexes, we wanted a solution that was in-between the two options in order to obtain the most natural feel. If the cost of moving up/down/left/right is '1' point, then moving up-right/down-right/down-left/up-left should cost roughly '1.4' points (the square root of '2'). Since dealing with tiles is a bit more binary (you can walk across '1' tile or '2' tiles, never '1.4' tiles), we multiplied these values by two and rounded 'em up similarly to what old Civilization games used to do. The end result is that cardinal movement costs '2' points, and diagonal movement costs '3' points.

This is how it looks in action:

The algorithm makes for a more natural radius; a circular area projected onto individual tiles. However, there was one reason why we didn't instantly jump on this solution: the ability of units to constantly circle each other using diagonal movement as a shortcut.

This is something of a pet peeve of mine in tactics games. Since many of them implement the idea of different vulnerabilities for a unit's sides (forward, left/right, back), melee units tend to hopscotch around each other in order to attack the most vulnerable spot: the back. This is particularly awkward and tedious when two melee units are isolated but within range of each other, and diagonal movement only makes this easier to accomplish.

The issue can be alleviated with unit-specific abilities, e.g., some units can only attack with at least one tile of space between them and their target, others get a free hit on any adjacent enemies that try to walk away, while others still always turn to the attacking direction, etc. While these all help to limit hopscotching, I was still concerned over the behaviour manifesting itself without a global rule to discourage it.

Our solution was the aforementioned diagonal movement caveat: it's only possible to move diagonally if there's nothing perpendicular to the movement path (i.e., to the left or right of it). This way a unit can't walk around to the back of its enemy in just two steps, but has to take the full four steps route.

A few other rules helped to avoid the issue as well, namely the ability to cause extra damage by shoving the enemy into a wall or off a ledge, and the potential to score a critical hit when attacking from an elevation. Combined with elemental vulnerabilities and unique modifiers, we hope to present various strategic options at each unit's turn that rarely boil down to the obvious "attack the back" choice.

Let us know what you think of our approach!
9  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: October 01, 2014, 12:08:48 PM
Thank you very much; I'll be posting more of our concept art once we get through the current level-related tech stuff.
10  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: October 01, 2014, 11:09:39 AM
Thanks a lot! The name is something of a minor plot point: it refers to the dirigible itself, and how no one seems to remember where the it came from.
11  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: October 01, 2014, 09:38:36 AM
We've got an abstract test level and a unit, so it's time to begin with pathfinding!

There are a lot of things to consider with pathfinding in a 3D game, even a grid-based one. Here's how we're tackling some of the issues:

  • Wanting Trudy to feel kinetic and not like an abstract board game, we're including various movement options such as falling and jumping. However, most tactics games only allow vertical jumping. In Trudy, all units have a "high jump" and "long jump" attribute allowing them to leap across gaps as well. Bauk has a vertical jump of '2' and a horizontal jump of '1'.
  • Vertical inclines of '1' (appear as half a cube tall in the map, about 1/3 of the character's height) are traversed automatically without jumping. The unit's y position interpolate between the bottom of the cube and its top. It still looks a little odd, but will hopefully get polished up and look natural -- we don't want to break up movement with too many jumps.
  • Jumping down is possible if the vertical distance is less than: unit height + unit vertical jump + 2. It's still possible to get pushed off a ledge and fall down a greater height, but this results in damage and a "crumpled" state (unit's movement range is reduced). We thought about providing the freedom to jump down from any summit, but the confusion of getting damaged and suicide-ing units didn't seem worth it.
  • Getting pushed into a pit is instant death for regular units, but hovering/flying units can traverse these gaps.
  • Diagonal movement and jumping is possible, but only on 45% degree angles and if there are no obstacles perpendicular to the movement path. The reason for this limitation is that all units/props are contained within cells, and travelling in between them leads to all sorts of messiness.

The Bauk if a fairly grounded unit so we might have to solve more traversal issues once hovering/flying (and potentially grapple-based) units are added to the mix.

Video of Bauk's map navigation.
12  Feedback / DevLogs / Re: Aeon of Sands: Pyramid (a classic first person Dungeon Crawler) on: October 01, 2014, 08:00:41 AM

Might be a little late for the feedback, but I think the arrow buttons that are meant to go in the bottom-center take a bit too much space (unless you're dealing with a touch-screen device, in which case they might be too small/clumped together). While playing dungeon-crawling CRPGs with mouse support, I always gravitated toward the keyboard for navigation and only used the mouse on the port-view/characters.

Perhaps more space could be dedicated to the minimap? It's a fair amount already, but I always appreciated a generous minimap for helping to orient myself in these kinds of games.
13  Feedback / DevLogs / Re: Dinosword (Kickstarter RIGHT NOW!) on: September 26, 2014, 07:07:10 AM
Just backed it; good luck with the campaign.
14  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: September 25, 2014, 08:06:26 AM
Thanks! We'll be posting updates as the (rather long) feature list for the editor gets implemented.
15  Feedback / DevLogs / Re: Eitr - [ Action RPG ] [ Isometric Pixel-Art ] on: September 25, 2014, 08:05:14 AM
I dig the combat animations. They don't feel effortlessly fluid, but rather have that kinetic chunkiness that helps convey impact (just like the combat in some of the games you mentioned as inspirations).
16  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: September 24, 2014, 01:56:51 PM
Out of all the isometric and/or 3D level editors I've seen, my personal favourite for quick prototyping is Valve's Puzzle Creator in Portal 2.

Granted it's a very specific editor that's tightly coupled with the game itself, but its interface is much more streamlined and intuitive than typical 3D editors. Extruding/recessing surfaces is a very quick way of mapping out geometric 3D spaces, and it's much less finicky than dragging-and-dropping 3D objects and transforming them to make a whole, or carving out spaces from a 3D block.

We're just beginning to make our version of it that's more generic/suitable for Trudy, but I'm very excited about it so far.

Here's some quick info:

  • Uses OpenGL and Java SWT for portability, although this makes it a bit of a processing hog ATM.
  • Grid squares are slightly different tints of grey to help differentiate between them.
  • Ambient occlusion is used to give the terrain depth -- this helps a LOT with visually parsing the topography, although the implementation is too grainy right now.
  • Camera is in and allows for zooming and full rotation.
  • Any surface can be selected from any angle, and multiple surfaces can be selected using Ctrl.
  • Extruding/recessing surfaces is in, as is proper merging (extruding two different surfaces into the same coordainte).
  • Recessing the floor to nothingness creates bottomless pits in the game.
  • Height of blocks is visually smaller than width/length, but it's an arbitrary ratio catered to Trudy's needs.

There are still a lot of features to implement and kinks to iron out, but I'm really happy with how it's progressing so far. Here's a smoother video of the gifs above:

Video of early level editor for Trudy.
17  Feedback / DevLogs / Re: Zodiac - NES styled Platformer on: September 24, 2014, 01:51:19 PM
Cool CRT shot. Are you limiting yourself to the NES palette?
18  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: September 17, 2014, 02:42:02 PM
While rigging Bauk, we started off with the left side of the skeleton so as to easily mirror all the symmetrical parts. Asymmetrical components can be tweaked later on, but this really helps speed up rigging and symmetric animations like walking.

Bauk's skeleton; the left side is mirrored for the most part to complete the structure.

The full rig with all its controllers.

One of our primary concerns with animating Bauk was his shield. The shield can either spin or appear static based on a passive state, which means all his animations would have to be doubled and there'd be some awkwardness if the shield started/stopped spinning mid-way through an animation. To compensate for this we bit the bullet and looked into using locators. We've had a few issues implementing 'em in-engine as they add a substantial amount of complexity, but it would've been an issue for various units whose weapons and tools detach during use.

Video of Bauk and his detached shield.

With the system in place, we tackled a few more animations:

Video of all of Bauk's early animations.

One thing I'd definitely advise keeping in mind is that it's difficult to gauge what the walking/running animation speed should be relative to in-game movement speed. That's something that's bit us before as those animations tend to be the first ones in, but inevitably they result in a "running on a treadmill" (animates too quickly) or ice-skating (animates too slowly) effects.
19  Feedback / DevLogs / Re: moonman on: September 10, 2014, 07:27:37 AM
Love the idea of the different moons and the overall look (regardless of its origins). I just hope the head-ducking makes it in -- it looked quirky and fun, and there's something offbeat and appealing about it. I think it's the fact that it was automated and didn't slow down the player's movement; just an extra adaptive touch touch to environment traversal.
20  Feedback / DevLogs / Re: Dinosword on: September 10, 2014, 07:16:55 AM

I love the fact that his teeth remain visible along with the eyes when the area gets dark.
Pages: [1] 2 3 4
Theme orange-lt created by panic