Messages

16

Programming / Re: How to do archery?

« on: August 23, 2013, 12:49:19 AM »

I dislike auto-switching or long-range weapon slots because there is no opportunity cost associated with using different weapon types. Why crutch game mechanics for poor UI? Swapping weapons out is a legitimate cost that a player should pay, even when it may seem to make little difference.

While it may be cool if a player could define automatic actions based upon certain conditions (for example, swapping out a ring of vampirism for a ring of regeneration when there are no enemies in melee) could be interesting, but it should never forgo the loss of a turn to do so (definitely with a confirmation prompt).



The NWN UI handles quickslots very intuitively- check it out.

Otherwise, under the player's name/HP bar, you can indicate their current weapon- colorized or however (Bow could turn red when in melee, for example). Changing the Sprite or throwing up a warning indicator is another.

17

Programming / Re: How to do archery?

« on: August 22, 2013, 04:29:29 PM »

I think that this has even less to do with melee/ranged and more to do with having multiple weapons that are desirable to use. Allowing the user to define specific load-outs and mapping them to a quickslots is a better approach. From there you don´t have to create special rules if you don´t want to. Using a quickslot either consumes a turn or it doesn´t-- if it doesn´t, then you can limit the number of slots.

Yeah, quickslots can also be a solution but if we want to avoid forgetting switching weapons, specially during large confrontations with enemies striving from every corner, changing weapons automatically should be considered. This is something I wished ADOM had when I used to play it as an archer, no to mention having an auto-arrow-recover feature, which was basically the thing that kept me away from that class, picking a dozen of arrows after battles was tedious as hell.

It´s a UI issue. The player needs to A) know that he needs to switch and B) have a way to switch that is easy.

A) is easy to solve- just make an obvious indicator.
B) is also easy to solve with quickslots.

18

Programming / Re: keep an Endless Sci-Fi Roguelike interesting?

« on: August 22, 2013, 04:21:53 PM »

Novelty is the way to go with infinite. The game should increase in complexity as a by-product of being infinite.



Some sort of arbitrary narrative that keeps things interesting. Maybe you come across multiple opportunities to retire in the form of quests.

Saving a planet from a giant asteroid, or something, might exalt your status with said inhabitants and they provide you an opportunity to retire in high class. Or you come across a paradise planet that only requires 12 payments of some such amount to acquire a time-share.

19

Programming / Re: Damn The Rats

« on: August 22, 2013, 04:18:13 PM »

Keeping all types of enemies pertinent throughout, I think, is a mark of good design.

The challenge that new enemies presents to the player should have more do with the complexity and/or number of decisions that they must make to solve the problem. It shouldn´t be about numbers unless there are opportunity costs.


So, rats, for example, may deal more damage or be harder to hit when the user is wearing Plate Mail or wielding a Great Sword. Because we´re in an area where the diversity of enemies would demand Plate Mail, Rats are now a peculiar challenge. However, in earlier levels, where there are ONLY rats, we don´t even have to think about the equipment we´re using, we just pick the best for the job. Perhaps, instead, rats deal more damage the more rats are adjacent to you and now we´re in a wide open space... there are many ways to allow the rules of the game to weave greater complexity without messing with numbers.


Furthering the vein of complexity, the challenge should emerge from interesting configurations of enemies. Certain enemies should converge to produce a challenge that is orders of magnitude greater than what either provided separately or what increased numbers would provide.

20

Programming / Re: How to do archery?

« on: August 22, 2013, 04:09:26 PM »

I think the problem that the OP brought up has more to do with UI than it does with gameplay.

It isn´t a problem for a player to engage in a realistic style switching so long as it is clearly communicated to the player that they should do so. The problem has more to do with the cumbersome process of doing so and the liklihood of forgetting to do so-- especially if you have to do it a lot.

I think that this has even less to do with melee/ranged and more to do with having multiple weapons that are desirable to use. Allowing the user to define specific load-outs and mapping them to a quickslots is a better approach. From there you don´t have to create special rules if you don´t want to. Using a quickslot either consumes a turn or it doesn´t-- if it doesn´t, then you can limit the number of slots.

21

Programming / Re: Window managers and "printing messages"

« on: August 13, 2013, 09:27:18 PM »

So would this work? I'm not sure if this is 100% in line with your ideas, but it seems it'd achieve the separation I desire (of UI and logic). One would have a distinct UI object, which can catch UI events. Buried inside the UI object is the window manager and panes. There is an interface available, which is what we can pass around -- that takes up UI events (UIEvent objects). Call it a "UIEventReceiver", for example. It might only provide a single method -- "receiveUIEvent()", for example -- and that's it.

