Dungeon generator protoype

[Gix]

I really can't imagine that turn based gameplay is going to work very well in a first person roguelike

It's actually not that bad.  While it may not be a roguelike, Legend of Grimrock is nicely done.  Granted, the viewport is fixed like the old Wizardry games but it works.

We opted for real-time for numerous reasons; one of which is the opportunity to pull off multi-player.  Being able to delve into a inhospitable/harsh environment with a friend and go against the odds is a concept I find very appealing.

It looks very interesting.
I got some good ideas for my own project just by looking at the screenshots.

The map layout is good, good connectivity and the multi level sections are great.
I like the depth of field filter, though I hope it doesn't interfere with gameplay. Sometimes these kind of visual enhancements look fine for showcasing level design but don't work once you get in to gameplay.
I noticed a bit of repetition of elements in some of the smaller corridors, especially picture number 3. Do you have a way of dealing with that?

When are you thinking of making a gameplay demo? I'd suggest making that a priority. Even a reduced function demo where you run around and engage in a little combat with some simple monsters will get people to engage with the game and give you some useful feedback.

We're playing around with different builds that have different levels of depth of field values and various other things like Bloom.  There's currently a toggle for these effects and, while I'm trying to find a good setup, I like the idea of having and "advanced visual settings" category to calibrate to everyone's liking.

The repetition you see (or noted in picture #3) is mainly an issue with our current shufflebag algorithm that (should) prevent the same random values from reoccurring too frequently.  We're confident that, once that's rectified, that a lot of the repetition will be subdued if not eliminated.  My main art guy is also keeping a close eye on the art (adjusting the textures and models) while I'm focusing on bigger-picture aspects of the development at the moment.

The combat prototype is nowhere near presentable at the moment and our main concern for it is the pacing.  It's one of those aspects that we believe we need to be satisfied with before looking for feedback from outside sources.   With that said, I expect our "playable" demo that showcases the dungeon generator to be available sometime in the spring.  It might be boring to just look around but we figured it might be interesting to see how the environment plays out (with traps and such) before introducing monsters.

We're actually putting a lot of thought into keeping that feeling without using grids or turn-based game-play.

A common mistake when trying to do this is to simply make a game real-time but very slow-paced, which I think rather misses the point.  Turn-based roguelikes allow you to take half an hour deliberating per turn if you like, or you can keep hitting the keys and be the other side of the level in a couple of seconds - they are as slow- or as fast-paced as you want them to be at that moment in time.  Roguelikes can be killed stone-dead by an enforced slow pace (for example, those with too-slow animations).

The turn-based gameplay is one of the aspects of the genre that I love and I also agree on the pitfalls of real-time... it's probably why our combat prototype hasn't come along as far as the dungeon generator.  Structurally and visually we know how we want it to look like but, for the combat, we only have an idea of how we want to feel.

Right now, what we've got is what I've come to call a clock-based system.  Every X moments, entities are synced and moved and their motions take (currently) X amount of time to complete so that they don't look like they're waiting for those moments (to avoid that constant stop-n-go feel).  X is whatever seconds we're playing around with at the time.  It's basically "1-2-3" ballroom dancing and/or how one reads sheets of music.  That allows us to quickly adjust combat speed to figure out what's comfortable and fun.  From a player perspective, you feel a bit detached (as some actions aren't instant) so we know that's not the answer...  or (at least) that there's more to it than that.

We've even played with the idea of stopping the clock whenever you let go of the controls.  These systems are still up for debate internally and I'd be curious to hear your feedback once we got something that we're satisfied with.

To explain an idiosyncrasy of this forum: Krice is perpetually making posts, whatever the topic may be, about how his never-seen-but-always-talked-about twenty-year project is going to do everything much better than everything else that has ever been made.  In retaliation, Mushroom Patch has started making parody posts in the same style.  Taking anything either one of them says seriously is a waste of time.

Noted.  Thanks.

[Aukustus]

It's actually not that bad.  While it may not be a roguelike, Legend of Grimrock is nicely done.

We opted for real-time for numerous reasons

I hope you avoid Legend of Grimrock's "hit->strafe->turn to face previous tile->wait for monster to follow->repeat" combat exploitability.

[Gix]

It's actually not that bad.  While it may not be a roguelike, Legend of Grimrock is nicely done.

We opted for real-time for numerous reasons

I hope you avoid Legend of Grimrock's "hit->strafe->turn to face previous tile->wait for monster to follow->repeat" combat exploitability.

Yeah no kidding.  I was merely pointing out LoG's take on the first-person view.

