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.


Topics - requerent

Pages: [1]
1
Programming / Alternatives to Mana/MP?
« on: May 03, 2013, 09:56:39 PM »
I'm look for words to describe the quantification of magical energy.

Mana is the most common, Od is pretty good, and Qi/Chi/Ki are all okay also.

However, I'm looking for one that is Renaissance-localized: I'm working on a project cosmetically inspired by the Italian commedia dell'arte, but is very loosely based upon the historical conflict between the Basque people and the Spanish kingdoms.

I want an anglicized word that describes a localized Spanish version of Magic Points- alternatively a Basque or Italian version would work. I don't mind anglicizing a word myself though- so if it's in another language that's cool.


Edit: It would be nice to have a repository of words in different cultures/languages that describe this idea.

2
Programming / Modeling the game world- Sensory Systems
« on: April 23, 2013, 04:52:55 AM »
I'm working on creating a simple but thorough framework for roguelikes so that I can prototype a few that I've had jumbling around in my head. It's a fairly ambitious project, so I'm working to abstract as many concepts as possible into a simple construction.

I typically design feedback first, with a central focus on UI. If there is no UI for a feature or it does not yield any feedback, then it really doesn't matter anyway. In this spirit, I've begun working on creating an abstraction of agent perception, which is used for modeling AI.



In this model, the agent is both a controlling intelligence and an entity in the environment. Percepts are the information that the entity can interpret, from which the agent may evaluate and select from its actuators how it will act with the environment. I'm trying to reverse engineer the logic in the real world into a sensible and easy to work with abstraction. Within the agent, we can break this down even further into Sensory Systems and Sensations. The Sensory Systems describe what and to what degree an agent can acquire raw data, or Sensations, from the environment.

The five human Sensory Systems:
Vision - Sense of sight
Taction - Sense of touch
Audition - Sense of sound
Olfaction - Sense of smell
Gustation - Sense of taste

These Sensory Systems detect raw input for the following Sensations (in humans- other animals have different senses for different sensations),
Photoreception - Brightness and Color of light. (Vision)
Chemoception - Chemicals. (Olfaction, Gustation)
Nociception - Pain (All)
Electroreception - Electrical signals (All, not trusted by instinctual brain)
Mechanoreception - Physical interaction, including sound (Audition, Taction)
Thermoreception - Temperature (Taction)
Proprioception - Kinesthetic sense (Taction)
Equilibrioception - Balance (Audition)
Magnetoreception - Magnetic fields (Vision, not trusted by instinctual brain)
Chronorception - Time and circadian rhythms (All via Zeitgebers, mainly Vision via daylight)

Note: It's interesting that our pleasure from food is derived from the intersection of chemoception from our olfactory and gustatory systems-- If both the taste and the smell converge, we know that it is safe to eat, but if they diverge, it may not be and we find it unpleasant.


Is it important to distinguish Sensory Systems from Sensations? I think so, as we may want to utilize this abstraction layer for varying effects. In a simple game, we may just have a single Sensory System and a single Sensation (which is most roguelikes)- but we should be able to add and map as many as we want without problems. We also want the sensing abilities of each entity to vary in interesting ways- creating a distinction will allow us to input emissions/Sensations into the model and allow entity Sensory Systems to gather the data. We can create a mapping of Sensations to Sensory Systems- where the Sensory System describes an individual's ability to acquire Raw Data from the environment. For example, Photoreception has two basic properties- Brightness and Wavelength, which are typically defined via spectrum. Vision describes the range of brightness and wavelength that an entity can detect. We typically can't improve these Sensory Systems without artificial means, but we can improve our ability to evaluate these Sensations. Ultimately, we need to process these sensations before delivering them to the UI or AI for actuation. It then seems useful to abstract how these sensations are evaluated. I've come up with three basic super-modes.

Cognition - Conscious analysis of data.
Intuition - Subconscious inference of data.
Instinction - Unconscious mapping of data to evaluation.

