Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    53
  • comments
    225
  • views
    69537

A watery grave

Sign in to follow this  
Milkshake

407 views

Well, not a whole lot to report this week.

I decided I needed a temporary "floor" so I could see the shadows of objects (as without any depth cues, even I couldn't understand where some of the things were being generated). I dragged out some old water code I had from a previous version of the game where it was much more terrain based, and added a GL backend for it so I could see it on the mac build (which took inordinately longer than it should have, because I always forget you need to use a second texture stage to have texture and CPV at the same time). The water bobs and swells while the texture slowly drifts over the surface - all totally out of place inside a room, but after reading the article on how Ritman wrote the story for Head over Heels, I'm less worried about having a solid explanation for everything I put in up front. I've also turned on labels in the rendering code so I can match up the room that gets generated with the logical puzzle it thinks it's asked for.

x

Now I certainly don't plan to have every room half full of water, but putting this in reminded me of that awesome Tomb Raider level (The Cistern, I think it was called), where you have to raise and lower the water to get to different parts of the level. I don't think I'm going to force my poor little cow to swim, but maybe if I made certain blocks float on water, I could create some cool puzzles where you need to flood the room to raise a platform up (to either collect something or jump off the floating block to get to another part of the room), and then lower it again to get to the door you submerged when the room was flooded. Yet another thing on my ever expanding todo list (currently sitting at a staggering 2675 lines long).

Other than fixing a nasty bug in my capsule to box collision code that was flooding my physics solver with NaNs, I did put in some initial support for generating blocks inside the puzzle. Adding these made it instantly feel a lot more Head-Over-Heels-ish (which is precisely what I want by the way). It's still pretty stupid about using the blocks: it doesn't know how to ensure you actually need to use the block when navigating the puzzle, and the building code doesn't have a clue how to take blocks into account when laying out the platforms, but it's a good start.

x

x

Cheers!
Sign in to follow this  


11 Comments


Recommended Comments

This is looking really cool now. As I've said before, I think all this procedural generation stuff is very ambitious and I'm looking forward to seeing how it pans out.

Swimming cows would be pretty cool though [smile]. (*Featurecreep alarm sounds*)

Share this comment


Link to comment
Cool project! This is the first I've stumbled upon it so I'll be keeping up with your progress. I really like the graphical style. The perspective immediately reminded me of Solstice back in the Nintendo days.

I'm a big fan of procedural content and would be interested in any of your findings (if you so choose to share with the community). That's going to require some clever programming. The AI will have to "know" whether or not a puzzle is unsolvable. Interesting.

Share this comment


Link to comment
Funny you should say that EasilyConfused - I do have old build with a swimming animation in it. I think I added that right before I realised the project was just way out of control and I scaled it back to something a little more focused. I'm trying to be really strict with myself right now and only work on stuff which makes it fun (and once it's playable, makes it more fun).

And Rav, CPV = Colour Per Vertex - it's just the Maya term for having different colours on each vertex of a mesh. The fluid code has an option to change the translucency of the fluid based on the depth at that point ... it's pretty crap though to be honest.

Share this comment


Link to comment
Thanks Jay - and yeah Solstice, another very cool iso game from the past. I really dug the dungeons in that game, but I will admit I found the above-ground mode 7 stuff a bit odd.

It's still not clear to me whether I'll be able to get the whole procedural thing working, and there's some wholesale refactoring going on as I add new things (like the blocks). One of the hardest bits is trying to include the whole human perception aspect to it: a lot of things that are very valid, are also very ugly or almost impossible to sort out on the screen. Still fingers crossed eh?

Share this comment


Link to comment
(Warning - I am about to waffle b*ll*cks)

I was just wondering if there was any possibility of implementing some kind of learning system for your procedural generation, so that it spits out a succession of rooms that you manually sit there and "score" based on how human-pleasing the result was.

Would it be possible over enough time and samples for the generator to analyse the scores versus the parameters used to generate each room and see if it could find any kind of correlation between its parameters and your score?

(Waffle ends)

Share this comment


Link to comment
That's an interesting idea. Were you thinking more about what you actually do in a room? Or the way it looks?