Yea, totally.

We have the whole program as an "Application" object. Within this is a UI object and GameLogic object. The only thing the GameLogic object knows about the UI object is the interface to pass events (UIEventReceiver). Note that if we want to modify the UI to be a different kind, e.g. a graphical one instead of a console one, or to use a different set of panes, or whatever, we just rewrite the relevant parts of the UI object and the GameLogic and everything associated with it is unaffected, since it only cares about the UIEventReceiver interface and sees and knows of nothing else.

Yes.

But here's where I'm not sure if this works with what you suggest: You mention that Application passes down to the window manager, etc. In the setup I mention above, the thing that receives the UI events is ultimately the UI object. Should Application receive those events instead and store the window manager/panes itself?

When I say the Application propagates the event, I mean that logic of the game sends the event to the application, which then broadcasts it to relevant objects. The Game object doesn't have access to the references necessary to directly broadcast to UI elements, but it can provide the application with that information. In this sense, I'd consider the Application the governing intermediary... kind of like a kernel (maybe? >_<).

So, making the application headless, in the case of a server, shouldn't have any UI objects initialized. The Game doesn't know or care about that though, and still sends UI events to the application, which could then send those across a network to a remote client or something like that. I don't recommend going nuts with features that you'll never need, but I think the server-client relationship is a good way to contextualize the distinction between Model and View (relative to MVC- Model View Controller).

When the game logic wants to do something to the UI, like print a message, it sends an event. You mention "UIEvent" is "generic". What does this mean, that it has no derived types? But different types of events may require different parameters. For example, a "warning event" (which may flash the screen red, for example) may not have any parameters, while a "message event" (to print a message) must carry with it the message to be printed, and a "prompt event" must carry with it the prompt text, range of options available (yes/no, a direction, whatever), and also the callback functions to be invoked upon choosing an option. This suggests UIEvent should have derived types for each of these various kinds of event.

I think it makes it easier to develop if the Game isn't working with a wide variety of Event objects. You can make Events be the product of composition instead of inheritance by passing an array of objects that would represent the construction parameters. Usually the first element would need to be an enum or flag to indicate the type of the event.

Why subvert strong typing? It's personal mostly. "I" don't like having a large library of Events that I would be adding new objects to on a regular basis. If you can easily rationalize a finite set of events that your game would use, then it'd be better to use strong types instead.

Prompts are pure UI. They're simply a menuing schema to help the player communicate to the game what s/he wants to do. Or rather, prompts/menus help the user fill out the parameters necessary to produce a game action that makes sense. In this vein, I don't use callbacks. The Game propagates an event saying what type of situation the player is in and what range of actions are available. The UI is responsible for formatting that information in a way that helps the user select an action and send it to the game. I just don't see where there is a need for a callback (in this case). Even if the action being taken doesn't have to do with the scheduling of the game, it's still a 'wait for player action' scenario, so, again, as long as the UI knows which actions to present to the player, you don't need anything fancy. I don't see any harm in using a callback though.

Similarly, the -more- prompt has nothing to do with the game. The UI simply received too many events to display in the log, so it tells the application that it is going to consume the next input to finish displaying the remaining log messages.

Also, when we send UIEvent to the UI object or Application object (?), what should happen right there? Should it be put on a queue of some kind, and then the logic has to finish before the event can be handled (which happens in the outer "main program loop" that pumps the UI), or should it get "handled right then and there", e.g. a pane with the prompt is opened, or the message is stuck in the message buffer, or whatever "thing" the UI does in that case is done?

I think that kind of depends. Suppose you send an event for creature that moves in the player's LOS. In this way, the UI can update each move in sequence so that the actions are graphically offset. Alternatively, the event could just throw all the information at once and the UI is just responsible for updating each move in some sequence (which could be canceled by input to skip the animation, or something). The latter case is more elegant and gives your UI more control over how it presents its information. In this sense, you may only 'need' one message sent to the UI that contains all the information about how the game state changed and what actions the game will accept-- the UI can then animate that information or not, doesn't matter to the game.

In cases where there is an interruption and the game is waiting for a decision to be made, it's not really any different. It's not going anywhere while it waits for the UI to tell it what the player has chosen to do. In fact, we could have an aggregating message that builds up in the game logic until the player has an opportunity to make a decision, and then just dump it all on the UI at once.

It really just gets down to, I think, performance and preference- and each case is going to be relative.

