Messages

1

Programming / Re: Cavern generation code

« on: July 18, 2013, 04:44:05 PM »

Oh well @#$@.  Dangers of using a beta service I suppose, but Koding completely redid everything.  Again.  I'll have to wait until I get home to setup a dropbox dl link until I can figure out the new system.

Thanks for the heads up on this.

2

Programming / Re: Cavern generation code

« on: July 14, 2013, 11:49:59 PM »

The diggers/roomies approach does look interesting, but as Krice noted maze generation is different from cave generation.  Still looks like an interesting approach, and it's been added to my list of generation techniques I want to implement in C#.

Still tweaking data values/experimenting with cleanup code to refine my algorithm.

3

Programming / Re: Cavern generation code

« on: July 11, 2013, 02:20:44 AM »

Hmm, I think I'll try running the end result through the cellular process, see if that helps with the diags without destroying how the dungeon looks.

4

Programming / Re: Unity 3d

« on: July 11, 2013, 01:52:19 AM »

Well no idea what ORK is, but yes I use unity.

Edit: Ah, ok it's a RPG framework.  I use Orthello to handle tilemaps and animations.

5

Programming / Re: Roguelike with every (well not actually every) Genre!

« on: July 02, 2013, 04:02:27 AM »

I really don't think this idea is possible at all.  Such a game would feel unfocused and very, very random.  Further more the sheer amount of content you would have to generate to have all of those things in a single game would make it very difficult for a solo dev to complete.

Even just looking at the combat system I don't think it would work.  It's like a doctor told me once when he was giving me my temporary leg brace to use before my custom ordered one came in: "This is one size fits no-one.  It will work, but it won't be comfortable."  I'm sure you could create a combat system that technically works for all of those different situations, but it would never work as good as a system designed specifically for that setting and genre.

6

Programming / Re: More Free Tiles!

« on: July 01, 2013, 08:54:16 PM »

May I suggest putting them up on OpenGameArt.org for more exposure?  It's a very clean set so I'm sure some devs over there would like to use them.

7

Programming / Re: Cavern generation code

« on: July 01, 2013, 08:45:26 PM »

Looks nice.

Not only doesn't look nice, but it's not even ready yet (no connections).

One hour tops to implement connections.  Maybe an extra hour to tiddy it up to make it as generic as possible., so I don't consider that a major hurdle, especially since if you configure the input values correctly you can get very large continuous zones.  The main reason behind the speed is how the data is stored, it is trivial to pick a random node in zone 1, a random node in zone 2, and bamf! connection.  Assuming you have to enter a command to go through it, as is the case with most rogue-likes.  Connections that auto-move you do suddenly become more interesting to place.

Keep in mind my intent with this is to create a general purpose generator that can be used in any C# based rogue-like.

Krice: Could you give me an example or two of algorithms that you consider good as far as cavern generation goes?

I agree with your premise.  I appreciate blunt honesty.

But even so, things aren't all bad all the time.  It's one thing to have standards, and another to expect perfection.

Some cultures are just like that, doesn't bother me.  My wife is from Taiwan, and she's like that (though considerably less...blunt ) On the rare occasion she says good job I know I dun good.  The rest of the time is spent pointing out what could have been done better so it can be done better next time

Watch those diagonals.

4-way connectivity is nice, but the aesthetic is incomplete when diagonal edges between tiles still exist.

*sigh* Yes, it's something I've been struggling with.  I believe a good tileset rather than solid squares would hide this to some extent, but then it looses some of it's general application, since many rogue-likes don't use graphical tilesets.  You could of course hide it with a lighting engine, you can only see the area around you, so the player couldn't tell there was a space diagonal.  Still not ideal, I agree.

Anyway, nice little algo, but go make some gameplay now  ;P

Gameplay?  What's that?

8

Programming / Re: Cavern generation code

« on: June 30, 2013, 02:37:40 PM »

