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 2 [3] 4 5 ... 24
Programming / Re: Races and roles
« on: July 23, 2013, 11:03:34 PM »
Point taken :)

I guess another example is european swordfighting and japanese swordfighting, two styles of melee combat. It's still unclear to me whether this involves genetics or not though - are Japanese or Europeans more physically adapted to their style of swordfighting? Can we claim that a couple of dozens of generations of natural selection through warfare are enough to ensure an entire population becomes better at that type of fighting?

If not, then it simply comes down to culture and preference. In that case there's no reason to have inherent aptitudes or ineptitudes. You would simply use what is available, and therefore become proficient at that. Which leads us back to the notion that everyone starts the same, and you simply level things that you use, without regard to innate abilities.

Disagreed for two reasons.

1. Just being in the presence of said culture increases your aptitude. You might've witnessed pugilist matches or lived next to a budokan temple as a child. Being the product of a culture necessarily exposes you to the concepts and intricacies valued in that society. Even the games you play as a child are preparing you for activities that that particular culture values (that's why games exist).

2. It's incredibly boring for a player to play through the entire existence of a single character. The culture they grow up in defines they're early experience and exposure to different things- this necessarily increases their aptitude. Genetics may play a larger role for survival elements (samoans are especially adapted to periods of famine and plenty, arabs for resistance to drought, africans to resist sunlight, and europeans for wearing clothing and high latitudes), but that's just a matter of categorization.

Say we divvy it up into intrinsic bonuses, aptitudes, and actual skills and experience.

Race defines our intrinsics.
Culture defines our aptitudes.
Lineage defines our skills.

With each crossing over into the other by varying orders of magnitude.

Anyway, from a gameplay perspective I feel it makes sense to have some choice determining aptitudes towards certain skills. Conceptually, I feel race explains this better than a faction or a "class", which just an arbitrary restriction. Ultimately, what matters it the gameplay though, so the explanation is sort of moot :)

It isn't moot if it plays an important part of the narrative.

Programming / Re: Rendering question
« on: July 23, 2013, 10:54:22 PM »
I now have another question, related to window managers: If a bunch of things happen during the turn logic (which would be triggered by keypresses going to the pane showing the game world) that require updating the screen, e.g. displaying text messages, or an explosion appears, or something -- should one mix calls to the window manager's redraw function with the logic like that, or handle that separately, like by passing events to the window manager to be handled later in some main message/event loop where all getting of input and redraws are centralized? If separate, then how does one preserve the ordering and sequentiality of those things?[/quote]

If you are not using real-time rendering, then a change to the game state should inform a window that it needs to redraw (nothing else will!). In real-time rendering, the window is either checking the game state each frame to see if it needs to redraw, or it waits to receive incoming events and redraws.

Each window just reads the state of the game and draws that information in a way that is pertinent to that particular window (status bars, maps, text notifications- etc). You either need to tell a window to update or have the window always updating.

Note that just having an event queue with "redraw events" added to it wouldn't seem to work, since the windows' states would be changing, which means that by the time that queue is finally handled after the logic completes, the windows have changed state several times and the redraws would only redraw to their last state at the time control returns to the event loop.

You don't need an event queue. You simply tell a window when it is dirty and that it needs to redraw.

I suppose this ties in with the "separating render and logic" concern I mentioned in another thread here, but am curious as to how it's done in the context of this window manager-based system.

Separation of rendering and logic has more to do with calling drawing instructions within the logic of the game. Telling a graphical object to redraw is fine. The purpose of keeping them separate is so that we can rewrite either one without effecting the other.

In real-time games, it's common to update the rendering at 60 HZ and update the logic a little faster, say, 100 HZ. The idea is that the logic is always updating slightly faster than rendering, so that you get a more fluid visual experience. If logic updated slower, objects would appear to move in a choppy manner. To optimize render and logical updates, their code needs to be in separate places. The Logical side of the application acts upon the game state, modifying and updating it in various ways, contingent upon input. The Rendering side reads the game state, in an agnostic way, and prints the output. This is a basic I/O relationship.

In a roguelike, this is a complete non-issue, but I think the example may help to illustrate why you want to keep it separate. After all, in the text messages, we need to send explicit information to the text message window (game log). That means calling something like "tmWindow.log(myEnum.combat,combatInfo,whatever)" for each game interaction that occurs. The Window does the drawing, but the logic tells it what to draw. The main point is that the Logic isn't deciding how that information is drawn.

