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 ... 21 22 [23] 24
Programming / Re: Java RL tutorial!
« on: March 11, 2012, 10:54:42 PM »
Its really boring; thats just another tutorial like any c ones, isn't it?

I would say that Java and C/C++ are quite different languages, though the first few chapters don't really emphasize that.

Java prevents you from needing to do as much work >_>.

Programming / Re: Java RL tutorial!
« on: March 10, 2012, 12:46:06 AM »
Many newbies go for IDEs like eclipse. These are tools intended for experienced developers, and their features are intended to automate frequent or annoying tasks, not to remove the necessity of knowing how to do them on your own.

Code completion, context hints and dynamic syntax checking are GREAT for new programmers or anyone using an unfamiliar library.

For the second tutorial- just a quick recommendation-- You've got a bunch of independent if statements. They really should be a switch, or at least a bunch of if-else statements- otherwise you're making a lot of wasted comparisons.

I'm not directly familiar with the CharKey constants, but here's the gist

Code: [Select]
case CharKey.UARROW: if(--y < 0)y++; break;
case CharKey.DARROW: if(++y > 24)y--; break;
case CharKey.LARROW: if(--x < 0)x++; break;
case CharKey.RARROW: if(++x > 79)x--; break;
case CharKey.Q: stop = true; break;

In this case, you always have O(C) comparisons where C = 2, whereas otherwise you have O(N) comparisons- where N is the total possible number of input keys. It's so insignificant, but stuff like this is good to learn when the concepts are still simple and can make a big difference later in generation time when doing world-generation and historical simulations.

edit: stumbled across the proper keywords.

Do you plan on facilitating someway to acquire new party members?

Other Announcements / Re: Share your ideas for 7DRL
« on: March 08, 2012, 12:37:49 PM »
I plan to keep the general (a bit minimalistic and DROD-like) style of gameplay, though. I feel that the usual mechanics of stats, hitpoints, heal-by-rest, accuracy and dodging, armor, and so on are overused, boring, and don't bring much to the game.

What is DROD?

I've come to a similar conclusion myself lately about stats, dodging etc.  Deterministic systems should be the norm in games with permadeath.  Failute should always be from your own mistakes, not the whims of the RNG.  Dice rolls are an inheritance of table top gaming, where there was a specific tension to picking up the dice and rolling them hoping for a specific number.  When a computer does it and you never ever see the calculation then it just feels arbitrary and unfair.  Not fun at all.

Equipment and items are also boring as they take away from the fun of interactive gameplay.  You should spend your time making tactical decisions, not fiddling about in menus.

Anyway, my 7DRL 'Rogue Rage' has nothing to do with economy, and I'm sure as heck not changing my design now  :P  If you want to know all the gritty details I've got them in a spreadsheet (take note of the different tabs):

As a simple overview, it's a melee combat game that encourages fighting against groups.  You attack enemies just by standing next to them, with bump-to-hit triggering special attacks.  The exact effects depend upon your stance, and you switch between these freely.  There is no character progression between learning new stances.  You have a Rage meter that increases in battle, and when it hits 100 you get quite immense power for a short amount of time.  Outside of Rage you're much weaker.

I'm hoping it'll be quite fun.  I don't think I've made a game yet where many people have actually found the gameplay fun, though I've been praised for other things.

I am going to have to disagree with you on some of these points.
1. Equipment, if done wrong, can take away from the game, as you fiddle about in menus.  But if done right, equipment actually presents tactical decisions.  Such as whether it is better to wear item x or y, which items to have in inventory (with encumbrance or limited slots), which items to improve (such as with Brogue)...
2. I disagree that deterministic systems should necessarily be the norm in games with permadeath.  Its more of a question of how you want the game to feel.   Random rolling, if done right, adds tension and excitement, as gameplay contains an element of luck.  There is the issue of having deaths seem "unfair", but if the game is designed right, these instances don't happen often.  Determinism gives it a "chess-like" feel.

The healthy combination is to have a deterministic system with some form of fog of war. Card games that involve teams and the entire deck are a good example. All cards are known and known to be out, but their locations are hidden. Despite this degree of randomness, winning and losing depends very little on it (depending on the game of course- the skill fact in each of these games can be explicitly measured).

