Messages

1

Programming / Re: "Game state"-based game loop.

« on: May 29, 2013, 04:33:08 AM »

You are always gathering input.  However, when a significant input occurs, you need to act on it and resolve it.  For example, if someone dismisses a menu then your UI state must be updated as such so that it is only handled once.  In UI libraries this is commonly done by detecting the key press and dispatching a single KEY_PRESSED event.  When your code handles that event, the core game state is updated and the menu is dismissed.

When you have a continually running UI input/render loop, you no longer necessarily do logic every single pass.  Instead you might have a timer or something that invokes the logic update only once per second.

To learn more about UI states, I would study your favourite UI library to see how it does it.  For example, if you're using Java then you can study awt/Swing.

2

Programming / Re: "Game state"-based game loop.

« on: May 29, 2013, 04:07:05 AM »

OK.

I've noticed something else now: If one has the game loop like:

Loop:
   Input
   Logic
   Render

then, suppose we have to go to a menu. So the input tells the game to go to the menu state, via the "setNextState()" function. But... the logic and render phases of the loop will still execute on the main state, meaning it will try to expend a turn. In addition, when transitioning back to the main state, the game will try to get input again, and may not have done the logic for the turn (which requires the command to be done first, e.g. after dropping, then a turn should lapse, which means when the menu closes and the drop is called, we want to go directly to Logic and skip over Input for that one cycle of the loop.). How does one solve these problems?

Unless you're doing fancy animations, the logic step should only be triggered off specific UI events.  E.g., you won't advance the turn until the player actually does something (typically via a key press)

So it looks like this:

Loop:
  Input (wait for key press)
    Logic
  Render


With fancy animations a similar concept still applies:

Loop (happens many times per second):
  Detect UI input
  Dispatch UI events
    Logic
  Update animations
  Render


Note that animation state may be triggered off core state changes but, like UI state, it should be kept separate.

3

Programming / Re: "Game state"-based game loop.

« on: May 29, 2013, 03:59:44 AM »

1. Yeah, I have no problem with global variables.  There's rarely the need to add further restrictions by turning it into a singleton.

...

5. It's always good idea to keep the core state of the game (data describing your player, items, creatures, etc.) separate from the UI.  This is done by allowing UI code to read and write to it but the core state and the classes within do not know about the UI in reverse.

Generally, when a menu item is selected you will know what item was chosen.  Given the context you're in you can then directly modify the core state e.g. drop the item from the player's pack.

4

Programming / Re: Error handling

« on: May 29, 2013, 03:36:26 AM »

I use two approaches.

1. I have a record feature which will help reproduce the situation
2. In the code if I hit an unexpected state I assert out.

There's no point in continuing if you hit a state you know is corrupted and/or unresolvable.  The rubicon has already been crossed.

What you described might be similar to an event driven program.  In this instance, an exception trace is dumped but the game might be able to continue on.

However, when you start trying to fix objects I wager you're entering into the realm of madness.

5

Programming / Re: Grid-Based Lighting

« on: July 29, 2012, 02:14:13 AM »

Pretty neat.  How is your game going to take advantage of it though?  Are you planning to animate the glyphs as they move from one tile to another?

6

Programming / Re: Grid-Based Lighting

« on: July 23, 2012, 12:46:08 AM »

Full raycasting can be quite expensive assuming you need to incorporate all the tiles between the origin and the one you're checking.

A different technique, which is the one I'm using, is to represent what is visible to the player on an offscreen panorama.  For full 3D you need a two dimensional array but for 2D you can get away with a 1D array:

Initially nothing is obstructed:

Code: [Select]

0     PI/2    PI     3/2PI   2PI
00000000000000000000

If an obstacle occluded 25% of your view to the north:

Code: [Select]

0     PI/2    PI     3/2PI   2PI
11100000000000000111


You can make the array as large as you want to gain more resolution.

Next thing you do is do a spiral iteration from the origin outwards.  For each tile you're checking you calculate the angle (where in the array to start filling) and how wide it should fill (depending on the radius).