Also, what about the non-"game" parts? That is, the main menu and player generation screens. These require different panes than the game -- but how do we handle the invoking of them? How is the UI told it needs to do these special actions, when "panes" are an internal? Is it time to resurrect the "game state" idea, but as part of the UI or the Application -- that is, the UI or Application has a number of states, e.g. "Menu" and "Game", and there is a transition which shuts down or loads the appropriate panes? Or is there another way you might know of -- especially since you mentioned in an earlier post the whole window/pane system functions as a kind of state in itself, so it'd seem redundant to have an additional state mechanism in there? What would your suggestion of a mechanism for this be?

That's what the WM is for. You make a selection to start a new character. That menu sends a message to the WM to queue up all the necessary input prompts to build the necessary parameters to pass into a new game (possibly closing itself out  in the process). The WM should manage which inputs go where.

And what about when we do the inventory screen? Though I suppose this isn't as much of a problem, since when the UI gets a command requiring inventory, it could just open the screen right there, before the game logic knows about anything. The situation would seem to be different for commands requiring confirmation prompts, like moving on a dangerous piece of terrain, since that requires some game-logicy stuff, namely the evaluation of terrain difficulty, before a prompt can be issued. I'd imagine the UI would pass such a command straight on to the game logic, and it notifies the UI of the confirmation. Or do you suggest some other way?

When the player moves onto dangerous terrain, the game tells the UI that the player has an additional action to take. That additional action, in this case, is a binary yes/no. The UI presents these options in a way that makes sense to the player, and then sends that selection back to the game. The game, on the other hand, simply popped a UIEvent and waits for the player to take an action.

Inventory screen is typically pure UI, though you could make it so that looking at inventory is an action sent to the game which then responds with a UIEvent that provides all the information necessary to present the inventory. In this case, that action doesn't consume a turn, so the game is still waiting for an action that results in a game update.

22

Programming / Re: Window managers and "printing messages"

« on: August 12, 2013, 06:18:28 PM »

Didn't read the whole thread- sorry.



There are, probably, at least 2 forms of feedback. Real-Time and Event-Driven. In a turn-based game, everything is Event-Driven.

Consider,
The "Game" is a Server and the UI is a Client.

The game is turn-based, so the server is oftentimes waiting for input before updating. When the game updates, the Server sends information to the Client, which then decides how that information should be presented to the player. In a similar manner, the UI captures the input and evaluates it at an application level to determine if it is used in the game, if it is, it gets passed to the server.


So-- a generic UIEvent is produced by the Logical Game whenever anything happens, and the Application passes that information down Window Management until something happens.

Let's say you have a 'more' prompt or a confirmation message-- that's ALL UI, it has nothing to do with your game logic.

Similarly, your UIEvents shouldn't target specific windows/panes, but should allow any Client to process that information however it wants. When you take damage, you may want the screen to flash red, the HP bar to go down, and a message in the log saying "You've been hit." The game logic shouldn't know any of that.


A server client relationship, I think, is a good way of looking at the relationship between the UI and the Game. They each have their own logic designed to work with each other, but not dependent of each other.

23

Programming / Re: Game balance and leveling.

« on: August 12, 2013, 05:53:57 PM »

Sorry, I failed to see your point here. Could you rephrase it?

I meant to say 'arguing the contrapositive,' not 'proof by contradiction' (both of which are incorrect >_>).

Otherwise, where'd I confuse you? I'm pretty much just saying that your general assertions are poorly reasoned and that I have to disagree with them otherwise the dialog may suffer.

Okay okay,

You're trying to make a game were 'skills' play the largest role in how an entity interacts with the environment (inclusive of other entities). The 'skills' paradigm is something that the player is aware of beforehand, and is able to make preemptive decisions that guide their character's development. When you take this approach, there typically needs to be a general 'resource' that the player gathers to develop skills. Either in the XP to gain levels to get skill points sort of way or in the training of specific skills. In either case, the gameplay is going to get repetitive (whereas finding hearts is intrinsically less so).

That means that you ADD the problem of repetitiveness to your game, which you now must solve by finding out the appropriate way to pace progression in a manner that is likely to result in the emergence of fun. This problem is solved by Level Design. In a Roguelike, your level design is likely to be automated. The problem of Heart placement is ALSO a Level Design issue, and one that is orders of magnitude simpler. OTOH, no XP gains from fighting also feels repetitive, so it's arguable that Skills/XP systems attempt address the repetitiveness of mundane tasks-- but in reality they may just exacerbate the problem.

The difference is really value-neutral. Trade-offs for tastes and preferences and developer skills that can all be implemented in wonderful ways.