Programming / Re: Procedural generation of quests and narratives
« on: March 08, 2012, 06:23:15 AM »
I typically prefer it in conversation when the person with which I'm sharing an idea with refutes it with constructive criticism, thereby allowing a conversation to organically emerge that in itself becomes the solution to whatever problem the idea was meant to address.

With that in mind, I'm going to stand opposite to the idea presented.

As I envision it, the system starts with some ultimate goal, derived from some suitable plot archetype -- Defeat the Evil Menace, Rescue the Princess, Free Our People, Lift the Curse, Find the Maguffin, etc.  As with any good Ultimate Goal, it is of crucial importance but somehow indefinitely deferrable -- there can always be more impediments and side quests thrown in the way of success.  So, we start from that ultimate goal and work backwards, determining what complications exist and setting up subgoals for them.  Each subgoal can involve just as much complexity as the original goal, so in this way we can build up complex structures of interdependent subquests.

A teleologically generated game world will emerge with a cohesive and unique narrative, but there are some problems.

Firstly- that the world is teleological. That is, the sub-quests, world, and everything, from the player's perspective, either has something to do with this ultimate goal or not. Even if there is some explicitly and implicitly generated game flavor, the player will always be trying to factor that into the teleology.

Secondly- It won't be character driven. It may feel like that the first playthrough- but with further iterations a 'this is the storyline' pattern will become obvious.

Thirdly- unrelated sub-quests and inane sub-quests become impediments to the goal. They are 'things that must be done' to get to the next chapter. There also tends to be a clear indication of failure and its effect on the the ultimate goal for any given sub-quest. This indirectly promotes save-scumming (if you could save).

Fourthly- Failures are clearly failures and do not impact the progression of the narrative in an interesting way. That is, when we fail- we lost the opportunity to acquire or gain some advantage, but

If your objective is DF depth without the bloat and both a more interesting narrative and a tangible story, then an ultimate goal may not be what you want. It's something that I've been thinking about, but I don't yet have a solid paradigm with which to rationalize a solution- however, here are some of my thoughts on it. They aren't very well collected, but hopefully I can impart the spirit of my idea.

We can procedurally generate a relationship tree by partially generating the properties of entities as they are encountered, and satisfying them later via a dependency queue.

For example- When we generate a monster, do we (as a developer) care what its family is? No. The family hasn't been generated- the monster's origins are unknown, but it must have some personal story of significance.

Typically- the player just assumes that the monster is there to feed us XP in the pursuit of the ultimate goal. But what if we generate the monster with unsatisfied dependencies- such as parents yet to be generated.

We ciykd then put those parents into a dependency queue and generate them in some other room further down the line. We can do this with racial types, racial variance, factions, and essentially everything. This includes flora and fauna, diet, vulnerabilities (pink mushrooms are poisonous to this species- emergent poison making abuse?! I think so- maybe the smoke from burning also blinds them), and be adjusted to include as much depth as desired. Coupled with some good ol' abstractions and maybe throw in some tautologies and you could potentially generate the rules of the game along with the game itself.

So, say we kill Monster A. Further down the line, we run into parent of Monster A, whom we kill. Then we run into Clansmen of the parent of Monster A, whom we kill. And all of a sudden the clan is out to get us. We could then hide in a town where that particular clan is very unpopular. The townspeople see that the Clan is more threatening than usual so the mayor attempts to recruit adventurers. Our hero joins the cause, ensures he is the only survivor of the defense, and becomes the de facto military ruler of the town.

Our world is deterministic and our character's identity emerges from how we play them.

Brogue generates key puzzles so that the the solution and the problem are all on the same level. But what if we generated a problem whose solution shows up later- IE, finding a locked box. We pick the box up and take it with us, but we need a key. The generator may happen to randomly generate a town in the room in which the key is also generated-- it might be generated into the inventory of a a person.

If we have a tree of dependencies satisfied as we explore while creating new unsatisfied dependencies, we don't have to wait for a complete DF-style world to generate to get an even more dynamic range of results.