Now if what you're about to fill is already completely filled with 1's then the tile is fully occluded.  If the space is all 0's then it's fully visible.  Anything in between will give you a percentage i.e. an alpha value.  Once you determined the alpha of your tile, then you fill in corresponding area in the array with 1's if it's an obstacle.

I think this method will give you a decent FoV with anti-aliasing.  Since you are using a grid then you can pre-calculate the distances and the angles as they'll always be the same.  This is really fast too because now you only need some multiplies and integer operations and checking between any two tiles is now a constant time operation because any tiles in between have already been accounted for.

To do your grid-based lighting you store an alpha for every tile that you want to check.  Initially reset all values to 0.  Then repeat the above algorithm using each light source as a center and update the alpha value if it's greater than the current value.

7

Traditional Roguelikes (Turn Based) / Re: QuickHack Complete!

« on: July 05, 2012, 08:31:25 AM »

I was able to run the .jar on my MacBook Pro.

Took me a while to figure out some of the keys.  Tried F1, ?, Esc, etc. to bring up the help.  Then I discovered 'h'.  [edit] Upon playing again I saw the blinky text and the Press 'h' for help.  They didn't register in my mind the first time and so I would recommend keeping the Press 'h' for help visible always until the player explicitly presses it for the first time.

Selecting what skill to increase needs some feedback.  I moved the prompt to one of the skills then I pressed Enter.  Oh, the game started!  Did I increase my skill or did I waste a skill point?

I found an armband but it wasn't apparent if it was equipped or not.  In the inventory screen pressing 'e' didn't seem to do anything.

The instant feedback during combat is great.  The numbers scroll by a tad too quick imho.

Cool little game.  Thanks for sharing!

8

Other Announcements / Re: So I am Buying Diablo III

« on: June 27, 2012, 11:30:43 AM »

My biggest disappointments with Diablo III is the skill system which basically allows creating any spec at any time i.e. there isn't much of a point to creating more than one character of each class.

I'm pretty surprised they did this because considering the amount of time people spent creating and testing various builds in Diablo 2 you'd think Blizzard would want people to play more.

A lesser but related nitpick is removing the assignment of attribute points (e.g. str, dex, vit, etc.).

[edit] Another thing I miss are some of the bad-ass monsters in Diablo 2.  Remember Bremm Sparkfist, Duriel, and the oblivion knights?  Nothing remotely as difficult in this iteration (until Inferno I suppose).

Overall a nicely polished game but gets kind of boring once you complete a difficulty level.

9

Other Announcements / Party-based roguelike & perma-death

« on: January 03, 2012, 02:50:36 AM »

Given a party-based roguelike (lets say 5 characters) would you still have perma-death?  I.e. would you allow any form of resurrection e.g. mid-battle or haul the corpse off to the nearby temple?

I'm trying to reconcile the perma-death/no restore facet of roguelikes with the party-based mechanism.  With a party, the monsters and challenges would have to be a lot tougher and death of a single member would naturally happen more often as a result.

Of course if the entire party wipes then it's game over.

Your thoughts?

10

Programming / Migrating old saved games

« on: November 25, 2011, 08:01:20 AM »

I'm trying to determine if there is any feasibility to allow the player to migrate and load old saved game versions.

My initial thought is that it is pointless because old saved games will have pointers to obsolete data and some things such as zones should not be loaded back in as they were if you've added new content.

In a traditional application (e.g. a word processor) one can create simple content with limited functionality and it still makes sense to be able to load that simple content into a future version of the product.  However this doesn't really apply to roguelikes because content is often completely replaced.

Any other thoughts on this concept?  Do you know of any roguelikes that went out of their way to allow players to load their old saved games?

11

Programming / Re: Let's talk a bit about world map generation!

« on: November 18, 2011, 12:50:39 AM »

You mentioned the size is 200x200.

Is this the ideal size for an over-world map?  At what threshold would the player begin to feel that the map is too large?

12

Temple of the Roguelike / Re: Roguelike Round-up

