In the early midgame

[Ari Rahikkala]

That's right, I'm in the early midgame. Well, *very* early midgame of roguelike development. My plan is to eventually release a game named Straylight: Divergence, a sci-fi roguelike with some transhumanist themes. But here's all I have right now, in the form of a video (Don't ask me what those Haskell libraries like HTTP and xml are doing in the first few frames, I'll be looking at the packages I depend on and what sort of weird dependencies they have once I'm closer to release time). Going through it, you can see I have:

- A walking @, yeah!
- An environment of some sort to play in. The room and connection layouts are supposed to look a bit like a university campus or a small office complex that's built "close to nature", with outdoors areas everywhere, and trying to avoid corridors (corridors are a bane of interesting gameplay).
- Other walking @s. They pathfind to randomly picked positions.
- A mess of characters in the indoors rooms. I intend to eventually get around to implementing some sort of furniture, these characters display places where it could go without disrupting paths between doors inside rooms.
- A sort of "shooting" (though there are no guns in the game yet) and "jumping" (with no limits on how far you can jump) interface.
- Incredibly basic character stats. Stamina doesn't do anything and I'm not entirely sure it will even stay in the game. I kill one walking @ by shooting at it ten times.
- Oh, and forgot to show this in the video, but you can pick objects up and they'll be carried with you. At least as much as the game state knows, anyway, there is no actual inventory interface yet.

That's all well and good, but where do I eventually intend to get? Well, here's pitch.txt, which I hope to use as the feature list when I eventually announce a v1.0:

- A mixture of melee and firearms combat, somewhat influenced by the Matrix series (but not as flashy), with cover as a significant element in gameplay
- Acrobatic combat moves controlled by "dancing" a la PrincessRL
- No killing rats or worrying about food - you are a badass superagent right from the first turn
- Equipment- and implant-based raceless, level-less, XP-less, skill-less and almost classless character customization
- Five character archetypes to kick off a specialised build (while avoiding limiting your later options): Homo Superior, Catlike Assassin, Hulking Brute, Half-brained Abomination, and Robed Ascetic
- A mid-hard approach to the science fiction theme, avoiding things like rayguns and psionics, but allowing for all sorts of cinematic transhumanism and weird physics
- Character advancement based on a large tree of perks ranging from mundane advantages like increasing your character's hitpoints, to special abilities like wallrunning or ability to "undo" actions
- Cyberware, bioware, nanites, performance-enhancing drugs, special mental disciplines, and more ways to make your character greater than human!
- A variety of psychoses to suffer from if one goes too far in one's human enhancement forays (based on a sort of sanity meter)