While the quality of input can't be improved (except by artificial means), our processing of that data can be trained. It may not be important to have more than one evaluation mode for a game, but they help to rationalize certain elements of the game. One possible application may involve the perception of Ghosts. A ghost may provide little raw data to analyze or react to, but we may be able to intuit it regardless. Not by how strong our senses are, but by how sensitive we are to processing subtle influences. A few examples to emphasize the distinction:
Sympathy - Cognitive. We consciously rationalize how another person's state would feel (sensation reasoned within our imagination).
Empathy - Intuitive. We feel what another person's state actually is (sensation mapped to emotion).
Fear Sense - We can innately detect, on a continuum, how afraid a person is through a mapping from our sensory input. Doesn't provide information, just automatic reactions (sensation mapped to reaction)- chill down the spine, or a surge of hormones.

These concepts overlap in application, but different evaluations and weights may provide information that provides incentive to behave in a particular way. Since the player's avatar is the aspect of the player Agent that is acquiring information from the game world, it's also partially the Agent's job to interpret that data. From a UI point of view, providing the player with raw sensation data makes them responsible for interpreting the meaning. While this can be very interesting, we typically want the Agent's abilities, stats, skills, qualities, etc to provide the information. It could be a lot of fun to play a character that is manically afraid of all things, especially if the player doesn't know this. IE. Instead of a peaceful townsfolk, you suspect that they want to dismember you in a ritual sacrifice to their bloodthirsty deity-- okay, that may be TMI, but the avatar could fail to properly interpret their friendliness and trick the player into slaughtering them all. Evaluation includes misinformation-- which can be a lot of fun.

Another more sense-related example may be understanding why a sensation exists. The Aurora Borealis is the result of particle radiation (primarily from the sun) sneaking by the earth's magnetosphere and interacting with the atmosphere. Suppose our Avatar sees a flash of light- how is the avatar to evaluate that information for the player to make reasonable decisions from? The player will always be able to guess, but a well-designed game will not provide too great of an advantage to an experienced player (we don't want features to become arbitrary at different player skill levels). Is it a magical spell? Divine judgement? A flash of magnesium? Bright Light has meaning relative to that Avatar.

Telepathy could be rationalized without the addition of new senses or sensations, but as a property within an intuitive evaluation mode. IE- suppose that Telepathy is derived from Magnetoreception. The fields emitted by cognitive beings (higher wavelengths, or something) may have subtle effects on the ambient magnetic fields and, with enough training, we might be able to create an intuition about these subtle fluctuations- thereby inferring the presence of nearby entities. We may be able to develop a way to further evaluate this information to deduce what these entities are thinking. In many ways- cognition, intution, and instinction just describe different facets of the same ideas.

Creating meaningful evaluation modes really just depends upon how senses, sensations, and other factors are all mapped together. I probably wouldn't ever try to implement a realistic sensory model- but I thought the abstraction may be useful to others. There are some simple graphical techniques we can use to convey this data. 'X's are unknown, and any further letter/hue/saturation increases specificity. 'q'uadriped, 'd'og, 'p'ig, etc. Evaluation modes have much more to do with what emission patterns correspond to properties of creatures and objects-- that is, the evaluation modes are what tells us it's a humanoid or a goblin, friendly or hostile, dangerous or pathetic- etc.

To summarize:
Entities produce emissions, emissions are detected by sensory systems in the form of sensations, which are then rationalized by evaluation modes and presented to the UI or AI for decision making. Sensations that can't be completely rationalized are provided as raw data to the UI in a form that is relevant to that Sensory System (IE. if we hear something but don't know what it is, we might notify the map-- either as a direction, a specific location, or a general location-- maybe the type and intensity of the sound as well-- if we hear it over time, we may can filter the emissions to improve the specificity of the evaluations).

On the most mundane level, this is trivially implemented with singletons. Brogue's evaluation mode is total- anything you can detect you understand, but your Sensory Systems are limited to vision, clairvoyance, and telepathy. Your emission to the enemy is in the form of a heat map while their sensory system is described by their scent attribute. Stealth and dark places reduce your emission of heat (not formally heat, but an abstraction that describes your overall emission). You have perfect vision, apart from LOD in the form of light- so anything in your LOS/LOD you have perfect information about.

I imagine most any roguelike could be specified using this abstraction and done so in a manner that is both easy to implement, use by AI, and easy to communicate to the player.