Key point there. Everything works fine until it breaks down. You can create a game completely based on luck and still be amusing by it (Monopoly) and you can create a roguelike game with minimalist luck interaction but with tragic consequences, like having the player dying by tripping in a tree root and bumping with his head in a sharp rock. Does this means there is necessarily something wrong with this luck mechanism? You have two possible answers to give me: yes and no. Some players can find it hilarious while others completely unfair. Everything is cool as long you think it likewise. What I don't want is to play a roguelike heavily dependent in luck or loot.

Not really relevant. I provided Brogue as an example because its design decisions are evidence for my statement. Your hypothetical example is just bad design. My point--

That is to say, while Brogue is very challenging and punishing, no seed is unbeatable.

Was to say that, despite being unpredictable, Brogue can always be won. The player is ALWAYS responsible for whether or not they survive, not the RNG. The procedural content creates diverse and novel challenges, but they do NOT subvert the player's responsibility for surviving. Your example is bad because you don't get into whether or not the player is or can be AWARE of the risk of tripping and falling, and if there are any opportunity costs associated with taking that risk or not (the components that make a game a game!).

Again, not to be rude, but your example arguments are very weak representations of the ideas that you are making contentions against.

In-game-skills. Sorry for the confusion but whenever I say skills I'm talking about things you can improve your character at, like: "Skinning", "Battle Axe", "Fishing", "Casting" etc.

Sorry, I was actually just mocking you that time  >_>.


That said, I think your project is fucking amazing. I wish I had the due diligence to get something off the ground-- sadly, I have issues devoting myself to any design goals at all.

24

Programming / Re: Game balance and leveling.

« on: August 12, 2013, 03:16:45 PM »

The sensation of progress in a video game is ensured via positive feedback by modifying the player's gameplay choices in such a manner that increases the range of tactically salient decisions. The sensation of challenge tends to involve increasing the number and complexity of decisions required to overcome an obstacle.


As long as you accomplish that, leveling/scaling is arbitrary mathematics that demands a lot of design effort that is arguably wasted. Players will always tend toward the exploitation of whatever rules will unlock the most interesting range of content. The difficulty of a RL oftentimes demands this sort of optimization. Players won't play in a style that they find interesting, but in a manner that works. Features that do not converge with this goal are ultimately superfluous novelties that overwhelm new players with bad character development decisions.

I think, generally, binary empowerment and increased complexity of challenges is a better way to look at your balancing. Even if you are scaling, that extra 10 HP from leveling has value only relative to the number of hits that you can take from other enemies. All this represents is a buffer that provides you with the opportunity to make more decisions which then become a necessity as the difficulty increases.

y, 20 heart containers, just generate 20 appropriate randomized dungeons in randomized locations and put the heart at the end.

If you wanted to, you could even add items like the hookshot and tie progression through the game to them.  All you need to do is put the hookshot in one of the tier 2 dungeons, and make sure that you can access tier 1 and 2 dungeons without it, but require it for some of the later ones.

Mage Guild is a traditional-style roguelike in most ways, but character growth is based on finding power up items the game spawns in the dungeon.  It works really well.  Try it out.

That's exactly what I was referring to. You need scripting things up to implement wire_hall_medic's method, which begins to break dynamism. I don't want to have a world with exactly 20 heart chests but generating a world where heart chests have X probability of spawning. So in the end, I could have a world with 0 to 20 heart chests (roughly speaking).

Break "dynamism?"? That's kind of a lofty and baseless assertion. You seem to want the player to have certain expectations for progress, but your proof by contradiction doesn't address that at all. Firstly, you would always use a probability distribution to ensure that a mechanically significant feature in a game spawns. Secondly, you can influence their generation in a manner that doesn't require the player look under every rock to find them but may punish players for not pursuing the necessary empowerment for certain challenges.

Whether you're spawning hearts or monsters that give XP, the only difference is a certain degree of inherent arbitrary repetitiveness, of which the latter is more inclined to provide than the former.

edit: What about a "skill" system doesn't also "break dynamism" in the way you're describing?

But even if I add specifically (scripting) 20 heart chests spread all over the world the results won't be the same as found in Zelda game, because in an open world the player will roam at will without following a certain path, making the chances of finding all heart chests in a huge world, next to zero, while in Zelda your path is incredibly scripted, making your character develop itself in predefined way set by the developers as they know that the player will find the 20 heart chests at a certain milestone. Sure you may have at some point in Zelda game the choice of following path 1 or 2 but all is heavily scripted and taken into consideration just to make sure that in the end the player's party has a certain measurable power to face the last boss with a proper difficulty level. I'm really not fond of RPGs-on-rails nowadays.