Programming / Re: starting a new rl as my graduation project
« on: March 07, 2012, 05:21:57 AM »
You could also go with Java and make it a webstart app. Java's suite of data structures would be great support for AI.

Programming / Re: Designing Difficulty
« on: March 05, 2012, 10:15:17 PM »
Chess is always the best comparison in my mind.  You know the immediate result of your move, and you can guess how your opponent will react, and so you can plan ahead a few turns.  But it's not fully predictable and your tactics have to change and evolve as you play.  The game rewards thought, and because it keeps changing you have to think every turn.  It is never ever boring.

I'm in the camp that doesn't think of Chess as a 'game,' but more as a competitive puzzle.

The problem with chess is that it has no fog of war and the initial board state is always the same. It is not predictable what an opponent may or may not do, but both players can be aware of ALL possible outcomes of any given move.

Chess is then a battle between who has more of the game state tree of chess memorized. If that doesn't determine a winner, it is a battle of objectifiable (word choice? >_>) heuristics. If that doesn't determine the winner, then it's who is more familiar with whatever sub-tree of board states of chess we are in. IFF that doesn't determine the winner, we will finally have a game that is interesting.

Why do I dislike all of that? Because it has the potential to become-->

Too much predictability and it becomes a set puzzle, which is boring since you solve it at the start and then just go through the steps.

The other thing we're getting at here is accessibility. A player's skill rating is more dependent upon memorization than on one's ability to utilize the rules. Because Chess is a solvable game, it would eventually become a set puzzle. A low-ranked player has virtually no chance against a high-ranked player due to a difference in the number of early moves memorized. If those early moves didn't matter, then it would become a contest of who utilizes the rules of chess in the most interesting way.

A simple exercise to change things up is to allow players to place pieces on the board within the first two ranks in turns. If white places a piece first, then black has a slight advantage in initial board state, while white has an advantage in tempo. The change in starting conditions mean that memorization won't favor one player or the other. Intelligent building of the opening board state and clever utilization of the rules would play a larger role. After all the pieces are placed, the game is still completely calculable- we just cut out memorization as a factor in skill. Of course- there are obviously 'good' and 'bad' initial states and these may not matter much what the other player is doing, so memorization can still play a huge role if this style of chess is something that a player practices regularly.

An interesting game to look at, in terms of initial state and fog of war, is this little Italian card game called Scopone (Specifically the variation Scientific Scopone).

The gameplay is simple-
--40 card italian deck, each player is dealt 10 cards.
--Right of dealer plays first.
--Each turn a player MUST play a card (10 rounds per hand).
--If there exists a card or group of cards on the table that add up to the exact value of the card played, those cards and the one played are captured by the player's team. If multiple sets of cards exist, the fewest number of cards must be taken (player's choice on a tie).
--If a player plays a card and captures all the cards on the table, it's a 'scopa' (pronounce it loudly and proudly!) or 'sweep'- unless it is the last round of cards played.
--When there are no longer any cards in hand, the last person to capture is awarded all of the remaining cards on the table.

Points are calculated at the end of each hand. One point is awarded for each of the following:
--Most Cards (unless there is a tie)
--Most Golds (unless there is a tie- 'gold coins' is a suit)
--Highest Primes (generally who has most sevens)
--Gold Seven
--For each Scopa

The first team to reach 11 points wins. Points are only calculated at the end of a game and at the same time- therefore, it's possible to tie. If there is a tie, continue playing until the difference in score is 2.

Table talking is absolutely allowed- There are even specific italian words that players are encouraged to use to tell their partners what they want them to do. The only restriction is that a player is not allowed to announce a card in their hand.

What makes this game awesome? All of the cards are accounted for AND there are a variety of objectives for each hand. The rules are very simple and strategy gets very interesting.

If there is a 4 and a 5 on the board and I don't have a rider (9), I might play a 3 or a 2. My opponent, who has a 7, will want to win a prime, taking the 4+3 or 5+2 (pending on what I played) with his 7, leaving behind a 4 or a 5 for my partner which could result in a scopa for my team. The opponent knows that this is risky, but if he does something else there may still be a combination of 7 on the board passed to my partner- who might also have a 7. Say the board is 4,3,5- he might play a 2 instead of a seven. If my partner plays a 7, he leaves a 7 exposed to the other opponent who could take it as a scopa. Lots of things have to be considered.

