Messages

1

Programming / Re: well well well - three holes in the ground. How to combine tile graphics?

« on: August 05, 2015, 12:21:12 AM »

Good discussion. 

Ill have to think harder about marching squares.  I tried a method of dividing the tile into quadrants and considering each of the neighbours to those quadrants and then programmatically assembling each tile from different quadrants.  But I started to go insane, so I stopped short.  But maybe Marching Squares is what I may have been reaching for?

My artist simply proposed that I make a dozen or so pre-fab areas of various sizes and shapes and he would make beautiful unique images for each one that I could simply slap down in the right random locations.  Along with randomly sprinkled single holes.  This idea also has its appeal.  If I have enough pre-fab shapes, it will be random enough to provide the tactical variety I require, and also some visual variety as each image will be unique.

2

Programming / Re: well well well - three holes in the ground. How to combine tile graphics?

« on: July 23, 2015, 10:47:19 AM »

Hi Pol - so you just went and drew 46 tiles.  impressive.

What is the algorithm for working out what tile to show? 

I thought of assigning a number or 'weight' to each tile surrounding the tile to be identified:

1       3     5
10     -     50
100 300 500

and for each tile that is a hole, add its number to a unique total and have a hashmap of totals to tileIds.

i.e. if   tiles   1, 5, 50, 100 and 300  were holes, the total is 456   which would be one of the keys in map which would return the correct tileId.

Simple to code, the pain is just creting the 46 key/value pairs in the map by hand .  ugh.

3

Programming / Re: well well well - three holes in the ground. How to combine tile graphics?

« on: July 22, 2015, 11:46:03 AM »

Hi Krice.

huh, yeah, I didnt think of that.  Make the hole tiles totally black you mean, and then change the floor tiles around the hole tiles to include edging.

hmmmm.  thanks!  Ill look into that.  It doesnt sound any more complex than the wall code, in theory.

4

Programming / well well well - three holes in the ground. How to combine tile graphics?

« on: July 18, 2015, 01:22:59 AM »

Hey.  In Dungeon Bash, I have various terrain that overlays tiles and his different effects.  One of these is a hole.  i.e.  you can see past the tile, but it only counts as moveable to a flying creature.  To non-flyers it is impassable.

Currently when there are a bunch of tiles next to each other that are holes, the game just shows a single hole for each tile.  What Id like to do is show one big hole in an area where there are multiple tiles next to each other that are of type 'hole'  this would look much more impressive.



In this example, there are two tiles next to each other and I show two holes.  Id rather show one bigger hole across both tiles.  In some areas I have much larger hole areas and some areas have randomly placed holes.

I sat down to draw some pictures of different configurations and realized it was a lot of work - there are a LOT of configurations.

So I was just wondering if anyone had already done this work for me?  IS there some thread or images out there that are related to solving this problem that I can fastrack, or am I on my own?

cheers

5

Early Dev / Re: Dungeon Bash alpha test released to IOS and Android - free to download and play.

« on: June 10, 2015, 02:50:36 AM »

Just a quick word to say I have done a few releases since my last update.

The game now has stealth play, powerups, and a tutorial mode!

Go to www.dungeonbash.com  to download it.

IN THIS RELEASE (A17-I15)
- added Power Up screen between levels where XP can be spent on upgrading stats and buying extra abilities.
- Added new abilities for characters to purchase with XP
- modified map generation to create more tactically interesting levels.
- changed help menu to have tips that aren’t covered by the tutorial.

IN THIS RELEASE (A16-I14)
- Tutorial mode finished.
- Fixed save/resume game bug introduced in (A15-I13)
- Changed help menu to have tips that aren’t covered by the tutorial.
- Made earlier levels bigger.
- Make all levels have varying sized rooms and bigger maximum room size.
- Exit will always appear in a room, never in a corridor.
- Improved side-swiping tabs.

RELEASE (A15-I13)
- Random party choosing screen
- Tutorial mode! (half finished).
- Pressing pass while in leader mode passes leadership to the next character.
- going down stairs while in leader mode passes leadership to the next character
- pressing solo no longer auto-activates leader mode.
- fixed save game bug when some characters have gone downstairs

IN THIS RELEASE (A13-I11)
- STEALTH:
- light levels in the dungeon now reflect detectability of that tile for stealth purposes - the light level is an indication of:
   a)  torches - actual light that makes it easier to be detected.
   b)  monster detection skill - shows how well each monster can detect enemies in its vicinity.
   c)  monster attention.- characters attract monster attention, indicated by lighter tiles around noticed characters, and those closest to monsters attract more attention.