Those hearts are "designed" into the level. The whole point of procedural content generation is to automate the level design process. If you want to capture the designed sensation of a Zelda game, develop algorithms that do that. You're narrowing your perception of the possibilities with not-so-good examples.

If I was to implement characters' power level based on loot in my game, its game-play would be completed ruined as I would need to add the right amount of loot (scripting). Even with the "right amount" of loot, the game's difficult level would remain inconsistent because the player could be lucky finding too much too early or unlucky and not finding nothing at all even after long periods of game-play. The only solution for this would be: scripting, which could destroy the surprising factor during exploration.

You really need to play some Brogue: https://sites.google.com/site/broguegame/.

There was a contest match recently where no weapon spawned apart from the starting dagger and people still managed to win. That is to say, while Brogue is very challenging and punishing, no seed is unbeatable. Lucky and unluckiness are, a lot of the times, relative. When they aren't, there's nothing necessarily wrong with that.

Sure I could solve this problem by spawning the right loot only after a certain level or after a certain amount of game-play time, but this also means that I would never be surprised in finding occasionally great loot. Skyrim has this method, I mean loot quality completely bound to the character's level. It works well I might say but skirim is skill based and loot based. However, this method does bring the inconvenience of me predicting the loot type, I know for instance that a dwarven type armor will not appear until my char doesn't reach level 12.

Or you could solve the problem in a way that doesn't contradict your design goals.

I want my game to be skilled based. Not only it feels more realistic but also avoids the player relying on luck to find that exceptional piece of armor or weapon to ease down the game's difficulty level.

"Skilled based" as in, the player's progress depends upon their skill at playing the game, or at their skill in deciding which up-arrows to push on a character sheet?




Sorry to pick on you a little bit, but there's a lot of defeatism in your post that explicitly contradicts many of the reasons why people develop RLs in the first place.

25

Programming / Re: Persistent world? Yes or no?

« on: July 28, 2013, 11:49:38 PM »

It depends a lot on the setting. If the player represents an expression of a society more so than an individual character, then persistence is fine. Especially if dungeons are also "players" that change to express the hellish nature of influential energies (or something).

26

Programming / Re: Persistent world? Yes or no?

« on: July 28, 2013, 08:09:56 PM »

This is all nice but also feels like exploiting. When you die exploring a certain area you will unconsciously carry this knowledge to your next character, i. e. this will let the player prepare his next character accordingly to that specific area containing a specific type of danger that could only be dealt in a specific way.

I don't see it as exploiting at all.  If you discover that thrown potions can function as weapons on one character, are you exploiting if you use that tactic on future characters?

The player will always have access to information their avatar "shouldn't" have.  It isn't a problem and there's no reason to worry about it.

That's a difference between universal mechanics and generation specific details. If you've already played a particular Seed before and know what to do, it is cheating.

27

Programming / Re: Nausicaa Engine

« on: July 28, 2013, 08:08:02 PM »

Good question, maybe something like this? Just wrote this up on a whim.

Code: [Select]

======== Application Layer =======

Manager
- Logically manages UI elements relative to a given schema.
- Useful for:
Manages the state of the application
Initial propagator or consumer of input
Propagates UI events
Functions as a window manager

Scheme
- The type of UI to render and input to receive, a logical I/O context.
- Useful for:
Logically unify platform backends (Mobile, Web, PC etc)
Typically separate schema for input and output
Captures platform specific input or propagates to the application
Determines how panes are rendered and interacted with

Platform
- The actual I/O context, platform specific backend.
- Useful for:
Deploying on multiple platforms (DirectX, SDL, Console, iOS etc)
Abstracting differences between platforms
Simplifies porting of applications

Pane
- A GUI element that communicates feedback to the user.
- Useful for:
Managing discrete I/O interactions
Abstracting different types of UI with content
Capturing UI events


======== Game Layer ========
Model
- A pure data representation of the game, a game state.
- Useful for:
searching the state tree for AI
serialization for saves and replays
replication for networking

System
- A stateless and pure function that evaluates the game state, modifying it agnostically in some way.
- Useful for:
Isolation of logical interactions
Test-driven development
Maintaining fidelity amongst interactions

Entity
- A key for a list of components stored in a database as represented by a game state.
- Useful for:
Simplification of interactions
No limiting inheritance hierarchy
No confusion as to how entities should communicate
A configuration of components IS the "gameplay entity," the 'key' doesn't matter!
Simplified state management