@Krice:
Fair enough on the unity plugin.  If you're truly interested in seeing it run I can build a stand-along version.

I am curious as to why a multi-pass algorithm is inherently worse than a single pass algorithm in your mind.  If I left all the tiny one or two space areas in, then I could see it being called inferior, but I don't.  They get cleaned up.  In fact I would argue the ability to create disconnected zones in the context of cavern generation a strength.  Take this cave for instance.  Coloring done in GIMP.

You could setup a series of portals, or 'narrow passage' or whatever you would want to call it to connect the different areas.  Also, performance is very good.  This dungeon is from a 56x34 area with 2500 size 3 drops, and it only took roughly a second to generate.  And if I wanted a single continuous, increasing the drops to around 3000 would do it rather nicely.

9

Programming / Cavern generation code

« on: June 30, 2013, 04:33:34 AM »

Want to get some feedback on this generation method I've been working on.  Mainly, does it look cavern-y?

http://languard.koding.com/cave/Build.html

And source for those interested: http://languard.koding.com/cave/CaveGenDropMethod.zip

The general idea behind the algorithm is I drop splats onto the area.  To see what I mean, turn drops to 1 and drop size to different values to see what one drop looks like.  The more red an area is, the more likely it is to be floor.  Clicking convert changes the raw data into dungeon data (floor - white or wall - black) and cleanup does that, it removes the little orphan areas.

I can write more later, but I'm more than just a little time crunched for getting this month's #1GAM done

10

Programming / Re: HTML5 RougeLIke

« on: April 26, 2011, 03:36:48 AM »

Blog updated.  Once I get Firebug, and once I stopped fighting the dynamic nature of javascript, things went a lot smoother for me.

Now to convert the generated dungeons into playable format.  Each pixel of the current display will represent one tile in the game of course.  As I plan on using 16x16 tiles, this represents a very large play area as I have it configured.

11

Programming / Re: Is Sharplike defunct?

« on: April 21, 2011, 10:58:55 PM »

I've never used it, but from my poking around I'd say it's dead.  SVN doesn't work and neither does the site they give for hosting it.  Also the Rogue Basin page was last updated almost a year ago.

12

Programming / Re: HTML5 RougeLIke

« on: April 21, 2011, 09:45:25 PM »

BSP Dungeon Algorithm Implemented.  ABOUT F***ING TIME!!1!!11!  716 lines of code in the main bsp.js file.

My word but that was a Trial by Fire introduction to the JavaScript language.  I'll work on a blog post about the process, but for now if you wish to see it: goo.gl/VCr9H  The yellow lines are the rooms.  The options don't really work at them moment, so touch them at your own risk.

13

Programming / Re: Memory Leaks in SDL and OpenGL

« on: April 17, 2011, 03:11:57 AM »

Only thing I can think of is maybe missing a SDL surface, or possible an array of surfaces?  Been a long time since I used SDL, so I'm just taking a shot in the dark because I know that was the source of one of my memory leaks.

14

Programming / Re: WIP: Chaos Fortress

« on: April 15, 2011, 08:19:51 PM »

If you need help with C# or XNA questions, let me know.  I've been teaching XNA/C# since 1.0.  I also have a basic utility library if you're interested, which includes an easy-to-use logging system which can display to the screen or write to a file, or both.

15

Programming / Re: Implementing materials for items

« on: April 14, 2011, 05:07:15 PM »

Also Dwarf Fortress has a very good material system implemented as well, and while the internal code isn't visible all of the material files are.

I would advise against separate properties for armor and weapons.  Taking a page from DF, a material has several properties: How sharp can it get, how heavy is it, how flexible is it, and so on.  Different items are going to care about different properties.  A hammer wouldn't care how sharp it can get, just how heavy is it.  A sword would pull on sharpness and hardness for cutting through things, and weight for how fast it can be swung.  Armor would mainly be concerned with hardness and flexibility, with weight tossed in for movement penalties.