Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - requerent

Pages: 1 ... 4 5 [6] 7 8 ... 24
76
Most games, if not all, are a simulated function of time. Turns are NOT the unit of time that a turn-based game is working with. A 'turn' is simply whenever an entity gets to perform an action. Most TB games use 'ticks' as their unit of time and a turn has a tick-cost associated with it. A player will experience time relative to how frequently s/he gets to make decision, but your game will simulate in ticks.

From a player's point of view, an enemy may move two spaces per turn. But in reality, the tick-cost for moving is simply half that of the player. The enemy's cost to move may be 50, whereas the player's may be 100-- but the game updates relative to ticks, not the player's idea of what a turn is. In this sense, your game is updating everything every single tick.

Now-- we need a system that manages who gets to take a turn. However you do it, you'll simply be waiting however many ticks before an entity gets to act, based on their action, make them wait however many ticks again. Ticks give us a lot more flexibility than basing our game on turns, but it isn't wrong to do the latter.

You avoid phantom collisions by updating the entire game every time an action is made. That way we'll know that the space is occupied before making a decision.

77
Programming / Re: Problems and Pitfalls of Deterministic Combat
« on: June 01, 2013, 06:19:17 AM »
1)

Firstly, 1-HP roguelikes can have combat systems. They can also be more complicated. Just because there is only 1-HP doesn't mean that there isn't a complex system in place. The sequence of moves and the situation in which a loss occurs isn't necessarily any different. 1-HP is more about how the feedback cycles work. For both styles, it's all about the sequence of salient decisions a player makes that result in victory or defeat. Losing HP as a form of mistake forgiveness hinders your ability to progress. In 1-HP, we can hinder the player in other ways- such as forcing the use of consumables or by putting them in a disadvantageous position relative, to, say, other enemies.

Secondly, check out Brogue. It has very straightforward and transparent 'bump combat' mechanics. The game tells you your odds (by looking at an enemy) and indicates to you how much damage you deal. The value here is that you're essentially given a range of risk to deal with. So long as you're always accounting for the bottom-line, you won't lose (but the price for winning isn't always consistent), however, you can roll the dice if you need to bet your luck against something.

https://sites.google.com/site/broguegame/

2)

Arbitrary timing systems are bad. Brogue is a good example of a timing system that is mostly not arbitrary. I advocate a powers of 2 system, whereby all time-costs are relative to each other. That way actions never get out of sync. The simplest example of the advantage here is that an enemy with an attack delay of 100 vs you with an attack delay of 150 will never appear to be getting a free 'hit' every other turn. This is bad because the player isn't always aware of when that 'extra' turn is going to be taken by the enemy.

3)

Like you say-- attack locks with lock-picking skill. That way success is a function of time. Now you just need to make time meaningful. Brogue, again, does this via nutrition. There is a finite amount of food produced in the dungeon. If you dawdle too long you die.

Alternatively- introduce consumables that provide a risk-reward scenario. Also, don't guarantee that things behind the door are necessarily good.


4)
Arbitrary scaling is something that I personally look down upon. As a property of your mechanics, why do you even need +5 gear to be in the game? Why not add new options, abilities, decisions for the player to make? You can also invert the meaningfulness of gear-- Plate Armor might be great against dragons but terrible against rats. Turn the game into a cost-benefit analysis instead of binary jumps in improvement. Emphasize decision-making instead of gear, stats or XP.

5)
Again, check out Brogue. Each weapon fulfills a different use-case or provides flavor/variety/novelty, however they are not distinct enough to warrant carrying around many different weapons. IE. A War Hammer attacks twice as slow but deals double damage. The sneak attack in brogue deals 3x damage. The opportunity cost of more tactical decisions is sometimes worth the clumped damage. We can make this even more meaningful by introducing other abilities that may converge in a meaningful way with our equipment.

Synergy, Opportunity Cost, and Options are what make things interesting.

6)
For every discrete challenge, the breadth and depth of potential solutions within the player's decision-tree more or less describes both how much of a puzzle the game is and how difficult it is. Whether it feels like a puzzle or not is a combination of novelty and the degree of information provided to the player. One 'solution' to the problem of feeling too puzzling is to make it so that puzzle solutions are 'ideal' but not necessary. Effectively using traps to defeat certain enemies or taking advantage of the map might speed things up, but not give the player more advantages apart from time and style points.

If a player doesn't have enough information to precisely calculate what the result of his actions are, then it won't feel deterministic. Also-- AI is another point of concern. AI can make erratic decisions if you design it that way. This will automatically make a game non-deterministic even if the combat system is.


Brogue is a game in which losing is entirely your fault. The dice-rolling under the hood is more of a way to buffer the difficulty in a forgiving way more-so than a punishing one. In this way-- losing IS deterministic, but winning isn't necessarily deterministic. That said-- Brogue is quite difficult.

78
Oh.... Heh.... Some of my previous advice may not be entirely correct. Excuse me-- You don't loop through each system per entity for a turn-based game, you only allow one entity to take an action per looping of each system.