Component
- A set of isolate data corresponding to some System(s) aggregated as an entity.
- Useful for:
Isolating salient interactive elements
See 'System'

Ancillary
- Object used by system(s) with which to communicate to the application layer.
- Useful for:
Propagate events to the UI for arbitrary feedback
Query the game state to evaluate the validity of a mapped action
Manage special feedback mechanisms, ie Cameras (which are part of the UI)
Manage special effects that may update per frame, rather than with game logic
Manage external libs, such as an oop physics engine (a system writes changes to the state)
May not be stateless, but game logic shouldn't depend on its state
Also used by the application to serialize the state
Manage networking and other forms of communication
The idea is pretty straightforward. Logically isolate everything as much as possible such that it is trivial to replace, remove, or reconfigure any aspect of the program.

The "Game" is just a set of stateless systems that act upon and modify the Model, or a game state. Game states are easily hashed, serialized, replicated and otherwise insanely useful for data management (such as networking, saving, replays, etc). The Model, of course, is just a database containing entities which are just keys for sets of components that represent a salient actor within the game. The Model will also contain some other details, like the current tick and the seed.

Some of our logic may depend on foreign libraries that don't immediately seem to fit into our wonderful world of stateless systems and pure data game. For these, a system may defer logic to some foreign process. For example, say we're using Bullet. Bullet is very OOP, isn't easy to serialize, and isn't stateless. We can use an ancillary object to manage the physics simulation, but we're still writing data to/from this ancillary via a system. Particle effect management, sounds, cameras and some other logically arbitrary but essential feedback features that have logical components can also be managed by ancillaries. Ancillary comes from the latin ancilla, which means slave girl. These bitches also send UI events to our application so that it knows when to draw things. The UI can use an ancillary to query the game state to determine whether an action is valid or not. These gals really just manage how the logic of the game communicates with the UI. The nature of the component-based system will necessarily promote the isolation of ancillary features into separate and unique objects- so it's kinda convenient.

Now, how does an ancillary actually query the game to determine if an action is valid? If the relevant system with which we are querying for is broken up into subroutines, we can easily use some of those routines to check it out. We can even duplicate the game state, run it through the system with the action appended and check to see what sort of UI event that system throws to another ancillary. It really just depends-- but it should probably be a chunk of specialized logic to test the validity. You may not also 'need' a querying technique. For example-- if you walk north but there is a wall and don't want the player to lose a turn, the system just bubbles a UI Event (via an ancillary) and returns to the system responsible for catching the action. If you equip something in a place that isn't valid, some checks should fail and the system can throw a UI event. The main issue here is that we want to know pre-emptively if it will fail so that we can more directly communicate to the player what they're doing wrong; however, if somehow a command gets through that isn't valid, the System shouldn't allow it. The ancillary cannot be performing game logic, it's purely a UI greaser.


So now we get to the actual application. First we have the platform we're running on. The Platform is represented by a set of interfaces filled out by native code. SDL, for example, will do the actual drawing, but we don't want to make calls to SDL because we want the freedom to drop, say, DirectX or even WebGL in as a backend. Easy, just fill out the interface and link for distribution on that platform. The logic of our UI, Application, and of our Game are not at all influenced by the platform.

Schema are logically distinct UI systems. Say our graphical interface is tiled like a traditional Console. That is a logical object, not a graphical or platform dependent one. The Logical console consumes drawing requests and sends them to some platform for rendering via an interface. You'll typically only have one input scheme, since the input needs to be rationalized by the platform code first, and all the input scheme will do is provide a mapping from platform to application actions (or rather, communicate platform 'intent' to the application). The output scheme could vary between desktop and mobile (which needs to be optimized for a small screen), but if you design it with mobile in mind, the differences could be really marginal.

From here we have a Manager to deal with Panes, focus, and determining how and where to send input. Panes contain formatting information that is drawn to the screen in a manner that is consistent with the logical output scheme. You probably want any pane capable of reacting to any UI event. For example, a camera pane may flash red when you're avatar is struck by an enemy, just as the health bar will tick down and the message log updated. These can all use the same UI event to update, just interpreted in different ways.

Panes serve two purposes relative to the game logic, helping the user format input in a way that an ancillary can use to validate, and evaluating UI events sent from ancillaries to update the screen.


And that's more or less how I'd structure a video game application. The only events that really occur are UI events, because everything else is communicated directly to where it needs to go. Input is passed from platform, to application, to logic, but I don't know if I would call that an event exactly. You could do input events also, but typically only the focus pane or the manager will be catching it, so you can just let the manager defer the input command.