Programming / Re: Races and roles
« on: July 23, 2013, 08:51:08 PM »
Races do give a lot of the fantasy feel to a game - although I am personally more partial to a more nearly realistic or historical theme, which the system you are describing represents better. Still I find it harder to believe that "everyone from Kingdom X is better at archery from birth"... which is kind of what you are saying when certain skills level up faster for people from Kingdom X. Races give a slightly more realistic feel.

Though honestly it makes little to no difference ;)

Historically, that isn't untrue though. There are many bow cultures who both genetically select for natural talent and require its usage as an adolescent (and typically as an adult as well).

Programming / Re: Races and roles
« on: July 22, 2013, 03:29:56 PM »
On the other hand, it could indicate that the character in question is truly exceptional. Maybe because they know their strengths (and weaknesses) and use them accordingly
Well, it could happen, having an exceptional great troll wizard or a champion halfling gladiator. But they would only be considered exceptional among other trolls an halflings as they would need also to compete against other exceptional wizards and gladiators existing in other races, which would have, by far, a greater disposition to excel in such roles.

That's so racist.

Programming / Re: Rendering question
« on: July 21, 2013, 10:38:49 PM »
If we're still talking about a console emulator (that is, the ONLY BASIC drawing method we have is plot_char), some drawing utilities could be in the logical console. Every complex drawing method, in a console, is just an aggregation of plot_chars. So, to draw a widget, that widget will send the instructions necessary to draw itself.

This is oftentimes called a display list. You have a tree of drawable objects that contain other drawable objects that we traverse when drawing the scene (also called a scenegraph). Each node in the graph represents a coordinate (relative to the parent) and possibly drawing instructions (and transformations).

When we draw a widget, we've already scoped to a local point, we just need instructions to draw. We would probably make a library of common methods, like draw_circle and daw_rect, to make things simpler-- though, more importantly, we would try to make sure similar widgets use the same drawing instructions whenever possible or make it so that a widget is a composition of components-- like scrollbars, textfields, etc. At this point though it's just semantics.