- rocks provide good stealth bonus for medium creatures and great stealth bonus for small creatures.
- hidden characters get an ambush bonus in the form of 3x attack skill for one melee attack.
- characters automatically hide when they descend to the next level, although they may be discovered instantly.  Their first action still gets an ambush bonus, however.
- the ‘stealth’ button will be deactivated if the character is unable to hide.  Hiding takes one turn and gives a slow bonus.
- any action other than normal movement reveals a hidden character - the character must ‘unhide’ to charge, but the charge still gets the ambush bonus.
- melee damage is a little more dependent on skill and less dependent on hit-points.
- creatures without hands can only carry one amulet.
- inventory tab shows capacity when selected.

6

Programming / Re: Shadowcast Java algorithm

« on: March 23, 2015, 10:14:36 PM »

dungeonbash uses quite a small number of tiles in its viewport: 11x11.  5 tile radius

To get around the symmetry problem, it (pre) calculates rays for a 15 tile radius viewport - this effectively increases the 'resolution' of the rays within the inner 5 tile viewport.

i.e. for a 5 tile radius viewport,you are tracing from the centre of a square out to 11 rays on each side of the square = 44 rays, more or less.

For a 15 tile radius viewport, I am tracing from the center of a square out to 31 rays on each side of a square = 121 rays.  BUT, I dont need to go all the way to the edge because I am only interested in a LOS radius of 5 tiles, so once I get to edge of the inner 5 tile radius, I stop tracing along that ray even if I havent hit anything.

Since I am tracing 144 rays within that 5 tile radius inner square, the 'resolution' is quite high and you get perfect symmetry and can see into corners without any special code.

This results in a fairly forgiving FOV, because the resolution of the rays is quite high, but I dont mind that for dungeonbash.

7

Programming / Re: Programming graphical effects with delays

« on: March 23, 2015, 04:42:42 AM »

Hi.     In terms of this discussion, I reckon separation of UI from game logic/data is a given.   The UI listens for changes from the model that it needs to reflect on the screen.  Gievn that, whats the basic difference of 3. from 1. and 2.   then?  Is it simply that option 3 does neither of the things that option 1 or 2 does?

I'm not quite so sure it is a given.  At least, there is a substantial difference of degree.  In case 1, the simulation halts, not for lack of input, but for display purposes - that is tight coupling.  Case 2 is much better, but.. it evidently does not give the view enough information to work with and/or the view itself contains insufficient logic.  There's been a few other methods pointed out in this thread and some of them have a significant degree of coupling.  When I say coupling I mean, can you change the model's simulation without breaking the view, and vice versa (if you can't it is tight coupling). 

A client server or similar approach (strict MVC/Visual Actor/perhaps MVVM), delivers a restricted snapshot of the simulation state to the client/view in some intermediate form (interface) that does not expose the inner workings or details of the simulation.  The view then decides what to display and how to display it.  The model neither knows nor cares about animations, nor any visual effects that do not change the state of the simulation.  As far as the model is concerned it could just as well be feeding a telnet client or an AI bot. 

This puts a substantial burden on the view (or client), it needs to run its own simulation, granted of a greatly reduced scope, in order to make acceptable, desirable, decisions as to what  to display, where, when, and how.  It is quite a bit of work and as far as I am aware, only a few AAA's go to the extremes.  If done right it does pay off over the long haul. 

Honestly, for roguelike games, I'm in favor of Xan's #2 'fire and forget' solution, perhaps with a bit more 'smarts' built into the view.  It is basically a 'dumber' version of a full fledged client-server or separate actor model.  Otherwise you're headed where a friend of mine, a professional indie dev is - spending 99% of your time and effort on graphics, 1% on game logic.  I guess that's what rogue lites are trying to be though so it depends on what you are aiming at.

OK, I understand.  I think the main concern with model/ui separation is that there is no UI code in the model, no model logic in the UI, and the model is not directly dependent on the UI.   (i.e. the UI observes the model).  All of the options in that previous post can still accomplish that.  In option 1) the model fires an event that a listening UI can turn into some animation or other, and the model then waits for an event to come in that says its OK to continue.  That callback event comes from the UI, but the model isnt aware of that.

But anyway, each of those 3 options seems to assume that the model is turn-based and its the job of the UI to turn a stream of turn-based events, by scheduling and queueing, into a sensible-looking UI in real time.  Which is exactly what I did and much regret.  That bolded part is doable, but difficult.  I guess its basically writing a synchronous system (turn-based model) and an asynchronous system (realtime UI) and trying to moosh them together. 