Right now, everything that moves in the game is clocked at the same rhythm.  Like, every X seconds, everything moves by Y squares; Y being that particular entity's speed value.  It's clunky but serviceable until we figure out how fast/slow things should be moving.

[Krice]

A common mistake when trying to do this is to simply make a game real-time but very slow-paced, which I think rather misses the point.

What if you want to miss the point. Trying to force turn based design can be as bad decision, but I know it's going to be easy to spot once you try it.

To explain an idiosyncrasy of this forum: Krice is .... Taking anything either one of them says seriously is a waste of time.

Says who. A random guy on internet.

[Omnivore]

Try adaptive real time with pause.  Assign reasonable costs (energy or action points/movement points whatever) to each action.  Set an easily adjustable default rate at which points are expended per second.  Add an easily accessible pause feature that stops the clock.  Now track the rate at which the user inputs orders (keystrokes, mouseclicks, etc).  If the player is entering new commands before the time for the last one has expired on a continual basis, the game is running too slow; increase action points per second.  If the player is lagging - still entering input at least every few seconds but all player actions are past time out, the game is running too fast; decrease action points per second.

The player should always have the last word though, there should be easy manual ways the player can adjust the speed, overriding the adaptive system.  You also probably want to have afk detection and allow the game to be configured to auto-pause on afk.  You would probably also want the speed adaption rate to be adjustable via config file or options menu.

For multiplayer, you might want to research how this problem has been addressed elsewhere.  I believe you could apply the adaptive approach in multiplayer as well though using an 'and' function - all clients are detecting need to go faster or all clients are detecting the need to go slower.  You will also probably want some kind of voting system to set the game speed and give each player an optional x amount timeout they can spend. 

The above more or less mimics the way I, as an old fart with slow reflexes, play games like Warzone 2100.  I change the game speed often during play and liberally use pause for when I have to figure out what I'm doing, lol. 

PS: I would advise against trying to find a 'one size fits all' speed beyond a general beginner default speed.  Not only do people vary widely in their perception of time and their reflexes, but also as a player learns the game they will generally be more and more capable (and probably desiring) of playing at a faster pace.

[Gix]

Thanks for the suggestions; it's greatly appreciated.  This is one of the many aspects of game design that requires a lot of iteration and testing so, at this point, no one really knows how it's going to end up being.

Adaptive real-time (or a variant of) will most likely be the solution.

PS: I would advise against trying to find a 'one size fits all' speed beyond a general beginner default speed.  Not only do people vary widely in their perception of time and their reflexes, but also as a player learns the game they will generally be more and more capable (and probably desiring) of playing at a faster pace.

For the time being, keeping the amount of options as lean as possible is much more simpler to test to get an idea of where we're going.  We're definitely looking at player options in the future, though, it's a PC game after all.

[Eben]

Looks great!

[Gix]

Here's an update on the project.  This time we've stepped away from tiles and are using voxels for the terrain and have been working on exterior scenes.  Here are the results:








I'd love to show you some of the new caves environments to compare it with the original screenshots but I've yet to reintroduce some of the elements that made the caves interesting since we reworked on the tech.  It'll most likely take another month or so to get them back up to snuff.

[Krice]

I find this kind of funny, because if there is something we roguelike players don't care it's pretty screenshots from a graphical engine. But I hope the game will be nice as well. If we get an actually good role-playing game with graphics like this I'm not against it at all.

[Gix]

I find this kind of funny, because if there is something we roguelike players don't care it's pretty screenshots from a graphical engine. But I hope the game will be nice as well. If we get an actually good role-playing game with graphics like this I'm not against it at all.

It's less about visual quality and more about what's going on under the hood to get it running; it just so happens that we're already using a good engine to make it look pretty.

I hope that we can make a good game out of it, too.  What we sacrifice by using a first-person view and a quasi-real-time game, we hope to make up for it in the dialogue and multi-player systems.  There was a focus on visuals for a long time because, like any developer, we needed to figure out how we were going to make the computer build and draw the environments/dungeons; similar to how one would need to figure out how to compute/display tiles and line-of-sight on a more traditional rogue-like.

Ironically, I think the biggest obstacle we face while making a game with visual fidelity a this level is that, something as simple as potion colours becomes hard to make distinct from one another.  By focusing on visuals, you make a statement of "show, don't tell" so using text kind of defeats the purpose.  16 colours reads really well on screen, but any more than that confuses the player.  So, right now, we're being really choosy on what effects each potion should have... but I kind of eventually want to expand the list of potions available.

[Krice]

something as simple as potion colours becomes hard to make distinct from one another.

Potions could come in different shapes. Also, symbols could be one option. I recall symbols were used in Dungeon Master to show the power level of a potion.