Messages

1

Off-topic (Locked) / Re: Portal 2

« on: May 04, 2011, 10:43:11 PM »

"emerging" in that there is only two things you can do: right mouse click and right mouse click (open portals) and all the puzzles build on top of those without adding any more mechanics.

whereas in a rogue you'd have dozens of inter-connected mechanics.

Oh ok, we're saying the same thing then. When I hear "emergent gameplay" I think of the player using the mechanics in ways that weren't anticipated by the devs, thanks to the complexity of the system. It's hard to imagine that ever happening in a game as linear as this one. Roguelikes, on the other hand, are all about "emergence."

2

Off-topic (Locked) / Re: Portal 2

« on: May 02, 2011, 07:20:35 PM »

that's a weird way to put it. portal's production values aren't that good. it certainly relies a lot on emergent complexity built on top of simple mechanic(s).

I'm not sure how you mean the production values aren't that good - valve is famous for thorough playtesting, they scooped up some ex-Pixar animators to work on this game, and we're talking about a series that is as famous for its memes and voice acting as it is for its game mechanics, if not more.

I don't know what emergent complexity there is to find, either. It's a straightforward puzzle game with one intended way to beat each room. There are a few "hidden rooms" which are either easter eggs or bits of lore. What's emerging?

To quote from another thread:

I was first surprised that my laptop which is four years old was still able to run these games.
So what do they look like? Seems a lot of money goes in the production, real voice actors, even real actors (like martin sheen), spectacular visuals (art is a different topic, tho), all in all an equivalent of Hollywood movies in the gaming world.

And then there are reviewers from all over the web touting these products for mass consumption as something revolutionary and legendary. Ok, voice acting is breathtaking, but the rest - a typical holywood plot, space-opera cliches (in the case of ME2 it is obvious where their inspiration comes from - SF pulp from the factory of Hugo Gernsback and the like). It is sad really.

3

Programming / Re: Modern Hitman/Spy RL

« on: April 27, 2011, 06:38:18 PM »

Anyone wishing to make a stealth-based roguelike owes it to themselves to play Kusemono, it strikes at a really nice core mechanic for implementing that sort of genre into roguelikes. It's easy to see how things like disguises and shadows could be folded into it, as well.

4

Off-topic (Locked) / Re: Portal 2

« on: April 23, 2011, 05:38:34 PM »

it's funny how many of the things we like about roguelikes are exactly opposite to the design choices made in portal 2 - a game entirely guilty of having a short length, lack of depth and complexity, and a heavy emphasis on static plot

it has production values in its favor, but having voice actors and writers doesn't make a good game

5

Programming / Re: Methods against Save Scumming

« on: March 25, 2011, 07:58:43 PM »

I still don't see how it makes permadeath more meaningful but I realize now it's not a worthless exercise.

It's the only thing that makes permadeath meaningful in the first place

Permadeath isn't a thing if it's not permanent

6

Off-topic (Locked) / Re: Foul Bachelor Frog :-D

« on: July 08, 2010, 03:23:58 AM »

this meme more or less embodies my life at the moment as a poor college student

whatever

7

Programming / Re: Corner detection algorithm

« on: March 28, 2010, 06:55:27 PM »

The problem being that the first example is not a corner.  The middle tile has no diagonal edges exposed.

I would argue that it is a corner by virtue of being the point of intersection of numerous walls:

Code: [Select]

#..   ..#   ...
.#. + .#. + .##
..#   #..   ...

But I suppose that's something of a flawed rationale because something like this would be all corners

Code: [Select]

###
###
###

So I dunno. Depends on what you're trying to identify corners for. I originally wrote that algorithm to check whether a door or window could be placed on the selected wall segment so it worked fine for that purpose.

8

Programming / Re: Corner detection algorithm

« on: March 28, 2010, 03:33:52 PM »

I don't see how you can ignore the diagonals like that...  Consider:

Code: [Select]

#.#      ..#
.##  VS  .##
#.#      #.#
Or many other layouts, for that matter...  Of course I can't think of any elegant method to include diagonals.

I think you misunderstand. The algorithm I suggested would return both of those as corners.

These are the only situations which will return a corner when they are not:

Code: [Select]

..#   #..
.#.   .#.
#..   ..#

If your game has the possibility of this occurring, you can hard-code in checks for either of those situations and tack it on the end of the algorithm, which would increase total potential steps to 5. So it's still a lot more elegant than brute forcing by comparing to every possible permutation, and it also only has to look at walls, not floors (which reduces the ways in which things could go wrong). If there isn't a chance of those specific cases occurring, which was the case for my game, you don't have to worry about it.

9

Programming / Re: Corner detection algorithm

« on: March 28, 2010, 03:05:00 AM »

Had to deal with this earlier today actually.

Firstly, unless you specifically have to deal with diagonal walls, which I don't, forget about this:

Code: [Select]

...
...
...
and just think about these

Code: [Select]

.
...
 .

So let's say our function gives us a wall to test, that wall is the middle guy:

Code: [Select]

.
.#.
 .

so he's known, the unknowns are to his east, west, north, and south. This is what the algorithm starts off knowing.

First, check the spot to the right:

Code: [Select]

.
.#?
 .

If it's a wall, check the spot to the left:

Code: [Select]

.
?##
 .

If that's not a wall, the algorithm ends and returns that we have a corner. If it is a wall, check both above and below at the same time. If either is a wall, the algorithm returns a corner; but if neither is, it returns not a corner.

Code: [Select]

?
###
 ?

If, however, the spot to the east was not a wall, we have to repeat the process starting from north (only we don't have to check east on the last step):

Code: [Select]

?
.#.
 .


Code: [Select]

#
.#.
 ?


Code: [Select]

#
?#.
 #

If neither the east nor north tile is a wall, we can return corner.

The algorithm can take up to 4 steps, but as few as 2, so it's more efficient than checking the situation against every possible permutation of a corner.

10

Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)

« on: March 22, 2010, 03:25:45 PM »

Hey guys, I'm Ben, I'm an 18-year-old college student in Vermont. Been doing game art for years and will go into that professionally, but I've been learning C++ in order to be able to develop roguelikes. First one I played was Dwarf Fortress last summer, followed shortly by Nethack. Absolutely in love with the genre and hopefully will be able to contribute to it soon