If you make your model inherently asyncronous and event-driven in the first place, as you would for any realtime game, then it isnt going to be too much more complex than a turn-based model anyway, and the pay-off is it lets you get away with a very simple UI layer that jsust dumbly reflects the current state of the model at all times. 

8

Programming / Re: Programming graphical effects with delays

« on: March 22, 2015, 11:45:43 PM »

3) A visual actor system that works with the rest of the visual presentation to the player independently of game logic and data: the visual aspects of the game are maintained separate from any game logic code; the visual actor system simply listens for game events that it is interested in and makes decisions about what animations to start, queue, replace, skip, etc.
Pro: Far more flexible than the alternatives.  Can be much nicer looking.
Con: Much, much more complicated and prone to subtle bugs.  Hard to determine if the visual state accurately represents the logical state of the game.
Examples: none that I know of.

Another name for this is the client server model.  There are quite a few examples out there, whether or not any qualify as roguelikes by today's definitions I have no idea.  I'm not aware of any that are called roguelikes.  The primary advantage of this approach is clean separation.  SOLID, SRP, encapsulation, all 'best practices' in industry, at least according to some, are all satisfied in this model.   

Not sure if the extra work involved is worth it for a roguelike game.  Depends on whether you plan on doing a single game, a series of games, or a series of enhancements to an initial release.  The longer the lifecycle, the more you benefit from lower maintenance costs.  Its definitely not worth it for a 7DRL, or for a 'throwaway' that is released once and never significantly enhanced.

In this issue, you're probably best served by forgetting that you're doing a roguelike and looking to modern turn based graphical games for examples.  It basically isn't a roguelike problem.

Hi.     In terms of this discussion, I reckon separation of UI from game logic/data is a given.   The UI listens for changes from the model that it needs to reflect on the screen.  Gievn that, whats the basic difference of 3. from 1. and 2.   then?  Is it simply that option 3 does neither of the things that option 1 or 2 does?

9

Programming / Re: Programming graphical effects with delays

« on: March 21, 2015, 08:01:44 AM »

I would highly recommend it - a turn based model that queues and waits on real time animations is one of those 'how hard can it be" things that  seems simple at first, and then the further  you go and the more things you want to do , the more it drags you down into the mud, and you curse yourself for not taking the time to get it right in the first place.

10

Programming / Re: Programming graphical effects with delays

« on: March 21, 2015, 05:52:04 AM »

I'm wondering what is the best way to resolve complex game interactions each having their own graphical effect that takes some time to complete.

For example if you hit a monster, then they get knocked back and then cause an explosion that damages each adjacent tile. I'd want to calculate everything that happens here in one algorithm but then play out the different effects visually one by one.

I could store the original game state then calculate all the interactions and then send them back to be played one by one, but it seems a little bit unwieldy. How do other people do it?

Hi.  My game is www.dungeonbash.com  and I implemented it the exact wrong way.  For whatever reason , it was decided that the game model or engine would be turn based, and these events and their completion callbacks would be communicated to the presentaton layer as a stream of events and let the presentation layer queue them in an animation queue to play out. 

I cant stress strongly enough that this was a bad idea and if you have started down this path, pull our now before its too late.

It means you have a bunch of state that is turn based in your model and another bunch of state that is realtime in your presentation layer (making it much more complicated than it needs to be), and these two systems have to communicate in a more complex way than needs be, and there is quite an impedance mismatch there there as well between these two complex systems.

If you have a game with realtime animations and such then make a real time model.  Sure, the player and creatures might take turns, but in this context, they are real time turns where an action just happens to be walking from one tile to another, or making an attack or whatever. 

If I wrote DungeonBash again, it would be so much easier to construct and maintain if I:

1) made each and every entity in the game model (creatures, explosions, whatever) its own rigourous formal state machine that independently and asynchronously responds to events from other entities in real time.  the fact that a lot of these events tend to happen on what the player perceives as 'turn' boundaries is irrelevent to the model.  The model is a collection of indepdent entities that communicate with each other via realtime events no concept of turns at this level.

(consider the pros and cons of using an event bus which is another discussion in itself)

2) make the presentation layer as thin and dumb as possible.  Each presenter just reflects the state of the entity it represents in realtime with as little state in itself as you can get away with.  None would be ideal.

3) state transitions in the entities in your model that require time to play out are timed in the model - it doesnt require a callback from the UI to tell it that an animation has completed.  Rather, the UI dumbly mirrors the state of the entity and configures the animations to complete at the specified time.  i.e.  the model fires an event for its UI that says - I have transitioned to this state, and I will be in it for exactly 800ms.  The UI then dumbly takes that event, and starts playing the appropriate animation to complete in 800ms

11

Design / Re: Player goals within roguelikes