Where does the query code and modification code reside, and how does the UI have access to it? It's definitely logic code. I assume we can put it in a System, even if it's not the "usual" kind that runs every step. Does the application/GUI layer know about the System being used? I guess what I'm saying is that I somewhat dislike that the application layer is so aware of the game's internals

Yea, the application doesn't need to know anything about the game. Input is always a logic activity, but since input is meaningless without feedback and may target the application first, the application needs to decide what to do. Don't get overzealous with systems though, they're purpose is to modify game logic, nothing more. If something sits between the UI and the game state, like a query, then create a managed and isolated area for that to take place (an ancillary).

It's also not inappropriate to manage Systems as an FSM instead of iterating over each of them for every game action. In this way, each system is a sub-routine that can be switched to if the prior system necessitates it. For example, the ticking system that progresses the state of the simulation forward may defer to subroutines to handle gas and fire propagation, and other things like that.

Also, you can make your entire application use a component based entity system, but I haven't considered a way to rationalize that. In a way, Panes are like entities and Widgets are like components, but the states of these objects aren't of logical importance, so it's kind of pointless. Use OOP to run your application, and CES to manage your game logic.

I wonder if there is some nice halfway solution, where the application layer is a bit more decoupled from the game logic itself, but you keep this querying, which is definitely less involved than a bajillion events going all over the place for the smallest action...

KISS. Hopefully you can see how an Ancillary object could figure this out in an isolated manner.

Ooooh, using a plain dict would actually be really lightweight and cool! Do you have any particular opinion on the relative merits of Entity Systems over just Component-based Entities (which allow game logic within components/entities)? I feel those would be better adapted to games that aren't real-time. At least the class-based design may accommodates both?

All game engines (that matter) use hybrid systems as opposed to pure OOP or pure CES.

An entity is a base class with virtual event handlers for every possible game event.
Components can be applied to entities, which are then managed by a system.
The systems modify relevant components and produce events for entities to handle if they want.


While this is VERY easy to understand and use, it results in HUGE amount of obfuscation. Why? Because it can be very confusing where game logic should actively reside, and it can be difficult to find where game logic is actually taking place. You also lose the ability to serialize and replicate without extra work, and you sacrifice the fidelity of game states, making it difficult to search the state space. If you're working in a group, it can be tedious to manage where logic should actually go.

Also, if you don't mind me asking - where and how did you learn all of these these things? You seem to have very clear ideas on most of these issues, which is great

