Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Jotaf

Pages: [1]
1
The duration of a game is entirely up to the dev, usually by changing the number of levels. Of course, if there's not enough interesting content in your game, it should probably be kept to a few levels; but as you grow more content it might make more sense to also have many levels.

You can always force it to be a coffe-break RL (like DoomRL and others) by reducing the number of levels; but these games also feature a less steep learning curve and overall simpler mechanics than the big RLs. Of course that part can be planned in advance :)

The unpredictability of the RNG doesn't lend itself well to the "hours to finish" measure -- that's ok for rollercoaster rides like the commercial games, but when you factor in the perma-death and the replayability you can't really just put a "40-hours of entertainment" stamp on it ;)

2
My plan currently consists of a vision of the type of game I want, and not much else. This has got me much further than the previous 50 grand schemes of world domination :) I once had a great plan for an RPG that consisted of more than 1mb of pure text. All of the features were pies-in-the-sky though. No RAD could ever have done THAT.

I keep a "to do" list but most importantly a "done" list, for motivational purposes :) It was suggested to me recently and I love it. Periodically I take some items out of the "to do" box and into the "maybe" pile; things that seemed nice at the time but now have grown old and I don't feel like implementing them.

This is all for fun so most of what I do, I do it for the fun of it -- the journey matters, not the end result. The main criteria for selecting the next thing to do is how easy it is to implement and how fun I think it is for me to code. And so I've been ticking items off my to do list like crazy. :)

A great factor here are the tools I use. Dev in Python is waaay more rapid than in Java, which in turn is moderately more rapid than in C++. RAD methodologies can only get you so far. In Python I can pass lists and dictionaries all over the place without breaking a sweat. And then there's the doryen RL library, which has easy true-color console display capabilities and every RL algorithm you could possibly want. A powerful combination.

So, as you can see, we all know how to pump code like crazy. It's just that, contrary to intuition, RL dev is pretty hard for a one-man army.

3
Programming / Re: Roguelike Game Engines or Developer Wanted.
« on: April 13, 2009, 01:37:42 AM »
I'd like to have multiple stories in my RL. Yes, uncommon. I was inspired by the heavy story-telling of Legerdemain, and wanted to a story-centric RL for a long time. So if you'd like to see one of your stories come alive in a RL, give me a call :)

My RL on Roguebasin: http://roguebasin.roguelikedevelopment.org/index.php?title=Torchlit

4
Programming / Re: (un)acceptable memory usage
« on: April 13, 2009, 01:32:39 AM »
Ya know, in Python land, if the tiles are stored in a list, you can "use pointers" with very little modification. Just make sure you create one instance of a tile type that you want to reuse -first-, like wall=Foo(), and then just merrily set it somewhat like this: mylist[i ]=wall. In the case of nested "2D" lists as is usual with maps, that would be map[x ][y]=wall. Python's copy semantics, unlike other languages like C++, won't make a different instance for each, instead they will all point to the original "wall". On the other hand, if you had map[x ][y]=Foo(), THAT would make a different instance for each tile. :)

BTW you can always check an instance's "true identity" / memory address using the function id(). So when you're not sure just print some id()'s.

Pages: [1]