The system that determines which action, if any, that an entity takes (inclusive of the player and AIs), will reschedule that entity's next opportunity to take action within a priority queue (the priority being the speed-cost of the action taken). Otherwise, the game updates somewhat like a real-time game. There are plenty of solutions here, but a priority queue is elegant. You just want to make sure you only get one entity's action per turn.

There are a couple of ways to approach turn-based physics. You can have everyone pick actions synchronously and simulate, but this can make it very difficult for a player to understand what is going on. I think it's best to have a single entity perform an action per game update.

This doesn't really cause problems for realistic physics so long as you have a little foresight. You can use 'idle' states and 'moving' states to indicate that an entity moved last turn or stayed in the same position. That way, if two enemies are charging at one another, you can resolve it in a way that is consistent with their actions. Alternatively, you can store a velocity or force on an entity to be used when evaluating collisions, you just clear it out the next time the entity moves.

Your entities should be making decisions in relation to the state of the game- inclusive of the positions of other entities. In this sense, you probably want to keep a map of entities/properties cached. This should make detecting hits trivial.

Note, a Map IS also an entity that stores the relative locations of other entities. When they move, the state of the Map is also updated.

79
Programming / Re: Brilliant Observations by My Brother
« on: May 30, 2013, 05:58:19 PM »
Quote
When I first started getting into game design and roguelikes in general the venerable KRICE told me that it would change the way I saw games. It would impact my ability to just enjoy a game with out being critical of it's design. Without wanting to 'fix it' or comment on it.

He was right. I've lost the ability to just enjoy the wiz bang of a AAA game.

The same thing happens for books, films, screenplays, and lots of other junk. But the truth of the matter is-- it provides a whole new level of appreciation. For the design, all of the work and sweat becomes visible. AAA titles become a marvelous engagement in an extremely complex development pipeline. Mo-Cap and normal maps and different lighting effects and shaders and ... it's just sooooooo much more beautiful when you know what you're looking at!

In games, and even more-so in films, it's common to see an 'orange and teal' color scheme. Once you study lighting and composition, you don't even have to pay attention to scenes-- you can read exactly what the film is trying to accomplish by the color schemes used. Watch the Star Trek movie with 'orange and teal,' in mind. It's basically the entire film.

80
It just depends on how you feel comfortable organizing your data. Just do what makes sense man. You should avoid iterating through components for each entity though- that's just a lot of wasted looping/checks.

Local references of parallel arrays is one way, unique keys for component-types is another, and I'm sure there are some other clever ways to do it. Looping through every component for every entity for every system, however, isn't a good idea.

An optimization like this, however, can be accomplished later. Make a game first with what makes sense, then you can speed things up in whatever way makes sense for your application.

81
Programming / Re: Top 10 tips in Game Design
« on: May 25, 2013, 11:02:12 PM »
Like, if you make a game that can't be understood on at least a fundamental level within 10 minutes, you'll probably lose a lot of players.

Three words: Dwarf Fortress.

In all fairness, I was going to mention DF also...

82
So does the System store copies of the components itself or just take references (IDs) to the entities and look them up in the entity database and work on what's in there, or something else?

Do whatever makes sense to you.


I think having a local array of references that use the entity ID makes the most sense to me. However, there isn't always a 'right' way to manage your data. Do what makes sense to you.

83
Programming / Re: More Free Tiles!
« on: May 13, 2013, 05:30:34 AM »
8x8 is fine, and you definitely want to blow them up by 2x anyway unless you want my eyes to bleed.

I have a criticism though. The enviro sprites are sufficiently darkish, so you want the character sprites to be brightish. It sets them off, contrast and all of that. You see how the flowers and barrels pop?

A minor thing, and it could be my monitor.

Sometimes that's something you want to do as a post-process. Leave it to developer discretion what gets highlighted.

84
Programming / Re: Physics Engine Implementation in Roguelikes
« on: May 13, 2013, 01:07:11 AM »
You can do Newtonian physics just fine in a grid based game, you'll just be using discrete units of measure based upon a space-time relative to the grid. Which can be rationalized roughly as the space it takes to comfortably occupy a single 'person' and the time it takes for said person to 'move at a brisk pace' between two tiles. As units of measure, we don't need to know what the actual values are, just that they are logical placeholders that serve as an abstraction layer over Newtonian physics.


Your smallest units of measure are 1 tile and 1 tile per turn, so base everything around this, including mass and acceleration.

Decide on whether you want to be fully physical or just use physics for certain effects. In a fully physical game, you need to ensure that an entity is always capable of moving 1 tile's worth based on it's physics-relevant statistics. This is important because you'll need to use it when calculating whether or not you can push into another object's tile.

You're going to probably want to use a state-machine to manage the physical states of agents. Don't use 3D physics, just use abstractions to represent traction. In most cases, if an entity is balanced, then it's forces will be cleared at the beginning of its turn. If not, they should spend their turn recovering balance. Traction should play a role here- for example, if an object waits, you can increase their traction, making it more difficult for them to be moved by other forces. If they're off-balance or in the air/falling, then traction should play no role in whether they recover or not. You'll need different rules for Flying or Floating enemies. An enemy that gets knocked-down might take a hit to their AC, while an enemy that's off-balanced may not be able to move/take action, but wouldn't suffer a penalty doing so.