Similarly- If one player of team A knows that the next player of team B has a 7, but that the other player of team A does, he can literally pass a 7 to his partner. The only way to prevent this from happening is for the other player of team B to ensure that an ace, two or three is on the board so that their partner can catch that 7 with a royal (face card)- that, however, could then expose a scopa with the remaining card. If card passing does succeed, it can oftentimes result in a scopa for the other team.

Say there is a 2 and 3 on the board and something else. You play an ace and your opponent has a 6. If two to three of these four cards are gold, a player will consider taking the risk of exposing a scopa to your partner. If they don't, however, they're going to pass a bunch of gold to your partner. Same sort of situation as the above two examples.

Being aware of how players pass on opportunities gives us hints as to what they have and don't have- but a player is just as likely to intentionally not play something to prevent the chance of a Scopa happening or to dupe you. With tabletalk as a component, both the rules and social component create a very fun and interesting game. You end up playing and thinking about the game in some really complex ways.

When a team is pressed into a position where they can't make a strategic action it's called a 'whirlwind' (because one team is taking cards when the other can't). A 'whirlwind' of scopas is the ideal progress of a game for one team (typically lots of taunting will result: "And it's become a whirlwiiiiiinnnd"- "is it breezy in here? Oh oh... look what just happened again"), but the game is very interesting because it's not difficult to come back from a losing position because there are so few points awarded. It's possible for the game to end in 2 hands, therefore dealer dis/advantage (though there isn't really any) is balanced by the way scoring is handled and by how many points you need to win. After all, each game both teams can get the same number of points in different ways. You have to play both to pursue objects and deny your opponents.

You can play it as a heads-up game also- just deal the second set of 20 cards after the first has been used up. The first hand is a lot of probing strategies, while the second one ends up dealing with card-counting and tricking your opponent.

The scientific variation causes the game to start as a whirlwind, which many players find frustrating (though IMO a better game)-- traditional rules have 9 cards to each player and 4 starting on the table.

If you have a friend or group of friends interested in alternative games, I highly highly recommend it-

Games are fast and a lot of fun. The regular version of two-player Scopa is in itself a great game. I find it to be much more strategic than Bridge or any other trick taking game.

Programming / Re: JVM vs something else
« on: March 05, 2012, 12:39:06 AM »
I knew of Runescape and Minecraft, but even though I had played Spiral Knights, I had no idea it ran on the JVM.  It's surprisingly fast.  Thanks for the lists  :)

Graphics for most of these games use JNI bindings of OpenGL. In other words, if you care about graphics, Java shouldn't be a hindrance in any way.

Programming / Re: JVM vs something else
« on: March 04, 2012, 11:23:21 PM »
There are enough excellent commercial Java games to serve as a counter-example. There's also a lot of misinformation.

Do you have any examples of commercial Java games? I've always been interested in the language.

Spiral Knights, Minecraft, Runescape- several others. Every Flash game (the VM used by Flash is just a smaller and less effective JVM for RIA).

Some lists- Google will reveal more.,3123.0

The JVM is interesting because it provides runtime optimizations. It caches stuff that is performed repetitively, allowing it to increase the speed at which it solves similar problems.

Traditional Roguelikes (Turn Based) / Re: Hydra Slayer version 13.0
« on: March 04, 2012, 02:26:58 AM »
Not very far...

I have experienced a few of the AOE/beam weapons and like them- I was just reminded of the calc ability from FFT, and how it seems somehow very appropriate for a game like Hydra Slayer. The calc ability from FFT does things like, 'Hit every 5 squares.' I wouldn't recommend that sort of all encompassing pattern for HS, but a 'spell' type of attack could have a randomly generated or not-explicitly logical set of squares it effects in a designated radius around the user in a variety of ways.

Consider the following-
Code: [Select]

edit: Code didn't preserve spacing... but you get the idea.

A weapon that only effects the squares above when activated/thrown. It could seem somewhat pointless- but the player may be able to take advantage of board manipulation and mushroom pots to create situations where they're able to use these sort of abilities extremely effective.

To make it more interesting, consider alternative effects and mixed elements. Within a 5x5 area around the player, each square might be affected by a different element. It could add some depth in regards to managing groups of enemies or treating multiple enemies as a single enemy.

Are there ways to split a hydra in two? That could also be interesting.

Traditional Roguelikes (Turn Based) / Re: Hydra Slayer version 13.0
« on: March 03, 2012, 11:56:13 PM »
Hola! I love Hydra Slayer and had just a couple of thoughts for features that might be interesting to think about.

The 'board' plays a variable role in gameplay. Sometimes it's important, sometimes it isn't. It might be interesting to include missile-like weapons (spells?) that strike in a pattern on the board, but require that each space it strikes must be occupied. Or something along those lines.

Another thing that may be interesting is to begin the game with only a few elements to consider and procedurally generate more elements with new relationships. Potions of knowledge may be necessary to learn about the properties of new elements.

Also, a weapon type that auto-transmutes itself on hit could be interesting so long as it was predictable.

Programming / Re: Simultaneous turns?
« on: March 03, 2012, 11:28:16 PM »
Simultaneous turn-taking and synchronous turns could be managed by making actions consume units of discrete time across multiple states.

For example, in a fighting game, each attack typically has 3 states. Draw, strike, and recover. Each takes a certain amount of time. While we're recovering or drawing we're exposed to a strike. If a strike hits a block then the opponent has to go through a certain amount of recovery (should typically be less than the attacker's, but that just depends).

We don't care about things like initiative or action order, because everyone just makes an action whenever their last action finishes (maybe previous action plays a role in what actions are available next, like in a combo- or there are opportunities to feign at specific points while an action is active- at the end of the draw step, bu we only need to stop action when the player could make a new action). Of course, tie-avoidance depends upon how discrete our units of time are- but for the sake of a turn-based game, we just automatically interpolate until a new action could take place.

Okay- I don't want to rewrite anything I just wrote, but there is absolutely no need to use discrete units of time. We can just jump to the next opportunity to make an action and 'pause' the game until the player makes a decision... nothing about this requires units of time. We just have a priority-queue where action states are placed based upon their duration- some states may effect later states and prompt for a new action (such as being interrupted). That's pretty simple to implement and should give you simultaneous turns-- that is, if you want to incorporate time in that way. It's an untraditional way to make a roguelike.

Programming / Re: JVM vs something else
« on: March 03, 2012, 11:06:19 PM »
I have never seen a single Java program that was running really smooth, no matter whether it was 3D or 2D. And it's not only the amount of memory used (C++ programs use a lot of memory as well), Java is just slow. However, if you don't have much C++ experience and you care about portability, Java is still a good choice.

There are enough excellent commercial Java games to serve as a counter-example. There's also a lot of misinformation.
- is kind of interesting.

Programming / Re: Designing Difficulty
« on: March 03, 2012, 10:27:32 PM »
The formal representation of solvability may include only unique and salient game states. Salience, however, is subject to design, so the model is as useful as it can be implemented.

I think these two are in fact related, since salient decisions would be those which can be taken (or maybe considered) by players making intelligent decisions. Otherwise any complex game would have a very low and irrelevant solvability (as my chess example shows).

Hmm... It doesn't have to do with player intelligence because the solvability is generated into the challenge. The player's actual intelligence is not factored into generation (though I don't think this is what you're saying). We don't care what actions the player is making or will make, we just want to be certain that there exists a desirable amount of decision paths that the player can take to solve the challenge. Moves of a low heuristic (dumb moves) value are not salient because we assume they are failed paths. The player's decisions don't really have anything to do with quantifying how solvability effects the challenge. Solvability should try to include some unintelligent decisions after all.

Now, if we are using heuristic pruning of some kind to simplify the problem of solvability, then we need a measure of what moves are important and what moves are not. I'm not sure if this is the player's intelligence- the player doesn't have anything to do with how the challenge is generated.

Also, I think some way of probabilistic calculation makes more sense than simply counting the paths. Otherwise you would have to calculate paths which occur in very rare situations on the same level as paths which occur frequently. This also automatically prunes meaningless decisions (like my fire/ice example).

I think I've been wrong in thinking about solvability as a tree (which could work). It should be a directed graph.

If that were the case, we could generate solutions as salient actions from the goal state with some branching factors and desired depth until we decide to converge on the initial state. If this is the case, we can explicitly generate the paths with only salient events. Any divergence from these paths may or may not result in failure (which is a problem). The greater the branching factor from the goal state on, the more solvable it is. That is- solvability describes the breadth of solutions. Complexity, then, is how many required steps from the goal state to the initial state there are- or the depth and variety of actions. Excuse the redundancy, I'm still thinking this through.

Hmm-- Suppose a Hydra is generated that the player can't solve with current equipment. We could also generate a single weapon that makes the hydra solvable in some amount of steps... or a whole slew of weapons and items that all need to be used within a particular order to solve the Hydra. Even a two-headed hydra can be turned into an incredibly complex problem pending on what weapons and tools are available. Runes can be used to auto-solve these problems or jump between salient events, but if we were to exclude them when deciding which hydras and weapons to generate, we can generate challenges whose difficulty is very measurable.

Combining the two, we get that solvabilty would be the probability that a player wins the game (except that now this is no longer a perfect player, simply an intelligent one).

I'm reluctant to use probability to describe whether or not a player wins a game, but I think we can set the probability based upon how we address solvability. If we're analyzing a game's solvability... then yes, the digested information we get is the probability. It's probably more important to look at distinct challenges, though, instead of the entire game.

This would actually make the game more complex, because we aren't considering highly equivalent actions as a contributing factor to variance when it comes to content generation. If we're in the land of 'Fire and Ice does the same thing,' we don't want to think of them as separate actions when generating complexity. This is just a side-benefit to applying salience.

But we should also apply this to your previous example that there are many paths when killing goblins, but not so many when killing dragons.

I think it still works out- if salience only cares about the highest heuristic valued moves, goblins will be more solvable because more of those moves are likely to have solution paths than in the case with the Dragon- unless, of course, that's not how the game is designed.


Calculate all possible board states and decision paths of chess, what is the ratio between Win and loss or draw? We obviously can't do that- but we're not trying to.

It should be possible to calculate this in very simple situations (like king vs king + 2 rooks and some simplifications of the draw rules).

Yea- I just mean we can't generate the entire game state tree of chess. It's one of those end of the universe problems. Of course, solvability as a model might hypothetically care about all of that, we just have to implement it in a salient way for it to matter. For really good players, chess doesn't really begin until after the 20th move or so- both players have the same amount of knowledge of the game from the initial state, they can silently agree on how the game will progress (because the best first 20 moves or so has more or less been solved). I kind of hate chess for that. Knowledge becomes more important than a person's ability to solve problems.

I'm really just trying to rationalize the most complete and useful way to regulate difficulty in a game so that it remains meaningful and challenging. Solvability and complexity, and their sub-properties, in terms of some organization of actions seems to be close- but there are a lot of gaps that need to be worked out.

Programming / Re: Designing Difficulty
« on: March 03, 2012, 10:10:17 PM »
That settles the matter. I assumed your question to Jo dealt with emergence in general because you asked in what way that would be emergent.

By the way, my last modification to previous message did not register at posting time so I fixed it now.

Oops  :-[. I may have misread- I thought Jo was talking specifically about emergent gameplay. So, asking "in what way is that emergent?" I meant in regards to how I thought it was used originally.

I don't know how much emergent challenges make the game interesting if there isn't also emergent gameplay. The goal or spirit of 'emergence' has more to do with making the gameplay interesting. If emergent challenges don't accomplish that, then I don't know if the game itself satisfies the design goal of being emergent.

This is just me reading into things though.


Centaur example is totally emergent.

Evasion may or may not play a role in emergence- just an open statement.

Pages: 1 ... 21 22 [23] 24