3
Off-topic / Linux and Python
« on: March 14, 2013, 09:22:10 PM »
I'm looking into taking Python a lot more seriously. I learned it for a Machine Learning course a while ago, and, well, I always keep going back to it for prototyping and the awesome math libraries.

I've been forced to rely primarily on windows for the last year, so I'm a bit out of the loop on the linux breeds. Historically I've always been an ArchLinux user, but their decision to package python 2 as 'python2' and python 3 as 'python' is, more or less, unacceptable (every other distribution does 'python' and 'python3', to avoid breaking the kabillion python 2 scripts out there).

Until that problem is rectified, I need a new distro. Another thing that is giving me a headache is the GTK vs QT problem. It's never really bothered me, but all of the python IDE's in linux depend on one or the other and I have no clue which one I will prefer given that I haven't had an opportunity to use any of them (I love Python for Visual Studio- but pip in windows never seems to work).

I've never been fond of Ubuntu or it's spawnlings but I don't really want a customized distro. Just something that is out of the way and doesn't waste resources. I don't want to fiddle with Gentoo, I really like the Enlightenment shell (it's ridiculously faster than any WM/DE I've ever used, including tiling wms), but there really isn't a distro worth using that runs it (bodhi is meh).

I'm downloading Funtoo now to give it a try, also went ahead and picked up the latest Fedora and Sabayon to see what they're all about. I'm just tired of messing with this stuff. Any advice for python development specifically?

4
Programming / Combat Systems
« on: February 13, 2013, 08:47:24 PM »
As I see it, there are two objectives in deciding a combat system- coherence and fun. Too much random is unfun while complicated algorithms are incoherent, resulting in incoherent player decision-making. Too much determinism, however, can also be unfun- as it produces a bit too much tedium and chess-like stress.

I suspect that many use a probability distribution in combat to ensure that things are mostly predictable, but allow for the occasional random win/fail.

I've been fooling around with the source code in Brogue, which is a very mechanically transparent game, and realized that the way the combat actually works isn't particularly communicated well to the player. Specifically- how much Armor, Life, Damage output, and Accuracy are necessary to be successful at any given depth. Brogue diminishes the importance of knowing the precise numbers with the various staves/wands/consumables you find- but it can be difficult to know what trade-off is actually being made when you use a Scroll of Enchanting. If I put an enchant into my Broadsword over my Plate Armor- how does that effect my ability to survive?

I particularly enjoy Brogue's system, which is why I've been looking into it. I don't want to talk about Brogue specifically in this, but rather what systems, in a general sense, make good sense. One issue I see with Brogue is that it uses a number of internal mechanics that the player doesn't really know about- particularly in how hit probability is determined. Defense, for example, has diminishing returns, while attack (the relationship between accuracy and damage) has increasing returns.