Currently, I only have parameters that govern the types of elements it can use and how "hard" they can be. So you can ask the puzzle generator to give you a room with lots of really hard acrobatics, versus a room with lots of combat (once I add that), versus a room with lots of puzzles (once I add those) - or any combination of the elements. I'm also planning on having sliders that control the density, linearity, treasure, etc. I hadn't really thought how any of those parameters would get set - whether I'd actually expose the sliders to the player and let them pick, or whether I'd look at the kind of character they'd made/played and match that, or whether I'd generate multiple paths through the dungeon, a jumpy one, a fighting one, or a brainy one, and just let you choose which path to go down. So I could do some kind of rating system where a user says "Hey, I really enjoyed that room, make me more with those kinds of elements in them", and I could tune the parameters to the users taste a bit.

The part that I don't have any tuneable control over is how the room gets layed out - there's a directed search it uses to try and fit everything into the room, but there's no way to bias the kind of output you get from it. All I can do is add new rules to it's layout algorithm (and that's my plan to try and teach it the difference between and ugly room and a nice one). So even if a human said "Hey, that room looked cool, make me more that look like that", I'd have no way of really applying that feedback.

Share this comment


Link to comment
You're procedural puzzle idea got me thinking and I had a moment of inspiration I thought I'd share. Rather than trying to create a puzzle/level from scratch, start with a completely straightforward map, identical rooms, doors on every side of each room, flat wall-to-wall floors, etc. Then, have the AI procedurally modify the map in steps. You're starting off with something that is obviously solvable. From this point you can modify/test/modify/test/etc. until you have a completed puzzle. The difficulty level of the map could depend on the number of modifications made.

Am I making any sense? =/

Share this comment


Link to comment
Certain does make sense - it's a subtractive model, where the one I have is more of an additive one. I'm guessing for a bunch of scenarios it would generate much nicer looking room layouts much faster than my code does.

The one thing that's really hard to handle is making sure there are no unintended paths across the room (particularly when the entry is elevated above the exit). I'm wondering whether this would be harder again to implement with a subtractive model?

You also touch on an issue I thought long an hard about - do you do the logical design of the room at the same time as the physical design (e.g. as you pick each element, you place it in the room), or do you separate the two (design the room logically, and then "render" it). I think if you're doing the modify/test thing, you probably need to do the two at the same time. My puzzle generation currently separates them: it starts with a logical design (more of a mathematical topology kind of description of the world), and then passes this down to a "Builder" who's job it is to build something that meets that design. The hope here is that is should be able to support many different ways of building the room and pick the best one to use for a given puzzle (or use different ones for different levels to create some variety).

The other thing is that I've separated the room layout from the room building. So there's a layout step which just works out where the rooms are, how big they are, where the doors are, etc. Then it passes those requirements down to the puzzle generator to design each room. The idea here is that I can swap in different room layout algorithms - either a nice uniform grid as you suggest, or a really windy complicated dungeon full of different sized and shaped rooms.

Are you tempted to try it out too? It'd be great to see how the different approaches work out? I'd love to see more isometric puzzle style projects on here!!!

Share this comment


Link to comment
Actually, I just might take a crack at it. I'm a bit short on time lately but I don't think I'd have much trouble throwing together a quick prototype in C# (or even FreeBasic if I really want to get it done fast).

Using the subtractive approach, I was thinking about starting with a wide-open grid and then subtracting rooms and doorways first. This would be done by the mapping algorithm while the individual rooms would be created by the puzzle algorithm. Hmmm, if solving a puzzle in one room requires actions in other rooms, the mapping algorithm would have to be involved in this as well.

I usually approach complex problems in the most simple way possible. I may just start off with something like a simple switch/door/bridge game mechanic. For instance, a room may have three entrances, none connected. One door just leads to a platform with a switch. The other two are seperated by a bridge. You'd have to find your way around to the door with the switch before being able to cross the room. Starting with something like this, I may try to add other "layers" to the puzzle building process so that the obstacles/puzzles "emerge" unexpectedly and give the user a varied experience.

It's quite a challenge! I'll bounce some more ideas off ya if I come up with any more...

BTW, I dig the cow ;-)

Share this comment


Link to comment
Hi Milkshake, I just love those graphics :)

As you say, very head-over-heels'ish LOL

Keep up the great work dude ;)

cheers,
Paul

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!