Uhh... I guess when I first taught myself HaXe, it forced me to think about programming in a more modular way. HaXe is a language designed to translate its code into code for many platforms (C++, Java, JavaScript/HTML5, AS3, emscripten, C#/Mono, etc). While this is wonderful for logic, there is always platform backend specific issues that you have to keep in mind. I just begun naturally thinking about how to make all of the elements of my programs interchangeable, so it would be easy to drop-in different renderers or input schema.

I've also worked with some of the bigger game engines, so I've had some opportunities, out of necessity in some cases, to extrapolate their overall design. They are functional, but I don't like the overall approach. Independently I began researching CES, but there aren't very many programming paradigms that allow you to utilize it as efficiently as possible- specifically, you're just pretending to be data-driven while actually in an OOP paradigm. A lot of tutorials and documentation talks about Components and Entities as classes, but I think this is wrong because now every single type of component needs a specialized hashing method, extra work to register them with systems, which now also must be objects, which makes it less obvious what your memory footprint will be-- it's just... like programming a GUI system, which every programmer should hate >_<.


Anyhow-- the question got me thinking about what I actually do, because I haven't really thought about it explicitly before. Other people will have their own approaches, just find what makes sense and works for you.

28

Programming / Re: Races and roles

« on: July 27, 2013, 11:50:23 PM »

So are you looking to do something like this?

(Race <---> Culture ---> Locale ---> Parents <---> Apprenticeship) <---> (Events)

Race: Species, special traits, abilities, size, weight, sexual dimorphism, propensities (chance to 'be a natural' at something they've never tried before).
Culture: Highly valued skills are emphasized in education, games, and lifestyle.
Locale: A subset of culture, whereby special demands of the land and interactions with inhabitants further specify what sort of exposure an individual has to certain ideas.
Parents: A player is likely to be more exposed and knowledgeable about things that his/her parents specialize in.
Apprenticeship: The occupation that the player trains for throughout young adulthood.
Events: Special events that provide additional unique context to the origin story-- such as being cursed by a witch, inheriting an heirloom from a distant uncle, or being captured and tortured by goblins as a young child.


If you could describe your plans as a simple formula, how would you do it?

29

Programming / Re: Nausicaa Engine

« on: July 27, 2013, 09:11:37 PM »

• Press "e" key for equipment.
• Go through the GUI elements in postfix ordering. None of the sidepanels (health bar, message box, etc) capture this, but the game display GUIPanel does (This panel will also capture arrow keys and convert them into movement commands).
• The game display GUIPanel accesses the HumanView and creates a new equipment screen, based on the Hero's inventory and equipment components.
• The GUI would then send an EquipEvent with all required data, and an EquippingSystem would receive it and do its magic. Also, the message box GUI element would also receive this event and write out a message saying you are equipping said item.

How would you implement this without events? I feel you'd need to have the GUI equipment screen explicitly keep track of the equipment system and of the message box, or have game logic within the GUI. On the other hand, what happens if you try to equip something that's too heavy? You send the EquipEvent, but then that's supposed to fail... should the EquippingSystem abort the event? Should there be EquipSucess or EquipFail events? On EquipSuccess, it might make sense for an EquipBonusSystem to update armour values, etc etc in some other component?

• The ControllerSystem tells the Application that it is ready to receive an action via human input.
• Player inputs command, which is first captured at the application level.
• If it maps to a potential game action, we open a UI screen that prompts the user to fill out the parameters for that action (or not, if there are no parameters).
• Once the action has been properly prepared (or for each subsequent selection), we query the gamestate to determine if the action (or current selection) is valid (the UI may pre-empt validity tests, such as graying out options).
• The query will reply with information regarding the action's validity and create a UI event, to be caught and handled however/wherever.
• The validated action is then returned to the ControllerSystem, which then modifies a corresponding component to get acted upon in a relevant way by some other system.

The UI is sending a direct and explicit message to the game- there is no event taking place. All the UI is doing, relative to game logic, is mapping some sequence of input to an entity's action. There is no event created when you tell the entity to perform some action- it's a direct request (message) to change the game state. All the UI is used for is filling out the function parameters, so to speak. Now, it's appropriate to keep the UI interchangeable, so the game should produce UI events that can be caught and handled in whatever way they want, but that's a one-way relationship.

Also, what do you mean about using classes for components/entities being unpythonic? How else would you do it?

Data structures. The entire game state could just be a data structure whereby each entity is a key and each component is another data structure. You don't need types or functions in either entities or components so you shouldn't use classes. Your game state is just a bunch of nested dicts and your systems are just pure functions acting on those dicts.

A game is just a database with processes and a UI.

30

Programming / Re: Nausicaa Engine

« on: July 27, 2013, 04:53:59 PM »

Is there a reason why you've implemented components and entities as classes? It doesn't seem pythonic.

Event systems at the GAME level can easily run counter to entity-based component systems. Each system is essentially a pure function that, given a game state, acts upon that state in some particular way. Application Events are wonderful, but Game level events with components really shouldn't be necessary. The whole idea of components is that only relevant elements of entities interact with one another. At what point should events ever broadcast between systems? They really shouldn't. You can modify the state of an entity so that it will be acted upon in a particular way by a subsequent system, but there is no event objectification here. You should be sending messages to other systems through the game state as a change of the game state. There are plenty of hybrid approaches, but if you're going close to pure (meaning your entity has no properties apart from components), you might want to delay the development of game events, as you will likely find that they aren't necessary. If it's simpler for you, of course, go for it. Do what feels right.

Thanks for the input (hah, no pun intended)! That actually makes a lot of sense. I think as far as my HumanView and GUI is going to be concerned, input is still going to be input events - not game events. So I'll be clicking places, opening screens, and the main screen will eventually capture (e), open the inventory screen and so forth. What the inventory screen is going to do is simply launch an EquipEvent, which an EquipmentSystem will consume.

I'm still not entirely sure I agree that drag'n'drop are game events. I feel they are still GUI events, but the problem is that upon a mouse-down, you need to check whether it's actually mouseDown or a mouseDrag event... so I might need to wait, say, 0.25s until I send the mouse-down event. If in the meantime the button has not been released, then I start a mouseDrag event?

Don't put a delay in for dragging. If the mouse is down when the mouse moves, it's a drag, otherwise it isn't. In 99% of all cases where you could either drag or click, there will only be one meaningful form of input-- as long as your GUI is designed well, you shouldn't need to obfuscate the difference.

No input should ever be a 'game' event. The 'game' is sent input through the GUI. The GUI is the I/O manager. It's whole function is to handle input events and provide feedback. When your UI catches an input bound to a game action, then you can do a game event.