Messages

91

Programming / Re: Alternatives to Mana/MP?

« on: May 07, 2013, 09:51:15 PM »

Charisma! For bonus points you can pretend during character generation that it's the traditional dump stat

LOL- considered Charisma, but it already has a place in D&D canon. I want something people aren't completely used to.

92

Traditional Roguelikes (Turn Based) / Re: Yanotavar, formerly known as Iso-Angband

« on: May 07, 2013, 07:48:52 PM »

Ahh... the texture for the top of the walls isn't tiled >_<.

93

Programming / Re: Alternatives to Mana/MP?

« on: May 07, 2013, 07:47:53 PM »

For this project I'm working on, there is only one energy resource- so I'm not worried about confusing anybody.

I like something that has to do with communion- that's interesting. Although Anima makes a lot of sense, it isn't as theme-specific as I would like. I wasn't really sure what I was looking for at first, but I have better idea now.

The setting is somewhat stage-like with magical masks and puppets. They serve as metaphors for power, control and hierarchy, but it's driven by magical forces drained from nature, and yet should have something to do with performance arts.

I was thinking something like 'panache' or some other word that captures the idea of stage presence and the ability for a performer to manipulate or influence a crowd.

94

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 06, 2013, 05:19:07 AM »

@requerent:

Thanks. I'm wondering, though: isn't the system supposed to contain a list of components (it was mentioned that a rendering system has a list of graphics components in it and that's how it is in my newest MiniRL program)? Yet update doesn't update by component, but by entity. Yet if all the system contains is components, how does it update by entity? Or does update(entity) go through the list of components of the entity and work only on those components that are relevant to that system?

I thought that might've been confusing.


Say we store our entities in a Hash Map or a Dictionary. The Key used for the dictionary represents the entity and it points to a list of components.


A system only need to know of components that deal with it specifically, but it also needs to know of the entity so that it can add new components if necessary. We get an access-time speed-up by keeping a local array of references in the System, and we can use the EntityID as a way to keep multiple arrays of components parallel. For example, when we evaluate Position and Velocity, we need to know which velocity and position represent an entity- we can keep an internal parallel array to do this. For a turn-based game, we need to ensure that each System's internal array of component references are ALL parallel, so using a unique EntityID is the solution. Alternatively, you could pass the entity and parse the entity data each system update, but I think that's poor data management.

95

Programming / Re: Alternatives to Mana/MP?

« on: May 05, 2013, 08:24:35 PM »

In old fairy tales and myths, magic usually either has no specified limit (like, there's no rule for how often Odin can turn into a bird.  He can probably do it whenever he wants) or else it has a finite number of uses for a specific power (three wishes, etc).

I think part of it has to do with suspension of disbelief. A mere mortal isn't capable of rationalizing the full potential of a God-like being. Most paradoxes in theist religions are solved by simply acknowledging that humans can't fully fathom Gods- to do so is an act of bigotry. It isn't our place to assume the capabilities and objectives of a divine being, we can only operate on what information they've given us. Just as a dog can only understand so many commands, so too is a person's perspective of divinity limited.

Unfortunately, for a video game, we need to find some way to rationalize their super powers in a logical way, otherwise we can't make gameplay mechanics out of the ideas. Whether it is casting time, recharge time, mana, stamina, or whatever, we're only trying to represent the idea of Opportunity Cost as it relates to the resources that a character has at its disposal. From a design point of view, whatever the energy currency is, it should be as discrete as possible.

As far as the narrative is concerned... it's a failure when that energy currency isn't an integral part of the story. That 'lolz I'm out of MPs' moment is a failure of the narrative- not necessarily the mechanics. Though oftentimes the two work together to destroy the meaningfulness of the game.

96

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 05, 2013, 07:59:57 PM »

When is each system's "update" function called, in a turn-based non-real-time game like a roguelike?

On each logical tick, we wait for input that will manifest as a player action. Once we get a player action, perform it and continue in the loop.

In a turn-based game, you typically want action-resolutions to occur on the same turn, in which case you're going to update each system per entity, instead of each entity per system. This literally just means inverting the game loop so that you do something like,

Code: [Select]

foreach(entityID:entityIDs) foreach(system:systems) system.update(entityID);
Where one of the systems is an input handling one that waits for user input.

Though you don't want to get input for every entity in the game, just the player, no?

As if the input system waits whenever its update(<entity>) function is called, then you'll get a lot of useless waiting where it waits for input for every monster as well as the PC. So do you have some kind of "input component" on the PC that other entities don't have, and the input system checks for this component, and if there's one present, waits for input, then updates the component with whatever input is given?

You DO want to get input for ALL entities. Just try to realize that the input isn't coming from a keyboard. The input might be better rationalized as a command or instruction. The AI gives commands to their respective avatars just as the player would-- the only difference is that the human interfaces with a keyboard.

You can have separate systems for this-- Such as an InputSystem to fetch the command for the player, but realize that only the player character's entityID and components are subscribed to that system. So it's fine to call all systems on every creature's turn, because each system is only going to do anything if that entityID is used within it's internal component references. I use entityID as a way to indicate to systems to only update one entity at a time- which is necessary for a turn-based game.

@requerent: In one of your earlier messages you mentioned how one does not need events or messages in a component system. Now does that latter bit mean that I should do away with the "handleMessage" stuff on the components in my test program?

I got the whole "send messages to the components" stuff from reading this:
http://www.gamasutra.com/blogs/MeganFox/20101208/88590/Game_Engines_101_The_EntityComponent_Model.php

She's talking about short-cutting the Component-System idea for broadcast messaging. That is-- you may want to send out global, component-type, or entity-local messages that components capture to perform data transformations on themselves. These transformations could result in other broadcast messages being thrown and... all of a sudden you've begun contradicting the whole point of components.

If you need something like that, the component solution is to just make another system/sub-system that deals with that case specifically. Systems are intended to be logically discrete objects-- they can be numerous and as short as possible.

She goes on to say that you can flexibly solve a larger domain of problems by separating the logic and the data, http://www.gamasutra.com/blogs/MeganFox/20101208/88590/Game_Engines_101_The_EntityComponent_Model.php#comment76795

Code: [Select]

What do you think? Should a component just be raw data (which would mean we wouldn't even have a class... just a struct(!) Wow, that's really departing from usual "OO" ideas...!)?
Other languages have stronger ways of rationalizing data (Like SQL). All that matters is that the system is reading data in manner that is expected. You could use structs, linked lists, or tables. Having a 'Type' isn't necessary or even important. But yes- in C++, you'd most likely use a struct.

97

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 04, 2013, 10:29:47 PM »

When is each system's "update" function called, in a turn-based non-real-time game like a roguelike?

On each logical tick, we wait for input that will manifest as a player action. Once we get a player action, perform it and continue in the loop.

In a turn-based game, you typically want action-resolutions to occur on the same turn, in which case you're going to update each system per entity, instead of each entity per system. This literally just means inverting the game loop so that you do something like,

Code: [Select]

foreach(entityID:entityIDs) foreach(system:systems) system.update(entityID);
Where one of the systems is an input handling one that waits for user input.

98

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 04, 2013, 07:48:31 PM »

Instead of making an event system as a whole, you could make an event component for specific systems to communicate. The first system evaluates that something is happening, so it adds the data about it to a component. Other systems check the same component, and act upon it.

That's the whole point. Systems are the message handlers and creators. You CAN use components as flags or put flags on components for other systems to look at, but you shouldn't NEED to do this. The transmutation of component data should be enough for other systems that use that data to perform their functions properly.

A good example is a Collision Detection System and a Collision Handling System. Suppose we're in a real-time simulation that needs super-precise continuous collision detection. For that to work, we need to have a system to interpolate the physical integration of forces over time. We also need to able to extrapolate from our current orientation to the next collision that would occur within a tick. However- the physical state of our simulation needs to update for ever collision in chronological order.

A quick solution is to make these systems co-routines that yield to one another based upon an Alpha. Essentially, we would make our game/simulation a Finite State Machine of systems- or rather, system-states. We just meander to different system-states when we need to perform some modifications to the data.

As for my own question, how would you suggest dividing up the code in a component based framework? Mine is similar to the article posted earlier, without the nodes. Engines store entities and systems, entities store components, and systems reference entities they work with, making it someone key-shaped I suppose. I was originally planning to make a LogicEngine and a RenderEngine, but I'm starting to realize that I should probably split it up even more than that, such as having a separate GUIEngine from the game's RenderEngine.

Divide it according to the minimal use-case. If a system only uses X components for something, for example, you may want to split your X and Y location components up (though it's typically okay for a system to work on a position component that contains both X and Y components even if it only works on one).

The idea is to prevent the need to duplicate any data but keep logical components isolate. A position component is used by both the renderer and the physics simulator, but a force component is only used by physics- so it should be its own component. You can rationalize it further by applying multiple forces throughout components and then evaluating/applying velocity when we need to update.

99

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 04, 2013, 03:18:09 AM »

My first idea would be to make the system that set the building on fire emit an event, which would make an UnemployedPeasantSystem add an ExtinguishFireComponent to some peasant.  According to requerent, this is probably not the best idea, and it would be better to not mix event- and component/entity-based programming.

I did say that, but at the same token-- many people have a lot of success mixing them.

One thing I dislike about events is that you need to have a strong idea of what everything does before hand. One of the advantages of components is that you don't need to know anything. When you mix them, you can add events as you go along that get triggered by component systems, but you really shouldn't have to be doing this. The system should do all the event management internally.

Edit: Most major game engines (like UDK or Unity) use a hybrid type system where component systems raise events associated with those systems-- however, this is just a tool for interfacing with an engine. It's better to have the low level access necessary to make your own systems and subvert the need for events.

More generally, how do we handle updates on entities the current system is not subscribed to? Or, in a more general sense, how do we handle tasks without knowing who might handle them?

Systems only work with specific components, not entities. They should never need to know more about an entity than what is in their respective system. A component.owner sort of thing is important though, as you may want to add components to entities within a system. This is true even when a system uses multiple components of the same entity-- it's just important to keep internal references to components parallel.

Another way would be to have some kind of FireBrigadeSystem that handles all BurningComponent entities. This system would then pull all jobless peasants from the entity manager and add an ExtinguishFireComponent to one of them. This seems to be the way that Artemis for Java prefers. Somehow this does not seem right to me, as one system pulls entities it did not originally subscribe to.

Think about what an entity represents. The problem your having has less to do with components vs entities and more to do with AI.

You have an emission of information into the game world- IE, a burning building.
You have an entity sense that emission and then adopt a particular behavior- IE, a peasant begins dousing the fire.


First we need to rationalize what a building is. Are buildings discrete entities (like in an RTS) or do they contain other entities (like in the SIMs)? I'm assuming that your buildings are discrete, but it's okay if they are not. A building and/or the entities/components that make up the building might have some kind of description to indicate who they belong to, whether it's a faction or an individual.

Then we need to rationalize what it means to be burning. We'd probably implement a fire propagation system and a burning component. This will work for discrete or container buildings, as we only care that something is burning and that there exists an entity who cares that it is burning. A fire propagation system would care about the materials of an object, the objects adjacent to it, world properties like wind and humidity, and as many other things that you may or may not want to deal with.

Then we need some way to alert the AI that they need to do something about it. The question is-- How do we alert them? An emission scheme might be more complicated than your looking for, but it would basically be a map that has sensory data that is significant to an AI. If you just need to send a message directly to all entities to clean up fire, then a FireBrigadeSystem, as you suggest, would make sense.

The FireBrigadeSystem works with AI components and Burning Components. It would just match up ownership/factions/concerns with problems, and then use whatever heuristics that the AI represents to WEIGHT a goal and add it to that entity.

So-- what you can do is have GoalComponents that are attached to entities. When we get to the DecisionSystem, we analyze that entity's goals and choose its behavior accordingly. FireExtinquishingGoal might include information about the location of the fire or a reference to a burning entity, or it might just be managed by the BehaviorSystem which could do a 'closest fire' sort of heuristic. You can nest goals in a single component if you want, but it shouldn't be a big deal.

Alternatively, you can have a set of goals that describe an entity's behavior and weight them based upon emission data. This will prevent a peasant from starving to death even though he's trying to put out a fire.



I think AI schemas work most naturally with component systems- as all we do is update weights according to emissions and our entities will act in their best interest. I posted some thoughts on Sensory Systems in another thread, which got a response that briefly discusses a way of managing AI that works incredibly well with component systems.

http://forums.roguetemple.com/index.php?topic=3289.msg27242#msg27242

100

Programming / Re: Alternatives to Mana/MP?

« on: May 03, 2013, 10:32:34 PM »

I guess some more context might be helpful---

The idea is that energy is drawn or drained from the natural environment and then used to animate units not too dissimilar from marionettes or puppets. Some have a continual power draw whereas others a one time animation cost.

These animations are extensions of the commanding unit, and result in a sort of hierarchy. So something that has to do with the divine right of kings could also be good. Something where power is drawn from nature but reserved for the commanding unit.

Vigor is better for like an inner life force, but not quite what I'm looking for. I think it's otherwise an awesome word.


Thanks for mentioning google-- It's pretty good. Something like Mundus could work.

101

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.

102

Programming / Re: The Ultimate Roguelike Tileset

« on: May 03, 2013, 08:43:14 PM »

... You don't care about an exclusive font, right?  ...

Spent about eight hours over two days this week looking for an exclusive font, but it's so hard to tell if it would look good in-game before you buy them I'm still with the generic crowd

Yea- there are hundreds of awesome UTF fonts- like those native american ones, but it's hard to tell if they'd just be confusing or not.

103

Programming / Re: Ending: Adventure mode

« on: May 01, 2013, 10:49:11 PM »

The advance doors now blink. They always spawn east or west in the starting room and I've removed the bad door. This should make the objective clear now as well as adding the opportunity to kill rooms in order to escape.

Preset puzzles would not work because the player would simply execute them by rote. I've tried this already. The challenge of getting to the final door through a random maze seems to throw up more interesting puzzles for me because I've never seen them.

Sorry, by pre-generated I didn't really mean previously designed.


Whenever generating a room, you can probe its difficulty. The breadth and depth of solutions, in a general sense, describes how difficult a room will be. Since your enemies are pure reflex agents and the player has only 4 available actions, searching the state space should be easy. Generally speaking, the breadth inversely describes how 'puzzling' the room is. You may not be able to divine an algorithm to create rooms with narrow solution sets, but you can generate and toss those that are too broad and shallow.

Players tend to want long and narrow decision paths to always have some solution, even if it is sub-optimal.

Obviously, in an adventure game, we don't WANT to screw somebody if their first move is a mistake, but we can analyse how much mistakes are punished by the increased length of that solution path. Creating an algorithm to generate maps with desired properties is a very tough problem, but creating an analyzer to toss bad gens isn't.


Just a thought.

104

Programming / Re: Ending: Adventure mode

« on: May 01, 2013, 07:01:36 PM »

Puzzle mode was awesome- very drod-like.

I think you should try and put pre-generated 'puzzles' in adventure mode. Patterns that if the player misses s/he'll most certain lose. These would be more like map features that have stuff arranged in a manner that has a very limited number of solutions.


Yea, you can randomly generate small areas and put them through tests to see how difficult they are (the branching factor of solutions and the depth of solutions). Right now, adventure mode is fun, but I think it's less of a challenge and more of a 'waiting for you to trip up' sort of experience.

105

Programming / Re: pedantic object oriented question

« on: April 27, 2013, 06:16:58 AM »

I bet that if everyone puts their functions wherever they want, we'll all end up happy.

like you ask your main game loop to update everything that needs updated.

I don't have my main game loop update everything. I ask the objects to update themselves. And I don't even do it in the main game loop. The map does it.

It's a cascading hierarchy of updates.