So would this "tree of drawable objects" be a separate data structure from the pane/widget one (even though, say, panes contain widgets -- doesn't this already form such a "tree"?) or not?

Yes, it's the same thing. 3D rendering works the same way, if you're curious. The position of an object is just an offset from its parent-- same idea for windows/panes/widgets etc. It's a little different with compositing, but that doesn't matter in this case.

And would those "circle" ,"rect", etc. drawing methods in that "library" be just "free floating" functions and not class members? If members, what would they be members of? The console, as you seem to hint in the first part of the message?

Doesn't matter really.

A good way to do it is to make it so that the Console accepts a 2D array of glyphs (struct representing character, foreground and background color) and a starting position. Then you could have a static class produce graphs to be passed into the Console. Alternatively, you could have these functions work directly with the console or be a part of the console-- it's up to you. Whatever makes most OOP sense. Since we're working with a logical console, it doesn't hurt to have advanced drawing operations there. However, proper OOP would put these methods in a helper object.

You could define a typedef for 2d glyphs called a Graph (or shape or whatever) and use that as the parameter for a console method "draw_graph." Then you can produce as many drawing libraries that you want, so long as they have methods that produce graph objects.

Code: [Select]
draw_rect(console, rect) //call drawing functions internally by passing the console
Library.draw_rect(console,rect) //for better organization put function in static object (most recommended)
Console.draw_rect(rect) //or for simpler libraries put directly in console (least recommended)

plot_rect(rect):graph //pass rectangle information and return a graph object
Library.plot_rect(rect):graph //from static class
Console.draw_graph(graph) // pass graph object into console drawing method.

The top set is faster, but gives you less flexibility. While the second set is a bit more memory intensive but will allow you to work directly with the graph object. Since the console acts as a logical buffer, it really isn't necessary to have a graph object at all, but you might find it useful-- especially for caching certain drawing methods-- IE, a circle of a particular radius could be easier to draw if you cache it as a graph after calculating it once.

Programming / Re: Rendering question
« on: July 21, 2013, 07:58:36 PM »
If we're still talking about a console emulator (that is, the ONLY BASIC drawing method we have is plot_char), some drawing utilities could be in the logical console. Every complex drawing method, in a console, is just an aggregation of plot_chars. So, to draw a widget, that widget will send the instructions necessary to draw itself.

This is oftentimes called a display list. You have a tree of drawable objects that contain other drawable objects that we traverse when drawing the scene (also called a scenegraph). Each node in the graph represents a coordinate (relative to the parent) and possibly drawing instructions (and transformations).

When we draw a widget, we've already scoped to a local point, we just need instructions to draw. We would probably make a library of common methods, like draw_circle and daw_rect, to make things simpler-- though, more importantly, we would try to make sure similar widgets use the same drawing instructions whenever possible or make it so that a widget is a composition of components-- like scrollbars, textfields, etc. At this point though it's just semantics.

Programming / Re: Races and roles
« on: July 20, 2013, 09:00:33 PM »
Races shouldn't be too much more than novelty. They shouldn't alter the paradigm from which you play the game. For example, if you want to fully experience the magical system, you shouldn't be compelled by the mechanics of the game to be a gnome so that you aren't missing content.

What happens here, with races and classes, is that the player's ability to explore certain content is heavily confined. it's better to allow classes to emerge from a composition of skills and items. If a player wants to learn a bit of magic, he should be able to- and it shouldn't be ineffectual just because he's not a 'pure caster.' Games can get pretty stupid with how they make distinctions between classes. Every character should be able to at least learn how to do things.

As for races, I think that our idea of what classes are is a disease. An animistic shaman may be more like a wizard than a priest, and there is no reason why a Troll Shaman may be less powerful or interesting to play than a wizard or a priest. It's important to rationalize how magic works in your world-- are their multiple sources of magical energy? If so-- everyone should have a near equal opportunity to tap that magic in some way that is meaningful to that character.

Lastly, the worst thing you can do is set ANY arbitrary restrictions on the usage of items found within the game. Everyone should, to some degree, find some degree of usefulness with any piece of equipment they find.

Programming / Re: Single Screen Procedural Platformer Levels...
« on: July 19, 2013, 01:42:21 AM »
Cute ^_^.

Programming / Re: Screenies of my cave generating algorythm
« on: July 18, 2013, 09:44:45 AM »
Is your game logically 3D Or 2.5D?

Looks awesome.
Thanks. I'm still deciding but I probably go with 2.5D game logic. There is already too much complexity in the whole project and some parts of it should stay "less" complicated.

Nice example of a 2.5D party roguelike.

Programming / Re: Screenies of my cave generating algorythm
« on: July 18, 2013, 03:57:34 AM »
Is your game logically 3D Or 2.5D?

Looks awesome.

Programming / Re: Single Screen Procedural Platformer Levels...
« on: July 18, 2013, 03:56:40 AM »
A procedural little big planet (sack peoples!) would be awesome.

I think it's more about how you string together meaningful challenges and complexity while regulating flow.

In a procedural platformer you'll have active obstacles that require you to make a series of moves to progress. As long as these obstacles are reachable (within jumping range), you can ensure that the obstacle is passable. Then there are also switches and other things that manage your progress. Mario physics when you jump on enemies can also allow you to generate enemies as a part of the puzzle.

You can also use an AI to play maps with variance to determine what areas of the map are more challenging than others. I forgot what this is called but there are a number of articles on it if you... want me to look it up. It's a rather challenging concept to implement though.

You want to make a Jumper game, right?

I think you misunderstood me a little bit.

I do understand that exploring a site like a cave or a dungeon in third person is the way to go but the world map?

I'm not contending text-based adventuring nor am I suggesting that third-person is better, but that your methodology, from the mechanics you've described, is insufficient.

It feels like you're generating a simulated world. Simulation games can be interesting, but in this case there would be a LOT of mundane activities, so you're looking for ways to short-cut those so that boring portions of the game are skipped and interesting ones receive focus. Games tend to do this to develop a narrative.

So- what narrative are you looking to develop? What narrative does playing your game facilitate? It's not a free-roam exploration game, because you have special exploration mechanics that narrate the exploration in a particular way. So- are these narratives connected in some way? Or is it just a continuous stream of novelties?

Each one of these experiences may be independently interesting, but how do you plan on making them meaningful in a broader sense? How is the 'world map' a necessary part of building the narrative? Your game will offer a lot of breadth with 100k sites, but they may all feel meaningless without some depth connecting them.

Anyway, rolling the dice is what roguelikes are all about.

No. Probability is a 'feature' in a roguelike. What roguelikes are all about are making decisions, without clear certainty as to how they will effect us, in such a manner that increases our chances to survive. I recommend playing Brogue ( for some inspiration. The failure to survive rests entirely on the fault of the player, not the dice rolls. The dice rolling creates variation, not determination, in how events resolve. In many games, the dice-rolling is arbitrary- because if a player encounters a situation where dice-rolling is important, she's already failed. Permadeath requires that a player always caters to the worst possible outcome. This means that dice rolls represent an opportunity for a boon rather than a penalty.

Your mini-exploration game doesn't provide the player an opportunity to avoid dice-rolls. What you really have here is a system of Random Encounters. The player can't foresee what will happen when exploring before making the decision to explore, so she is typically obligated to always explore- otherwise she will be missing content and the reason to actually play the game. So- you have to play a mini-game to get to points where you can play the game... in effect, you actually have two different games connected by a database. This can be interesting, but you will likely get a better game if your development time is spent devoted to making one of those experiences superb.

In games like Final Fantasy, random encounters exist as a means to pace the narrative of the story, manage flow, and develop ambiance. You wouldn't play the game for the REs because they are irritating and boring as hell-- the only motivation to continue playing is the narrative and interesting boss fights (and power-gaming if you're into that). The issue with text-adventuring is that the game is telling me what my narrative is. If it doesn't do more than connect a stream of novelties, it isn't giving me a story. Instead of being able to min-max my survival chances directly, it's obfuscated by a wall of text and some dice-rolling. Since the narrative isn't hand-crafted, what are our motivations to continue playing?

Have you ever played Seventh Sense? Check it out.

he idea of the game is to explore a huge world with tons of sites scattered throwout it (100k places to explore). Some areas will be empty others not.

This is another point of concern. What role does the player's character play in this world? Is she an already established hero or are we going to get a bildungsroman? If this game is primarily about fun simulated mechanics, it seems odd to emulate the simulated mechanics.

Now imagine being halted while in third person by bandits and wild life, as you try to explore a portion of land, just to realize at the end that that area was empty.

Don't generate meaningless areas? It's meaningful if the experience augments the narrative. Just make every path tie into some overarching theme. Or find ways to incorporate these seemingly nonsensical elements into a theme. For example- if you slay some goblin nobody but he turns out to be the goblin tribes successor king, they may start hunting you down to the point that they ally with some opposing nation that seeks to conquer that lands that you're involved with and... yada yada yada. You can make it so that the scope of an adventure is predictable or influences future events in some way.

First, you need to understand what type of land you're about to explore because it can be a dangerous place to go in at a specific time of the day, month, season or with certain weather conditions. You then define the pace at which you will explore it and define what you will be looking for. You will be able to actually define what each member will do during the exploration and if they should spread out to explore it way faster or remain together to increase their survival chances. Each choice shall bear an advantage and a disadvantage which only kin and careful players will sucessfully exploit.

I hope there are some options that will automatically do all of that for me. Will it tell me the danger level or do I need to discover and remember these things myself? It seems like another example of a poor mapping of feature to feedback. The player likely doesn't care about all of those things, just whether or not it's dangerous and how likely the area has something they are looking for.

Many events can be triggered during the exploration process like being ambushed or attacked by wild life, depending on the party skills that will tell who spots who first, giving the player the upper hand or a chance to evade an encounter.

The usage of skills, here, doesn't seem interesting in itself. The opportunity cost of skill development and the relative risk of choosing to go into an area could be interesting, but just having a skill floating there to modify random encounters can be disappointing. We want to get to POIs that are interesting- will these skills be useful in said POIs? It seems like we end up playing two different games. One is a dice game that determines what situations we end up in, and the other is a roguelike. They are connected only in that they share the same database. Sorry if I'm getting repetitive. Mini-games are fine, but, as this seems to be a game of exploration in many ways, your mini-game will be the main game and the roguelike will be the mini-game.

Other things will include unfortunate and fortunate consequences like falls and stepping on traps but also finding hidden treasure / items or special caravans carrying special cargo at a special price. Some situations will require player input to make important decisions like deciding if the exploration should be halted due to spotting a large enemy force or issuing shelter due to the weather changing, even though the area has been almost fully explored.

In a simulated world, locals become aware of POIs as a result of POIs likely being connected to civilization in some way (that is oftentimes why a POI is a POI). What are we exploring for in this game? The POIs could be unlocked via books or some other mechanisms that involve interacting with locals-- is there a 'need' for a world map? What incentive does the player have to explore apart from finding the fun of the game in POIs? If it's for special crafting opportunities (like in pokemon or something), why is the player motivated to do that? Is the player punished for not doing it?

I do think that the auto-explore feature does carry interesting decisions to make, in fact I believe its WELL above the options present in traditional roguelike exploration sessions. In ADOM the only options I had when exploring the world map were either [F]ight or [E]vade an encounter, that was it.

Okay- instead of paper-rock-scissors, it's now paper-rock-vulcan-lizard-scissors. It still isn't a mechanic that the player uses in a meaningful way. At the point in which it is, it's now the main game and the roguelike is the mini-game. Again- sorry for being repetitive.

Please understand, this post is all about world map exploration, and not about the best method on how to explore a dungeon or a cave, which is what this thread is all about.

I hope it's clearer now-- I'm not contending with your method of world map exploration, but rather the overall approach to developing the scope of your game.

I think that we need to know more about that to be able to rationalize whether your method of exploration is going to be interesting. The gameplay could be awesome, but I'm having issues understanding why that gameplay will be good. It seems like you're just trying to figure out a short-cut to manage a game that is too big-- this suggests, to me anyways, that the game is... well, too big.

Programming / Re: Rendering question
« on: July 17, 2013, 05:41:26 AM »
The thing I was wondering about though was that in Curses, the "window" mechanism seems like a natural one for implementing panes (especially with the Curses panel library), but Curses doesn't maintain that input/window separation, in fact it joins the two together. So it seems like to keep logical separation, you can't use the Curses window mechanism.

Unfortunately, I'm not that familiar with curses. If you want to be able to swap out the renderer, I'm not sure if you can rely on a platform specific implementation of windows, unless it's possible to logically abstract the entire curses drawing interface. If you want to use curses specifically and don't have an interest in another drawing methodology, go for it. The I/O handling of panes is more conceptual-- if what curses does is intuitive and makes sense to you, go for it. I only prefer a top-level I/O mechanism so that I can modify raw input data if needs be (like if we want to catch shift/ctrl at the application level instead of the pane level).

However, should a pane "crop" whatever is drawn inside it (as opposed to floating on top)? Doesn't this require additional functionality/computations in the underlying Console or 2D graphics system?

It's up to you. In most cases, you will have a clear understanding of how you want your UI to look, so you don't need any special logic. You could crop or not-- just depends on what you want to do. The rules with which a pane renders its widgets depends on the pane. A pane is just the base container for widgets and should not set very hard restrictions on what can be done with them. In most cases a pane will represent a partition of the screen that you render specific objects to, but the way in which those objects are rendered might not limit their drawing instructions to within that pane. The pane is basically a local coordinate system for drawing groups of widgets.

Programming / Re: Rendering question
« on: July 17, 2013, 03:21:23 AM »
The WM can be the input handler-- all you do is pass the input down to the focused pane and let it decide. A pane will have its own keymap for whatever actions it can perform.

edit: Well-- your input handler will convert input into 'keys', which the pane will map to an action. Basics of keymapping.

So am I right in my conclusion that it dispenses with the need for the "game state mechanism" for handling menus and so forth that I just mentioned?

Also, what about what I asked here about using Curses, with its "windows" and how they're tied up with the getting of input?:

I would likely make the input handler a separate logical object. All it does is handle the platform specific code for receiving input. It would then send meaningful interpretations of that input to the WM, who would then pass it on to a specific pane, from whence that pane's mapping of that input to some action would take effect.

A WM IS a state machine. the current state is the focused pane that receives input... Ah- I should clarify a little bit. A pane doesn't necessarily have to be nested within the logical boundaries of its parent pane-- for example, you may have a tiled pane open a floating pop-up menu. In this case, the menu would be registered with the WM instead of the parent pane, but the menu would still pass focus/data to its parent after its function has been served.


I think you're trying very hard to generate a realistic world and then find a way to make the experience of that world a 'game.' In reality it will just be a simulation and therefore very difficult to control whether it's fun or not.

I've linked to the PCG-wiki's article on Teleological vs ontogenetic because, I think, that the concept will be useful to think about here. Do you want to crutch a player into a simulation so that it feels like a game, or do you just want a game? If the latter, then just make everything interesting and challenging.

Unfortunately, how you generate your world and how you invite a player to experience this world depends HEAVILY on what sort of interactions the player can have with that area. For example-- if you generate a realistic mountain range but then don't have a climbing skill, there is a sharp disconnect between what the player can do and what experience you've generated for them.

To put it in perspective-- Games are interesting for the decisions. A good rogue-likes provide lots of subtle and overt decisions that, despite the game being randomly generated, lays fault for losing entirely on the shoulders of the player. Your auto-explore idea doesn't demand any really interesting decisions. There is no emergent gameplay in this-- it takes the experience out of the hands of the player and rolls dice to determine their fate.

Making a game out of a completely simulated world is... cumbersome. The player doesn't experience all of the work you're putting into the game-- it's just a poor mapping of feature to feedback.

Pages: 1 2 [3] 4 5 ... 24