Use your line-drawing algorithm and rectangles (two xy coords) to represent direction vectors. You'll need this for force calculations that make sense in grids.

Thanks! That all seems to make sense. Could you elaborate on how an solid state machine should best be implemented? I admit I'm not too familiar with them.

A Finite State Machine is just a way of representing different states that an object may be in. You don't actually need any specialist infrastructure to implement them, it's more of a conceptual thing. You may have different states for things like: dead, dying, falling, flying, walking, standing, charging, etc. These states can be implemented as flags or Booleans whereby the functionality of some methods/functions/processes is altered based upon the state. There is no formal way to manage states. Different states are treated in different ways and have different properties, but all represent the same object.

So- for example, we might want an enumerated type to describe the physics states. And then if-statements to modify calculations based upon whatever active physics state that object is in. State Machines are 99% of the time always a smart thing to implement for every game. Let's say the player character fails a traction check against some force applied to him. We just change the physics state and the next time an opponent attacks the player, we use data/values/algorithms relative to that particular state. Say the player gets knocked on the ground- we can change his physics state to 'prone,' which might put him out of LOS for some enemies and easier to hit for nearby enemies.

85
Programming / Re: Physics Engine Implementation in Roguelikes
« on: May 12, 2013, 08:17:56 PM »
You can do Newtonian physics just fine in a grid based game, you'll just be using discrete units of measure based upon a space-time relative to the grid. Which can be rationalized roughly as the space it takes to comfortably occupy a single 'person' and the time it takes for said person to 'move at a brisk pace' between two tiles. As units of measure, we don't need to know what the actual values are, just that they are logical placeholders that serve as an abstraction layer over Newtonian physics.


Your smallest units of measure are 1 tile and 1 tile per turn, so base everything around this, including mass and acceleration.

Decide on whether you want to be fully physical or just use physics for certain effects. In a fully physical game, you need to ensure that an entity is always capable of moving 1 tile's worth based on it's physics-relevant statistics. This is important because you'll need to use it when calculating whether or not you can push into another object's tile.

You're going to probably want to use a state-machine to manage the physical states of agents. Don't use 3D physics, just use abstractions to represent traction. In most cases, if an entity is balanced, then it's forces will be cleared at the beginning of its turn. If not, they should spend their turn recovering balance. Traction should play a role here- for example, if an object waits, you can increase their traction, making it more difficult for them to be moved by other forces. If they're off-balance or in the air/falling, then traction should play no role in whether they recover or not. You'll need different rules for Flying or Floating enemies. An enemy that gets knocked-down might take a hit to their AC, while an enemy that's off-balanced may not be able to move/take action, but wouldn't suffer a penalty doing so.

Use your line-drawing algorithm and rectangles (two xy coords) to represent direction vectors. You'll need this for force calculations that make sense in grids.

86
Programming / Re: Comic Action Ideas
« on: May 10, 2013, 03:39:21 AM »
Ah... Hmm...

I was designing a 1-dimensional roguelike based primarily on combinatorial challenges. That is, using different abilities in different orders or in tandem to progress. The game revolves around building procedurally generated abilities through different schema and rules generation- but it's ultimately too complex both to make or to play.

Something like what you're talking about is what really pushes the emergence idea altogether... and really should be the basis of any game that wishes to capture (or should we say liberate?) that idea.

87
err- sorry, the formatting messed up somehow.

Code: [Select]
Make the Z component of your map come first. So that you have a bunch of 2d arrays with respect to a Z-component Array.


In other words, your map is of the form Map[z][x][y].

Now, when you want to draw something, you simply pass Map[z] into your grid-drawing function. The grid-drawing function expects a 2d array of x and y coordinates- Map[z] is a 2d array, whereas Map is a 3d array. Get it?

Edited with tags >_<.

88
Do the map as a Map[z]
  • [y], and pass the Map[z] into the drawgrid thingy. I haven't used libtcod but I imagine that's the sort of pseudo-code you need.

89
You need to make a distinction between the player's view and the game's map. This wouldn't be much different from a logically 2D game.

All you do is use a 3D array
  • [y][z] and store whatever z-value the player is currently viewing from. This is no different from a normal game, where the view target of your proverbial camera can be described as the coordinate from which the viewing area is drawn.


In a fixed view roguelike, such as Brogue, the 'camera' is always pointing at the center of the viewing area, whereas in ToME, which follows the character (to some degree anyways) points at the character.

It can be useful to make the camera it's own entity so that you have the freedom to move it around with a 'look' command or what not- especially for a 3D roguelike.

90
Logically 3D (dwarf fortress) or Graphically 3D (Diablo 3)?

Pages: 1 ... 4 5 [6] 7 8 ... 24