Some of these things I've got more specific plans about, some only a couple of vague ideas of. You'll note I've been savvy enough not to try to design a procedural plot generator, or to use complicated AI techniques, or make a MMORPG, or any of the other usual stupid pitfalls. But I haven't been savvy enough to come up with a development schedule that would take me to something playable through minimal effort (something that in fact screwed me over a bit in the past as I spent weeks working on some fancy subsystems that I've gutted by now after realising how completely useless or unimplementable they are), and still don't really know where to go with development.

So right now I'm having something of motivational/organizational problem: Here in the early midgame of roguelike development, you can get started on anything, but everything depends on something you haven't yet finished. I could just randomly decide to improve the interface for shooting, but I don't have a way to determine what's a good target yet. I could make an inventory interface, but I haven't decided what sort of an inventory system I should have and, for instance, how many different objects to expect the player to have to manage. I could try and see if I can make the NPCs start acting in more meaningful ways and reacting to things, but it would be so nice to at least have an idea of what sorts of NPCs I want, not to mention finishing with the furniture so I could have them interact with that...

... actually, come to think of it, I might just do message printing next.

So, uh, yeah. Please feel free to ask questions, make comments, commiserate about the difficulty of developing with a spec that's partially half-formed in your head, etc.. I just went public with this in the hope of refreshing some motivation points.

[dephbokks]

I think the rogue basin article "Make a rl in 15 steps" is a decent primer on getting going. Just start small and keep building in a modular fashion. The other extreme is to design and plan everything out thoroughly, sort of like how Incursion RL is being developed; then it is easy to see how it all fits together since it was all so thoroughly planned.

Personally, I am more for going slow and building in a modular fashion, although I do try to plan things out as much as possible. I know what you're saying. When you add some new feature that you didn't originally plan for you may have to extend many other classes in order to account for this new feature.

I saw yr video though and it looks like you're off to a good start.

I am interested in the transhumanism bent too. I know you said that you were inspired by the Matrix series, but may I also suggest to look up the novel, Neuromancer by William Gibson [http://en.wikipedia.org/wiki/Neuromancer], and the Eclipse Phase RPG [http://www.eclipsephase.com/]. Potentially, you could find some stimulating ideas in those sources.

[Fenrir]

I think the rogue basin article "Make a rl in 15 steps" is a decent primer on getting going.

I'm not sure that article is really much help. Perhaps someone who has been helped by that article can come forward and correct me.

See this thread for awesome advice by linux_junkie and Bear.

[corremn]

I think the rogue basin article "Make a rl in 15 steps" is a decent primer on getting going.

I'm not sure that article is really much help. Perhaps someone who has been helped by that article can come forward and correct me.

http://roguebasin.roguelikedevelopment.org/index.php?title=How_to_Write_a_Roguelike_in_15_Steps
Now that someone else has said it, I found it to be completely un-useful.  Maybe it is because I am completely unable to stick to a plan.  Surely adding bloody footprints should be step 5, right??

[Fenrir]

People from other forums have said that they think it doesn't look helpful (assuming nerd_pride doesn't visit the temple.)

If I can get permission from Bear and linux_junkie, I would like to put the contents of that thread to which I linked up on Roguebasin.

The great wolf looks expectantly in the direction of Bear and linux_junkie.

I found it insightful, and I think other people will as well.

[Krice]

you can get started on anything, but everything depends on something you haven't yet finished. I could just randomly decide to improve the interface for shooting, but I don't have a way to determine what's a good target yet. I could make an inventory interface, but I haven't decided what sort of an inventory system I should have and

The obvious way to proceed is start from simple things which more complex things then use. But you can also implement something and not worry too much about details - they can be added later. Don't try to make everything complete first time, it wont  usually work anyway.

I suggest you create micro (only part of features listed) todo-lists, starting from simple things that don't depend too much from other features. My own todo-list is sometimes changing, because I look at the source code and the project in general and come up with new ideas after thinking about what could be missing or should be done in some other way.

I think people look too much at the complete plan and the full todo list and then they get confused and overwhelmed. I think it's wiser to get your hands dirty and develop the game one feature at a time, even if it is just a simple implementation of the feature.

[Bear]

Y'know, I didn't think that 15-steps article was very useful either.  It assumes way too much about what you're creating and how it ought to work. 

What I posted in the "Organization and Workflows" thread is basically my approach to writing any program I'm writing by myself; I have no problem with someone posting it somewhere else, just send me a link to it when you've done so.

Bear

[linux_junkie]

You have my permission to repost anything I write here, in any form, anywhere you'd like.

[Ari Rahikkala]

Thank you for the advice so far . Yeah, I actually started out with the 15 steps plan, though of course with the understanding that not all of it would be applicable. For instance, implementing saving and loading in Haskell basically consists of adding "deriving (Show, Read)" to all of your data types, so I knew that I could just take step 5 whenever I damn well liked (there are complications, but they're pretty mild when you're just using this feature for roguelike savegames).

So I figured I'd just use this thread as a sort of a devlog. I don't promise regular updates, but at least I have somewhere to show where I'm going. http://www.youtube.com/watch?v=kYPfADXFoG0 shows where I got today. I'm still not actually working off a todo list, but it seems it'd be a good idea, sooo I'll be getting to it then. Anyways, the interesting part of this video is probably 0:35, where I force a game crash. I (sort of*) store the game state at the beginning of each turn, so any time anything that happens during a turn causes an exception, I can tell the player what happened - and store the precise state of the game on the very turn before the exception happened, for easy debugging goodness!

* (In fact what's going on is that the game state, and in fact every value used in the program, is immutable. This is how Haskell works in general. It's the same approach as in Clojure, for those inclined for philosophical reading. Anyway, what that means in practice that the only extra cost of storing a "snapshot" of the game state that won't change regardless of what you do in the game is literally just a small amount of memory. I intend to use the same property to implement the "undo turn" special power later on.)

[Psiweapon]

Hey! H+ roguelike that's sweet!!

Man, keep working on this, plz, h+ sci-fi is cool.

Have you read anything by Greg Egan? he rocks my socks.

[Ari Rahikkala]

Ah, I did say I'd use this thread as a devlog, didn't I? Yeah, I totally had the free time for working on this for hours on end. Still, I've had some more time for the problem of procedural interior decoration lately:

http://ari-rahikkala.net/misc/map.html

Here you see a lot of... blocks of letters. The algorithm by which they're laid out is a bit messy, it starts out by drawing every digital line between every pair of doors in a room, then does some whitespace finding and general fuzzification, to produce the "uppercase" set (rectangles that are somewhat "between" a pair of doors) and the "lowercase" set (rectangles that are "out of the way"). Both sets are then subdivided further to bring the blocks to a reasonable size range (currently 1x1-5x5).

The plan is to make by hand a bunch of furniture layouts to replace those small blocks. The uppercase blocks can simply be replaced with any random furniture layout and have everywhere in the room be reachable regardless. The lowercase blocks are a slightly more complicated matter, they have to check for entrances to see the layout isn't putting a cabinet in front of the door or something. But there isn't a lot of essential complexity that needs to be added anymore.

... I swear I know what I'm doing, I just want furniture so that I can implement the "with cover as a significant element of gameplay" part of the plan. Well, actually, "with concealment as a significant element of gameplay", most furniture doesn't really work very well as cover against even small arms fire. In my experience, sprinkling single items of furniture about randomly produces incredibly ugly layouts, and while mine is by far not the only approach I could think of, it seemed like the one that could most reliably produce lots of different content while having just enough compelling structure to look like it was created by human beings. But I'll have to finish implementing it to see if that's true .



I've read my Egan, yeah. Neural mods from Quarantine will certainly show up once I get to that point (including Ensemble )