« on: July 01, 2011, 01:15:43 PM »

Nice article, thank you!

13

Programming / Re: Slow Attack/Movement Speed

« on: June 28, 2011, 09:21:25 PM »

The problem of using min(100, points) + amt is that it breaks for creatures with < 100 attack speed e.g. a slug with amt = 50 would be able to attack every turn when it is intended to only attack once every two turns.

That's not true. It moves each second turn as it should.

Whoops, my bad!  I was thinking max(100, points)...

But there is one thing I don't like about your method. Suppose you have two monsters A and B with 150 speed, and they both start with 0 points. They will move in the following pattern: A-A-B-B-A-B-A-A-B-B-A-B-A-A-B-B-A-B. From B's point of view, A will move either 0, 1, or 2 times between each two of B's moves. Since both are of the same speed, they should alternate, right?

I agree that interleaved is better especially when it comes to movement (I have a mud background and clumped attacks is natural).  However, isn't this a case of choose your own poison?  On one hand the turn order is very defined but you get clumping, while on the other hand you get nice interleaved attacks/movement but cannot predict who will move next.

Considering that my game is tactical turn-based I am initially leaning towards the former.  I don't see how your system can avoid both drawbacks but I could be missing something.

14

Programming / Re: Slow Attack/Movement Speed

« on: June 28, 2011, 05:32:24 PM »

Oddly, I was thinking about movement/time systems on my drive home today and am working on the skeleton of a blog post.

My problems with activity point accumulators are:
1) You may need an accumulator per-creature, per-activity capability (locomotion, manipulation, sensing) which can quickly add up given sufficient NPCs.
2) They can often interact oddly with 'rest' actions, or else require complicated algorithms to determine how much surplus activity can be stored before use.

My solution is based on probabilistic tick-scheduling.

1. Primarily this is for movement rate and number of attacks per turn.  I haven't thought about other actions but I was assuming that casting spells, etc. would always be 1 action / turn.
2. I see your point here.  If I don't store surplus activity or reset the accumulator then slow monsters will end up attacking once every round and fast monsters would be attacking slower than people think they should.  Overall if I could avoid surplus activity storage completely I would.

Can you provide a few more examples with probabilistic tick-scheduling?  Overall my goal is to allow fast monsters to attack > 1 per turn, slow monsters < 1 per turn (both at non-discrete amounts), and avoid unfairness around wait states and combat openings.

My system with the modulo is still in the design stage and it's the best I could come up with so far.  I'm definitely interested in spotting flaws in it and learning about better systems.

15

Programming / Re: Slow Attack/Movement Speed

« on: June 28, 2011, 05:15:34 PM »

At the beginning of each turn, your points are calculated as

Code: [Select]

points = (points % 100) + amt

Are you sure you mean this, rather than points = min (100, points) + amt (or some other more reasonable surplus limiter)? With the modulo, wouldn't it be really difficult to predict how many attacks you're going to get on the first turn of a fight? (unless the numbers are actually visible, in which case you might be waiting a while to optimise your attack points - pity the guy with 101 speed, especially if he overshoots tho wait and loses his 200 attack points before using them)

Correct, the whole point of using the modulo is to prevent players from trying to 'stock-up' or 'hoard' points before the first attack.  The values would be hidden from the user although there probably would be some kind of indication if they cannot attack that turn.

The problem of using min(100, points) + amt is that it breaks for creatures with < 100 attack speed e.g. a slug with amt = 50 would be able to attack every turn when it is intended to only attack once every two turns.

The person with 101 speed i.e. amt = 101 will always be able to attack at least once at the beginning of each turn.  I see your point though... if he tried to hoard his unused points it would be a long wait to get that second attack and if he didn't use it then it's gone for another 100 turns.  However, I don't think that's a big concern because I'm trying to discourage this style of play.

This system could be augmented so that if you are out of combat your current points (once they hit 100) will remain at max(100, amt).  This will add some more certainty to the start of a fight but I'll have to think about it a bit more.