« on: March 18, 2015, 11:01:05 PM »

I`m not a fan of quests, mid-bosses and other cRPG tropes in roguelikes. These could work if properly randomized but not always are, especially quests (old Sid Meier`s titles - Covert Action especially - did it really well). I`m playing lots of ToME at the moment and this is my major complaint about it - the "goal" structure is rigid, you always end up doing the same things, know where and what the midbosses are and don`t even bother with the lore scraps anymore.

Actually, this whole discussion and others I am having is bringing up some really interesting points to consider.

One is time-pressure - both carrot and/or stick.  What part can it play in roguelikes.  I just realized that food is one such stick in a lot of games.

Another is the nature of the mini-bosses.  In dbash at the moment, monsters are pretty predicatable in that they come at you bro.  Its usually the player team that is trying to setting up defensively with choke points and behind terrain, and using ranged attacks to pick of hordes as they advance before committing to melee etc...  and thats fine.

But mini-bosses could actually sit on the exit and try (somehow) to set up their own defensive position.  Thus turning the tables forcing the player team to be the one that has to be on the attack.  Anyone seen 'enter the dragon?'   

12

Design / Re: Player goals within roguelikes

« on: March 18, 2015, 06:52:16 AM »

When you boil it down, the itch that players are scratching is progression.   Sub-goals make progression more visible and immediate - they give the player points of reference for how far they have progressed and something immediate to focus on- people arent very good at staying focussed/interested in long term goals.

In Dbash, I dont think having permanent mini-bosses is such a problem because although the obstacle will always be the same, the means to over come it will be different, because dbash gives the player a randomised team of three different characters, each with different capabilities.
However, you did just give the me the idea of mixing up the rewards.  Perhaps I could have a bunch of different rewards, each made of 4 pieces that must be collected from mini-bosses, so that when you progress to the final battle, not only is your team different, but the mini-boss reward has different capabilities.  Like this one is a staff that does hugehge amounts of burst damage, whereas that one is a dagger that does heaps of ambush damage, etc...

13

Design / Re: Player goals within roguelikes

« on: March 17, 2015, 12:57:31 PM »

That offers the player an extra decision to make which is cool, but it doesnt count as a subgoal.  I did think of something though -

Currently in the game, XP is silently and incrementally turned into stat increases.  There is no leveling up, its just that every now and then as your XP increases, this or that stat might tick up a notch.

Im thinking this is a wasted opportunity to (a) give the player some choices and (b) dangle some subgoals in front of them.

i.e. at the end of each level, you could get a screen that says how many XP you have to spend, and the cost for various stat increases, and also buy new abilities.  This is a tried and true method...

So then the player would be looking forward to the end of each level as the chance to improve their character and they might have specific things on their shopping list theya re saving up for.  This would count as sub-goals.

Also, I was thinking that 20 levels until the battle with the big boss is not a very immediate - its the end goal, but the player can lose sight of what they are fighting for.  So Im thinking if there are 3 or 4 mini-bosses, each having a piece of something that when fully assembled enables you to kill the big bad, as well as being a handy item in its own right, then every 4 or 5 levels the end-goal is being reminded/reinforced as well.

14

Design / Re: Player goals within roguelikes

« on: March 16, 2015, 12:34:41 AM »

Hi - yep, there is loot, but you have to fight to get it.  Its just not lying around or able to be purchased, is what Im saying.  Also, the dungeon is a one-way trip.  No going back up.

mini-bosses with unique items was my first thought, because it would be easy to implement. 

From my own experience, I do get involved with things like  poly-piling stuff, and heading back to levels where there was an expensive item when I have enough gold.  These are sub-goals I set for myself - self-imposed quests I suppose you could call them. 

I think 'crafting' is another such - collect bits and bobs and the sub-goal is to get a cool item.  Poly-piling is a form of crafting I guess...

15

Design / Player goals within roguelikes

« on: March 15, 2015, 10:52:07 PM »

Im building a squad-based tactical roguelike.  (3 character team)  www.dungeonbash.com 

I feel like I have the squad-based tactics more or less in place. 

But now I feel like I need another layer to the game - some explicit player goals besides the single one - descent to level 20 to kill the big-bad.  That is the main goal, but I feel if I add fairly frequent sub-goals, they will help pull the player along by dangling that a 'just one more' type of carrot in front of the player.

What kind of short term achievements/goals do you think would be a good idea in a roguelike where the main preoccupation is squad-based tactical combat.

For context, the game is based in a dungeon (duh), and currently all items are gained only through killing monsters - there is money, no shops and no items lying around on the ground.  There is XP which results in incremental upgrading of character stats.

thanks,