The numbers for the individual monsters, however, are so finely tuned to the system, that it really isn't clear which is best to enchant. And in fact, against the most dangerous monster (Tentacle Horror) with top-tier vanilla gear and 10 enchants to go around, it makes very little difference where you distribute enchants- you'll win by ~1 turn worth of damage (1.5-.5, favoring armor) assuming average damage relative to hit-probability is dealt each turn (in other words, if you do win, you'll die if anything breathes on you shortly after). In a balance sense, this is problematic because it leaves much less flexibility to deal with long-range flame attacks. In Brogue, there are essentially 3 problems you have to solve to succeed- A solution for dealing with Revenants (immune to physical damage- not really a big problem but still pertinent), a solution for surviving Fire-breathing (from dragons and other deep-dwelling denizens), and a solution for horrors. So we run into other balancing issues for solving each problem as each problem demands a certain number of enchants in different categories of gear.


There are two real issues here-- One is affordance. How can we communicate to the player that what they're doing actually improves their odds for surviving, and two, how can we produce a game experience that doesn't appear to be tailored for the player but still provide opportunities to advance without compromising a diverse experience?


So-- A sort of general question-- What makes sense? What sort of combat system is simple enough to grasp but allows for interesting and emergent scenarios for the player to deal with without promoting a 'hunt' for particular gear for particular solutions? What examples do you think are most successful, equitable, interesting, and diverse?

I suspect that the D20 system is a popular answer to this problem because of how familiar it is- but at the extremes (high and low levels), the system is wholly uninteresting- too random or not random enough.

5
Programming / Interesting advancement paths/combat mechanics
« on: May 21, 2012, 03:47:18 AM »
I was just wondering what inventory/advancement/battle mechanics you all feel were interesting. Not necessarily well implemented or appropriately balanced, but offering an interesting range of gameplay. I'm primarily looking for novel or innovative systems that deviate from the standard.

FF8, for example, seemed very novel. A lot of room for customization, but the system failed because that customization ended up being illusory and exploitable in terms of maximizing power (good choices were obvious-- an unnecessary amount of options). The idea that you have a static progression and several modular options is a premise for good design, especially when you want to abstract the system beyond RPG characters. The relationship between equipment and materia in FF7 made for some interesting strategic approaches, but in both cases all of the 'skill' comes from preparing your characters, not from the actual implementation.

I tend to dislike immutable progress-- Using ability points and skill points, in my opinion, tends to be bad affordance. Although I'm a fan of D&D games, the rules converge on an emergent set of ultimate builds with some wiggle room in regards to specialization. Design and procedural design should balance to the more powerful player, so the game becomes more about building and less about playing. A variety of builds as a form of implicit difficulty setting is just as much a nuisance. I similarly dislike classist approaches-- everything the player finds in a game should be useful. Otherwise the RNG has to be tweaked to satisfy class-requirements for progress and the whole game feels less consistent and contrived.

Anyhow- I'm just curious to hear what kind of mechanics you all have found to be particularly inspiring in regards to how they could be used for the genre.

6
I've been meaning to get started on my roguelike project, but the more I prepare to write the first line of code, the more I feel like my traditional Java-based setup may not be ideal for me. I love Java, but I'm going to want an approach more optimized for prototyping that is also less verbose.

I want to have a wide array of deployment options (I would sacrifice this though)-
Compile to mobile device, compile to binary, publish on web, or distribute via source without ridiculous compilation instructions (Obviously, development will have to be considerate of the restrictions for each platform). If I can publish to web the other options aren't really important.

I willingly sacrifice control for productivity-- I don't really want to deal with pointers or memory management. I like code-completion and every form of spoiling that Java developers are used to.

I want concise or ultra-readable syntax. I want to shorten the number of times I have to push buttons.

I need the option to run CPU-intensive simulations.

I want to be able to prototype quickly- either making changes while the program is running or quick compiling. An interpreted language with the capabilities of compiling to native would be cool.

I want my environment to be easy to set up or come mostly already set up. Nothing obscure.

I'd like my deliverable to be lightweight. If it must include a VM it should be tiny.

I don't care about preexisting libraries- basic data structure management is all I really want.


I know QBasic, C/C++, Java, AS3, LISP, and some dumb scripting languages. I firmly believe that a programming language and development environment should do as much work for you as is possible. I want to think less and implement more. I've already done the whole 'compile linux from source' thing and am not in this for my personal education of programming concepts.

I've looked at Scala and I like it, but it's not great for prototyping because of its bad compile times. "Drink the koolaid" cults are also not very desirable.
I've looked at Python, but its obsession with dynamic features makes it a poor choice for CPU-intensive simulation.  This could be done with C/C++ extensions, but I easily get sucked into optimizations and want to avoid thinking too much.
There are some Python derivatives like RPython that looks interesting, but I haven't heard anything about them from another human-being.
Javascript/HTML5 has very good performance now a days, but I don't think it's a great choice if things get complicated.
I'd just use Flash, but the VM, on account of a sub 7-mb distribution size, is total shit.
I'd just use Java, but I don't want to require the JVM.

Anyhow-- what are y'all's experiences?

thanks.

7
Programming / Designing Difficulty
« on: March 01, 2012, 09:28:41 PM »
Hola Roguelike likers!

I'm working on a thesis that has a little bit to do with procedural content generation and wanted to spark up some discussions to share some opinions and get some impressions. Most of the concepts I'm interested in have more to do with roguelikes than anything else, so I thought I'd start here. I'm not too sure how active this place is- but I hope that it serves as the general hub for RL development discussion that I'm assuming it does. If anyone has any suggestions as to where a better place may be, please comment!


Divorcing particular topics from the context of my entire project is a tad tedious, so hopefully I can do that without producing large blocks of text (not likely). To start, I'm interested in creating some vocabulary with which to establish a more appropriate paradigm for looking at particularly important concepts in the design of a game. I'd like to begin with defining what it is in a game that makes them difficult. By difficult I mean simply that the incremental challenge of the game is pleasurably stimulating and keeps those addictive juices flowing in the brain.


There are two basic concepts that I'm rolling around, complexity and solvability-

The first is solvability. How solvable is any given game? Upon entering a room, we can abstractly look at the 'problem' of the room in terms of an unoptimized minimax tree. The player is obviously the maximizer while the 'room' (and challenges therein) becomes the minimizer.

Within this tree of potential game states, how many terminal nodes result in a victory for the player? Or rather, How many are solutions? The more paths that result in a victory condition, the more solvable the room is (room is an arbitrary measure of scope- we can think of the entire game's solvability based upon the solvability of each region, of each level, of each room, of each monster, etc). In all games, the solvability of a game tends to decrease as the player progresses. This quality of a game, however, is only interesting if combat doesn't heavily rely on probability (Dying after a stun with 99% Stun resist in ToME is NOT fun OR interesting).

Solvability is typically addressed with an overly dependent relationship between designer and play-tester. If we can design procedurally generated content so that its solvability is within a desired margin of probability, it's possible to make difficulty less arbitrary and more procedural. This is interesting because the game world itself becomes an intelligent opponent providing us with a measurable degree of challenge. Solvability also includes stalemates (which are equivalent to NOT losing)- bypassing a room or running away.


The second concept is complexity. Complexity more or less describes the permutability and variety of actions- How many solvable game state paths already exist as an isotope? How many different actions are necessary? And how many total actions are necessary?

At the start of most games, the player has a number of total possible actions. As the game progresses, they acquire new actions. With these new actions comes the responsibility to incorporate them advantageously into normal play. In most games, they typically don't alter the outcome too much, but they reduce complexity (and thus the risk of ending up in an unsolvable path) when properly used in a situation that would normally have high complexity. Whatever the case for a particular game may be- as more actions are acquired, the difficulty of the game 'should' adjust to provide continuous challenge to ensure those new abilities are, at times, necessary components to victory or necessary for a perfect victory (one without losing a lot of HP- or something similar).

In a game where difficulty isn't increased arbitrarily, but built-in to the already randomly generated game world, we can think of this in terms of enablers. We cun run straight into Lava Lake and try to slay the Fire Dragon- but it's complexity will be greatly reduced (to the point of being possible) with that ring of Fire Immunity.




Solvability and Complexity are particularly important in Roguelikes because of their randomly generated nature. How do we know our randomly generated challenges are actually challenging the player? How can we ensure that the gameplay continues to be interesting? How can we not completely bone the player after all their hard work?


I'll talk briefly about ToME and Brogue, since they represent two ends of the Roguelike spectrum that are very successful-

The first is ToME, and the game that I feel falls the shortest in terms of being interesting in regards to Complexity and Solvability (as far as the random generation of challenges are concerned).

ToME is filled with critters and critters of enemies, but there is very very very little variety or complexity to combat. When we acquire a new ability, we will think briefly about how this ability fits into our standard mode of operation, but we don't really need to think very much about what we're doing.

Our character is either strong enough to solve a problem or isn't- the challenge has very little to do with HOW we play our character because the BEST move (and best way to build a character) is often very clear. In the case of ToME, we're playing against a random number generator- there's very little intelligence behind how the game produces challenges.

After level 10, for example, a whole new set of monsters are randomly generated. The only significant difference, in terms of difficulty, is probably the existence of stealthed enemies (which doesn't make much difference). These jumps in difficulty and complexity are arbitrary and typically uninteresting (just one more thing to think about). The game becomes much more interesting after we reach the Far East, but most contests leading up to a boss have more to do with resource management, equipment, and character design than with tactical decisions. This is in part due to the role of unrestricted resting- which is a necessity given the inherent imbalance of class abilities. The problems with class restrictions in ToME are more appropriately addressed elsewhere, but it's important to note how the structured approach to acquiring abilities and the variety of abilities that can be acquired influence complexity. There is so much variety that it's too difficult to make gameplay dependent upon it. As a result, the difficulty moves laterally about the shallow end of the pool. That isn't to say that ToME isn't hard. Just that it isn't complex (despite all the different options that a player has).

ToME seems to have a ton of depth in regards to how a player creates a character to solve the problem of the game world. However, the game world doesn't ask much from us- it's more about intelligent min/maxing and hoping that we don't get hit by a WTF dice-roll moment. For this reason, the infinite dungeon is a lot more interesting than the actual game- It, however, more readily exposes some of the problems with how difficulty changes. Don't mean to sound Harsh, in regards to ToME, it does a lot of things very successfully- but I think it's only remaining problems revolve around its difficulty.



Next up is Brogue. My longest run was contingent upon a heavily enhanced staff of discord. Brogue is interesting because we emerge with our own 'class' that we can play and build up based upon the tools we find.

Brogue starts out with very few actions possible and virtually no complexity. Because there is no complexity almost every path results in a solution for the first 4-5 levels. You can hold 'X' for the first several floors to save a lot of time.

By the fifth floor (or so), if we haven't acquired a certain set of tools (including potions), we're likely to be boned in the next few levels. The further we go along, the more we depend upon the RNG to increase our range of abilities in a way that actually allows us to deal with problems. In most cases, the order in which we use our abilities doesn't matter very much. Against a hard enemy I need to use all my charges and toss a few javelins- against easier challenges I do less. Sometimes order matters- but decision-making in Brogue is fairly straightforward.

The issue lies in the fact that Brogue's monster generation is always depth-based. If the RNG hasn't graced you with the right/enough junk, it's not likely to be a successful run. We can make decisions to reduce our consumption and increase our chances- but we can never be certain as to the solvability, given our progress, of a level. We may simply not be strong enough by the time we hit a certain depth.

Brogue also has a tendency of providing us with dead-ends or, despite a speed-running esque approach, starving us to death. Our solvability isn't assured. Starving to death when we haven't been making frivolous actions or even the slightest bit of backtracking and avoid resting at all costs is the most unrewarding death.



The overarching problem that Solvability and Complexity expose is assuring that we don't screw the player out of their hard work and ensuring that it's rewarding and meaningful (as opposed to frustrating)- or that we at least honor them with a glorious death. I haven't touched chess-rogue yet, but it's design (Being something more like a procedural DRoD than a Roguelike) seems to satisfy the objective of reducing solvability and increasing complexity. It just lacks some of the more interesting RPG-esque elements and emergent gameplay that makes Rogue interesting.

I personally think that a roguelike should give us challenges (mainly combat, but also other types) that are more puzzle-esque and strategic (and less RNG-based WTF moments). DRoD is an excellent example of this, but it's by the grace of level-designers that it explicitly satisfies complexity and solvability issues (at the expense of flexibility- it's probably less roguelike than chess-rogue). It's more interesting to have diverse solution paths that allow a player to develop their own playstyle, but to demand that that playstyle be refined over the course of a game. As a side note, fighting games do a great job of capturing a player's personality without necessarily confining them to a particular set of decisions.


Accomplishing desirable solvability and complexity procedurally is a pretty complicated problem- how can we generate a 'room' that with some certainty and in reasonable generation time, will give us solvability and complexity within a desirable range of difficulty? Some probabilistic heuristics would make it possible and there may already exist a few models to implement such an idea. In most cases, we wouldn't bother analyzing or shooting for such an objective, but just try and make sure that problems are reasonably difficult by a certain point in time by the virtue of what content is being generated (such as in Brogue or in ToME).  Unfortunately, the complexity of such a methodology is typically lacking and the solvability isn't necessarily certain- the burden of montonous work with a sudden dice-roll of death sucks. Although we aren't dissuaded from playing RLs for these reasons, I feel like RLs tend to lack completeness as a game because these two problems aren't addressed in a formal way. We don't even know if there is a solution because there may randomly be a dead-end or coincidentally unbeatable monster. They aren't necessarily solvable and they don't necessarily provide continuous challenge.


Anyhow- more to think about later. Please let me know what you think.

Pages: [1]