Temple of The Roguelike Forums
Development => Development Process & non-technical => Topic started by: Gix on December 18, 2014, 04:14:50 PM
-
Hello,
Given its presentation, the purists might not call this a rogue-like but my team and I are working on an ambitious first-person rogue-like.
After a year of development, the dungeon generator is starting to take shape. Internally, we're very excited so I figured we'd share. Here's what we've got so far:
(http://1.bp.blogspot.com/-xxJia7aG6F4/VHzGJDeskPI/AAAAAAAAAmA/CVGEUxdfvrI/s1600/dl%2Bscreen10.PNG)
(http://2.bp.blogspot.com/-TrG6ViSHoDY/VHzGPkJXCWI/AAAAAAAAAmU/j0LQQse_q60/s1600/dl%2Bscreen13.PNG)
(http://4.bp.blogspot.com/-YFT9QD5Cbe4/VJECR9P4OVI/AAAAAAAAAoY/_O91ACm3-vg/s1600/DL5.jpg)
(http://3.bp.blogspot.com/-ebPyRmjb-RA/VHzF5e6poPI/AAAAAAAAAlo/DnmiySz-7qY/s1600/0_112.jpg)
(http://4.bp.blogspot.com/-1KvNtIyq3qE/VHzFzYviTGI/AAAAAAAAAlg/IiXBtJ407tE/s1600/bluecrystals1.jpg)
(http://3.bp.blogspot.com/-4Vw0FlXAGr0/VJECQYqPedI/AAAAAAAAAoE/QuD7IqhdUrA/s1600/DL1.jpg)
(http://3.bp.blogspot.com/-03QdkxEtu7w/VHzGHjoeq8I/AAAAAAAAAl4/by3CK-iq0L4/s1600/dl%2Bscreen9.PNG)
-
Very nice looking. Is this based on a first person shooter engine?
-
This is being accomplished with the Unity engine and, while it's in first-person, we hope that it won't be perceived as a shooter (not that this is what you were implying).
Or goal is to build a rogue-like where you're very much in the shoes of your character while keeping the combat at a much slower pace.
-
Looks very nice. The shafts of light in particular add a lot of atmosphere. Are the meshes being generated fully procedurally or are they being assembled out of pre-made chunks?
-
Very nice!
-
Looks very nice. The shafts of light in particular add a lot of atmosphere. Are the meshes being generated fully procedurally or are they being assembled out of pre-made chunks?
We craft multiple (small) custom-built meshes that are procedurally laid out which are, then, stitched together into larger chunks. It's an elaborate tile system (in the sense that there can be multiple pieces per tile) that creates each room. If we were to generate two flat walls, they would look quite different from one another.
We're trying to push for as much procedurally generated content as possible.
-
Given its presentation, the purists might not call this a rogue-like
Oh, why not? Everything is a roguelike now :).
-
Funny, it looks a lot like I've imagined my RL project Kaduria would look if it was 3D. Even this is not a roguelike it's interesting. This kind of 3D procedural generation must be quite complex to code.
-
Gix, don't mind the troll. I love the screenies. Anywhere I could find a beta and give you guys some feedback?
-
Given its presentation, the purists might not call this a rogue-like
Oh, why not? Everything is a roguelike now :).
It's a pet-peeve of mine when people mislabel things; particularly in the context of video games. I find that RPGs and rogue-likes seem to have suffered the most in this regard where:
- If you kill things and gain character levels, it's considered to be an RPG ::)
- If it's got permanent death and a random playing area, it's a rogue-like :'(
I believe that the people who use these skin-deep definitions to describe the genre kind of miss the point. They have every right to do so and (technically speaking) they're not wrong. They're true but inaccurate. I just (strongly) feel it's a disservice.
On the other side of the coin, Rogue-likes have often been described as top-down grid-turn-based games and they kind of need to be for them to have that strategic "last turn might be your last" appeal... which I agree and is why I put the disclaimer. We're actually putting a lot of thought into keeping that feeling without using grids or turn-based game-play.
Funny, it looks a lot like I've imagined my RL project Kaduria would look if it was 3D. Even this is not a roguelike it's interesting. This kind of 3D procedural generation must be quite complex to code.
It's certainly complicated from a technical and art standpoint. Because of its perspective, you have to account for performance when rendering a horizon. On the art side, you have to figure out how to draw the ceiling in interesting ways and do things like procedural lighting. You have things like light shafts that are dictated by points of interests (treasure chests, boss monsters, etc) which, in turn, influence other aspects of the environment such as flora.
I think the most complicated thing there was to code was the pathing; making sure that the generator knew where the player could and couldn't go in 3D space and build ramps where it needed them. It's really important for numerous things, like figuring out where the player is most likely to be looking and where to lay traps.
Gix, don't mind the troll. I love the screenies. Anywhere I could find a beta and give you guys some feedback?
The project is in early prototyping phase and we're slowly transitioning to production for a pre-alpha. I want to at least incorporate traps in the generator before letting anyone delve in because, otherwise, there wouldn't be anything to do. Monsters can spawn but the AI and animations aren't in yet; we got another prototype for that.
-
I just want to defend Krice's right to express his fantasies about video games he'll write someday. People who dare to dream deserve our respect.
I too envision a future version of mushroom patch simulator (MPS) with 3D, procedurally generated graphics based on a genetic algorithm. To keep it simple, I mine data from the genome of a mushroom (Cortinarius rubellus to be precise) and generate content from its gene sequences. Of course, I don't think a flat screen could adequately express my vision. I imagine a future technology in which the player sits inside a large ball, say 8 feet in diameter, wearing a helmet fit with projectors that beam the visual game content onto the walls of the enclosing ball. By tracking the movements of the player's head, a realistic, totally immersive 3D perspective can be simulated.
For now, I don't think there's much point in using 3D graphics, but at some future date when the technology I describe is commonplace and the world is ready, then perhaps I will realize my true vision of MPS (to the rapturous praise of all).
-
For now, I don't think there's much point in using 3D graphics, but at some future date when the technology I describe is commonplace and the world is ready, then perhaps I will realize my true vision of MPS (to the rapturous praise of all).
What you're describing is stereoscopy. As to whenever or not there's a point in using a 3D engine; it's just another tool of expression like text, ASCII graphics and sprites. I'm a believer of "show, don't tell" so my team and I are always looking at ways to increase visual fidelity... not to mention that the entire team (as we are now) knows how to do 3D video game art.
-
It looks very interesting.
I got some good ideas for my own project just by looking at the screenshots.
I'm also making a 3d graphical version of a roguelike, pretty much at the far end of the spectrum of roguelikeness, i.e. not very roguelike. :)
I think it's interesting to follow the arguments about what is or isn't a roguelike, it's similar in a way to other genre defining arguments, like what makes a detective story or a horror film.
Ultimately though, I think that genre conventions can be useful, but they can also be too constrictive, especially when it comes to technical considerations. In 50 years time do we still expect that roguelikes should be restricted to ascii graphics? And if we can accept roguelikes mutating to include 3d graphics engines, can we also agree that with a change in representation we might need to accept a change in gameplay? I really can't imagine that turn based gameplay is going to work very well in a first person roguelike... Perhaps at some point it requires a new break away genre to be formed, rather than another disruptive subgenre.
Anyway, on to some more useful commentary:
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 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).
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.
-
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.
We'll see who's idiosyncratic when mushroom patch simulator (MPS) is released. Until then, I have the persistence and conviction to endure the slings and arrows of critics. Probably the most persistence and conviction of any artist the world has seen.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Looks great!
-
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:
(https://2.bp.blogspot.com/-nqXW8_A3Gvs/WPgdzu5VcOI/AAAAAAAACM8/bDsp6BHvnh8enEbnVWJpt96DEnc3PTD0QCLcB/s1600/april19_num1.jpg)
(https://2.bp.blogspot.com/-tp_S08LFipw/WPgdzjLzlhI/AAAAAAAACNE/RYbJd2ZHHVkV9Xksv0uwx4LIh4a_4CeBgCLcB/s1600/april19_num2.jpg)
(https://4.bp.blogspot.com/-VJYv25n83mE/WPgdzjqd0cI/AAAAAAAACNA/5AzlV4zXx-c1IJI4hQ3aq9zrKqyhmi-hACLcB/s1600/april19_num3.jpg)
(https://1.bp.blogspot.com/-hH-TX9sMClI/WPgdz0O02nI/AAAAAAAACNI/Qi7fUAZ0X4AJIdXJxis09lebTjMKNGA7ACLcB/s1600/april19_num4.jpg)
(https://1.bp.blogspot.com/-4O-hx8pG2yI/WPgd0I5F2hI/AAAAAAAACNM/rU3wnw7NogsjG-zZoSSbQaD81neBJjWkQCLcB/s1600/april19_num5.jpg)
(https://3.bp.blogspot.com/--Mjm0Cnxmsk/WPgd0DV1uII/AAAAAAAACNQ/hVBDmfK21IgwnN2qwubCao54Qr-LQ_mMgCLcB/s1600/april19_num6.jpg)
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.
-
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.
-
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.
-
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.