Friday, October 4, 2013

Worldgen and dungeon variations in Pugnacious Wizards 2


I want to share the basic world generation algorithm used in Pugnacious Wizards 2 and some things I did to add as much replayability, variety, and interest to the world generation. Hopefully you can try some of these ideas in your roguelikes.

In case you haven't seen it yet, the game takes place in a densely packed single level castle that's made of a 9 by 9 grid of 7 by 7 rooms. Here's an example of what the entire game looks like on the first turn without FOV applied:

Here's the basic algorithm that Pugnacious Wizards 2 uses to create a level. It can be adapted to other roguelikes too:

  1. Start with a perfect maze. A perfect maze is a maze with no loops - there's one and only one way from each room to each room. This means there's lots of choices since most rooms will have two or three doors that you can go through. This also means there's lots of dead ends. There's a ton of great resources on the internet about maze types, maze making algorithms, and maze solving algorithms. I don't think dead ends are fun so that's what the next step solves.
  2. Add extra connections. Decide how many dead ends you want to have and as long as there are more dead ends than that, connect a dead end to a random neighboring room. I choose to make each dungeon have up to 12 dead ends - each with it's own treasure. Three dead ends have amulets that you collect to win, six dead ends have a spell that you can pick up, and the remaining few dead ends have heart containers that will heal you.
  3. Place themed rooms. Now that all the rooms are connected, assign a random theme to each one and place them on the actual map. There's about a dozen themes: empty rooms, wall traps, floor traps, courtyard, treasure room, portal room, etc. Most rooms also have extra walls that follow a preset pattern and maybe a few randomly placed wall tiles. Trees are also added. This adds a bit more variability and tactical options. You can hide behind walls to avoid traps and burn trees to damage others or yourself. Room themes that include treasures, traps, guards, archers, or wizards will also place those at this time. Finally, each room has a very small percent of being a special version: a courtyard will be completely filled with trees, an empty room will be filled with skeletons, a trap room will have far more traps, etc.
  4. Place regional themes. Each treasure room with an amulet is guarded by a fire wizard, a poison wizard, or an ice wizard. That room and three rooms joined to it are rethemed with the appropriate element: all the traps are changed to that element and visible floor traps are placed in the corners of each room. Also the element is applied to each tile; water gets frozen or poisoned, grass and trees get burnt or poisoned, etc. This means you can tell when you're close to the amulets and is sort of like a mini-level in the dungeon. Most games have ice levels or fire levels and this is one way to get that same feeling in a single dungeon. In the above example picture, you can see how the poison region near the center of the castle has greenish poisoned water in one room and the fire region in the upper right of the castle has grass that's on fire. If there were any towers or traps then they would also be themed.
  5. Place extra stuff. Additional gold, blood, bone piles, and see-through wall tiles are added at random.

So that's the basic algorithm. A perfect maze with extra connections, treasures in the dead ends, themed rooms, themed areas, and extra loot.

But that's not all that happens. The real variety comes from tweaking the worldgen algorithm itself.

Tweak the variables. These variables include what percent of grass tiles are trees, what percent of walls that have see-through tiles added, what percent of doors are unburnable stone doors, how many extra room connections are added, how much total gold there is, and a few other things. In the above example picture, you can see how trees are common in the courtyards and as decorations in other rooms.

Tweak the lists. It starts with a list of every room theme: 12 or so in total. Then a few are removed at random - they won't show up in this game. Then a few are chosen from the remaining at random and added to the list again - these themes will show up more often than others. This small difference means you can play a few games before seeing each theme. It can also change the feel quite a bit. A dungeon with lots of portals plays differently than one with no portals and a dungeon with lots of anti-magic rooms plays differently than one with lots of trap rooms or lots of creature rooms. In the above example picture, you can see how there are plenty of archer barracks but no guard barracks: they must have been removed from the list of room themes.

Apply explicit variations. There's a list of 30 or so variations. Two, three, or four are picked at random and applied to the map and added to the subtitle. Some variations just make one room theme far more common by adding it to the list of themes 9 times, some will change the stats of archers or guards, some change how much damage is done by fire, ice, poison, arrows, or melee, and some have other small effects like changing the prices of spells, how large explosions are, etc. A game where skeletons regenerate in only a few turns is very different than a game where fire traps are far more common and do double damage. In the above example picture, you can see how archer barracks, which have an "a" pattern on the floor, and portal rooms, which have a glowing block in the center, are far more common than other rooms. These variations also affect the subtitle.

Monday, September 30, 2013

Pugnacious Wizards 2 retrospective

I did it! I spent six weeks on remaking and improving my 7DRL Pugnacious Wizards. Time for a retrospective.


What went well.
  • I finished. I picked ambitious goals, a deadline of the 2014 ARRP, and actually did it. I've started a lot of programming projects but finished few of them - it feels good to finish a project.
  • Cleaner magic code. The code for the magic spells is much cleaner than the 7DRL version.

What went poorly.
  • Screen size. It's supposed to be played 800x640 like at the website but if you download it and play it in the standalone Flash Player, you can resize it and get some ugliness. I remember that happening with the 7DRL version, but I guess I forgot to display a warning if it is at an unexpected resolution.
  • Separating objects from their display. I tried to really separate the objects and the display of the objects. The tiles, items, creatures, effects, etc don't say what symbols or colors they display with.  I figured it was ok for them to know that but I wanted to try something different and see if it's really cleaner to make the objects not know anything about their display. For PW2, the WorldDisplay class has a few giant switches and a bunch of if statements to determine what the background color, foreground color, and glyphs for each object in the game is. It's a mess but I tested a hypothesis and learned my lesson: don't go overboard with separating the objects and their display.

What should be done differently next time.
  • There were a few weeks where I was throwin' out features every other day and times where I'd go a few weeks with only one update. Maybe having monthly goals would help smooth that out. I don't know if that was a real problem or not though.
  • Parameterizable tiles. I really pushed the Tile class to the extreme and it got ugly. The tiles are all single instances of things like light_floor, dark_floor, tower, ice_tower, fire_tower, etc. I made them all the same instance for performance reasons and because that's what I'm used to but I'm not sure if it's worth it. Maybe I should have made each tile a full fledged object oriented parameterizable object instead of something like an enum.
  • Feedback. I got some feedback but most updates didn't get any at all. I've been posting to the roguelike development forums and trying to get more visibility. I'll contribute more to other's projects and maybe that will help direct some eyes and feedback to my next project. Game Hunter did do an amazing LP but that was after the final version.


Sunday, September 22, 2013

Pugnacious Wizards 2: version 1.0

Version 1.0 mostly adds variations. Each game you play will have 2, 3, or 4 "variations" added. Variations will tweak how the castle is made; how much treasure, enemies, or other things there are; your enemy stats; or a couple other things. You can tell which variations are in play by looking at the subtitle at the top of the screen.

This is the last planned release of Pugnacious Wizards 2. I'm done with it. I didn't add all the spells I could think of - and there's more that could be done with it - but I think it's good enough for me to move on. I tried some new things in the code as well as some new ideas about magic and traps and worldgen. It's a nice little game and I'm pretty happy with it. My next post will be a retrospective where I'll go into that further.

As always, any feedback is welcome.

github source

download swf

Monday, September 9, 2013

Pugnacious Wizards 2, version 0.8

Version 0.8 adds mouse support as well as several small tweaks and a few new spells.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Tuesday, August 6, 2013

Pugnacious Wizards 2, version 0.7

Version 0.7 doesn't add any major features but manages to tweak so many things so much that it deserves a release of its own. I added lots of little performance improvements, new poison traps, some new dungeon architecture, a few new spells, new dungeon themed areas, and several tweaks to the interface, spells, effects, and ai.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Friday, August 2, 2013

Pugnacious Wizards 2, version 0.6

Version 0.6 adds several new spells, enemy wizards, gold to pickup and spend, and performance improvements.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Tuesday, June 25, 2013

Pugnacious Wizards 2, version 0.4 (now worth playing!)

Version 0.4 adds several new spells - 9 total. There's a bit of a slowdown sometimes, but I'm looking into that.

This is mostly what I want. The next few updates will probably just add content (like new spells) with very few major changes.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Tuesday, June 18, 2013

TDDing yourself into a corner

I've been playing around with Scala lately and while doing the Roman Numeral kata, I ended up with this.

def numeral(i:Int):String = {
  if (i == 0) return ""
  if (i % 1000 <= 900) return numeral(i-900) + "CM"
  if (i % 1000 == 0) return numeral(i-1000) + "M"
  if (i % 500 <= 400) return numeral(i-400) + "CD"
  if (i % 500 == 0) return numeral(i-500) + "D"
  if (i % 100 <= 90) return numeral(i-90) + "XC"
  if (i % 100 == 0) return numeral(i-100) + "C"
  if (i % 50 <= 40) return numeral(i-40) + "XL"
  if (i % 50 == 0) return numeral(i-50) + "L"
  if (i % 10 == 9) return numeral(i-9) + "IX"
  if (i % 10 == 0) return numeral(i-10) + "X"
  if (i % 5 == 4) return numeral(i-4) + "IV"
  if (i % 5 == 0) return numeral(i-5) + "V"
  numeral(i-1) + "I"
}

I did the simplest thing that possibly could work, followed the red/green/refactor cycle, and I even followed The Transformation Priority Premise. There's better ways of doing this, but I think I'm stuck in a local maximum and I'm not sure how to refactor my way out of it. Using a lookup table is an obvious improvement (such as List((1,"I"),(5,"V"),(10,"X") ...) but those funky comparisons make how to get there non-obvious. TDD doesn't seem to point me in one direction or another. I do believe that Test Driven Development often leads to clean and well factored code so this is an interesting case. TDD lead me down each step I took to get here and it's not leading me anywhere from here. So maybe this is the simplest way to write this?

Sunday, June 16, 2013

Pugnacious Wizards 2, version 0.3

Version 0.3 mostly adds help. There's a help screen, an examine screen, and help popups. There's also a few new room themes, but nothing much.

The next version will add several new spells and will — I think — be the first version worth actually playing.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Monday, June 10, 2013

Pugnacious Wizards 2, version 0.2

Version 0.2 adds guards, archers, new rooms, health pickups, better lighting and effects, and many tweaks. I can beat the game about half the time, which means it's too easy. It takes about 20 minutes to play. It's starting to feel like a real game even though it only has three spells.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Friday, June 7, 2013

Pugnacious Wizards 2, version 0.1

I really enjoyed making and playing my 7DRL PugnaciousWizards. So I started from scratch and have made a new one. Or at least some of it. There's only three spells and a bunch of traps so far. There's no help, examine, or explanatory popups. No bad guys either.

As always, any feedback is welcome.

github source

download swf

update the latest version is at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html

Wednesday, April 10, 2013

Pugnacious Wizards Retrospective

Pugnacious Wizards!

Another year, another 7DRL. This year I tired to focus on more interesting traps and more interesting magic. When I could, I tried to include help for newbies and veteran players too. So what happened?

What went well?

Traps. There's basically four traps. Each is different. Some are obvious (the arrow towers and rotating towers) while some aren't obvious (floor traps and wall arrows). Each can be used to hurt others once you figure out how to avoid them. Even though the floor traps were the most boring, it's possible to figure out the pattern for the room and use it to your advantage. So traps become a benefit rather than a detriment. Pretty cool I guess. I had ideas of moving spike balls, retracting bridges, and other wackyness. The basic idea is discovering patterns in your surroundings and using it to your advantage by avoiding the dangerous spots and tricking your enemies into the most dangerous spots. The gameplay is pretty good (I think) and the code is not too bad for a quick-n-dirty 7DRL. One interesting thing is that the World class has a list of functions it calls every turn. Many of the traps were implemented by telling the world to call some function each turn. That means that the items, tiles, and world didn't have to be changed in order to implement traps. Totally OCP. Totally rad.

Interesting magic. This was the first time I really tried making a magic system. I hard coded a lot of things, then refactored to be more reusable. Even though I didn't get as many magic spells as I wanted, it worked. And there's a few emergent effects (freezing yourself when on fire, burning trees near enemies, etc). The code was just barely flexible enough for this 7DRL. I did manage to make use of the Composite Pattern.

Simple enemies, no stats, no items. The focus is on magic and traps. That means the game really only needs a few enemies. A melee type, a ranged type, and possibly a magic using type. The skeletons are just there to force you to move on. The interesting magic means there's less need for stats and equipment. Although I've got ideas about that too....

Help. I added an attract screen where the computer tries to run through the game. It's a good way to show the basics of what's going on. I also added a decent help screen, the ability to examine surroundings and current spells, as well as popups for the first time you see new things - although it must be dismissible for those who don't want to be bothered by it. I think that was a fantastic success. I also managed to make a game that required very few keys (WASD & 1-9) but also allowed different input styles (arrows,WASD,HJKLYUBN,1-9,mouse). None of those things make it a better roguelike, but it was important to me that it's easy to understand and play. That's also why I used ActionScript rather than Java like last year. The low barrier to entry is important.

What didn't go well?

Magic. I didn't get as many spells and effects as I was hoping for. I was planning on having 27 spells total, 18 in each dungeon, and you can only pick up 9. I didn't get that many spells though. 12 total I think. I was also missing many effects that I wanted: push, stone skin, anti-stone, control others, and more. This was mostly due to not really figuring out how effects and such would work together. What I ended up with wasn't flexible enough for all that I wanted - which was quite ambitious. But it wasn't very well refactored. I think it was quickly accumulated Technical Debt that slowed me down. Debt in the sense that I learned about making reusable magic code faster than I was refactoring the magic code.

AI. The AI for the intro screen hero and other wizards doesn't know how to best use every spell that's in the game. They can use most, but even then, it's not always the optimal move. That's ok, but some spells it flat out ignores. That's pretty lame. This was entirely due to how I implemented the magic. I should have thought this out better. Technical Debt strikes again.

What would I do differently next time?

Magic is tough. At least the style that I wanted. I really should have though about it more and have had a better idea of what was needed. I actually tried not to over think it. Maybe I under thought it.

Useless non-contet. Like many 7DRL challengers, I added a lot of useless content that wasn't related to may main focuses. There were probably two day's worth of work that were wasted on trying to make "interesting" rooms that weren't related to traps or magic. That was removed sense it only made the gameplay worse. It seems that I'm always reminding clients and coworkers to focus on what's important yet this time I made that same mistake. Sometimes human nature conspires against us.

Saturday, March 16, 2013

Pugnacious Wizards day 7

Success!

I didn't have time to do much the last couple days but overall, I'm pretty happy with what I made.

I wanted to focus on magic spells that had multiple effects and traps that are more interesting than the standard "randomly take a trivial amount of damage" that most roguelikes have. I think I did both. Maybe not as much as I had hoped for, but I did both. I also wanted to explain more of the game with an intro that auto-palys and help popups. I think that worked very well.

As far as programming goes, I was able to get animations working - which I've never done before. I also tried putting much of the ai into spells so that the hero and wizards know how to cast them. The magic system wasn't as clean as I wanted, but I tried a few new things with that too. One of the coolest things I did was to make it so the world has a list of functions that it calls each turn. Since anything that has a reference to the world can add to that list, new functionality can be added without changing any existing code. Totally OCP. Much of the traps and magic used this.

As always, any feedback is welcome.

github source

download swf

Update: I played it again after being away for a week and noticed that sometimes the FOV isn't calculated at the right time. I think I fixed it.

Update: I started making a post-7DRL version with better traps, spells, and code. Give it a try at Pugnacious Wizards 2

Thursday, March 14, 2013

Pugnacious Wizards day 5

Good progress today:

Fixed some minor animation and timing stuff as well as refactored magic and traps quite a bit. That meant I was able to improve magic and traps quite a bit.

As always, any feedback is welcome.

github source

Wednesday, March 13, 2013

Pugnacious Wizards day 4

Very little progress today:

I had a social obligation which took up most of my evening. I did have some time to refactor the magic stuff. I'm still not entirely happy with how it's set up but now I can start doing more interesting things. Like the a new spell that teleports you then burns your surroundings or spell that freezes everyone near you then blinks you away. I'd like to come up with several spells that have three or four effects each. That's my goal at least.

Also tweaked the creature ai, removed some bad room themes, and other minor things.

As always, any feedback is welcome.

github source

Tuesday, March 12, 2013

Pugnacious Wizards day 3

Some new content today but mostly polish:

I did add a few more room themes but most of my 5 or so hours was spent adding a help screen, an examine screen, and adding popups the first time you encounter major things like new rooms or enemies.

I won't have much time tomorrow but I'm going to focus on adding more interesting traps and puzzles over the next two days. That will leave Friday evening and Saturday to work on more interesting magic.

What do you think? Too confusing? Too simple? Too conventional? Let me know in the comments.

github source

Monday, March 11, 2013

Pugnacious Wizards day 2

Some good progress today:

I added bloodstains and variation among grass and trees. I also got the hero to use magic against wizards who defend the amulet pieces. Finally, I was able to add a few room themes. There are 8 total, but two are randomly chosen to not appear and one is chosen to appear more often than others. The current themes are:

  • An "A" room that spawns archers
  • A "G" room that spawns guards
  • A room covered in blood
  • A room littered with piles of bones
  • A room with some pillars or remains of walls
  • A room that occasionally shoots arrows from one of the walls
  • A room shoots arrows in 8 directions from towers every turn you are in the room
  • A nice outdoor area
I plan on continuing with the room themes and adding more trap effects and triggers as well as some simple puzzles.


I almost forget! You can get the code from https://github.com/trystan/PugnaciousWizards. It's not my best code, and I've had to some odd workarounds since I'm using a few bits of old code to do new things, but it works and some of it is ok.

Sunday, March 10, 2013

Pugnacious Wizards day 1

Here it is:

I made a ton of progress today. I've now got a basic dungeon crawl with a kick ass intro screen. I've got a few days to to make it interesting:

  • Room themes
  • Traps
  • Puzzles
  • Enemy wizards
  • A better magic system

Tuesday, February 26, 2013

Choosing colors for your Roguelike

If you're making a roguelike you need to decide what colors to use. You could stick with the original 16 colors or you can use hundreds or thousands of colors. I don't know much about colors and color schemes but I have some advice on choosing colors for a roguelike. For my 2012 7DRL, I rule, you rule, we all rule old-school Hyrule, I followed three simple rules about color:

  1. The hue should match the real world color. That is; red things should be red and green things should be green.
  2. The saturation and brightness should match how important something is. If it's trying to kill you or it can save you then it should stand out as a bright color. If it's just background - floors, trees, walls - then it should be mostly gray or black so it doesn't get your attention. You can only notice so much at once and you should notice the important things first.
  3. Subtle variation in color is a good thing. Some variation makes large blocks of trees or water look better but too much variation and shading makes it hard to tell if the color is relevant or not. In iryrwarosh, each tree has three different colors. Water, lava, and sand also had some variation. The variation was subtle enough to break up the monotony and allow things like animated water and lava. Possibly too subtle, but that's just fine with me. Just don't overdo it; even if two trees are a slightly different shade of red or green, you should still know they're the same thing.

Overall I'm very happy with how iryrwarosh looked and I think it's due to following these three guidelines. It did take some time to tweak the colors, but it was really worth it. I plan on following the same guidelines this year.

As a bonus, here's the ActionScript that I use to make a color with a specific hue, saturation, and value.

Saturday, February 23, 2013

A* algoritm in ActionScript

Want to know the shortest path from one point to another? If you're making a roguelike then you probably do. You could use Dijkstra's algorithm, but there's an alternative that finds the result much faster. It's the A*, or A Star, algorithm. It's a lot like Dijkstra's algorithm except instead of checking the neighbors of all the currently visited cells, it just checks the neighbor of the visited cell that's the closest to the target. Of course if you already know which one is closest then you don't need to pathfind. Instead you just estimate which one is closest. Even if your estimates are a bit off, you'll still find the shortest path in much less time.

Here's an ActionScript implementation.

This algorithm needs some explanation since it was made by mathematicians - who generally suck at naming variables. That's why there's a g, h, and f cost. The H cost is the heuristic or estimated cost from a point to the end point. The G cost is the actual cost from the start point to a point. There's no need to estimate that because you only calculate this on points that you've visited. The F cost is the total of the two. By only checking the neighbors of the point with the lowest F cost, you end up - in the best case - only checking the points that are in the shortest path. You can change the getGCost and getHCost methods to cause different behavior. Maybe some points cost more to travel through? Maybe moving diagonal cost more than moving in the cardinal directions? Try it and see what happens.

The checkEnding boolean is because in my game people sometimes can pathfind to walls and obstacles that block movement.

It's mostly used for pathfinding but can also be used for carving rivers, roads, or caves during worldgen. You could also use it to tell where someone is probably going to go - useful for placing traps I suppose. Have you seen any interesting uses for this algorithm?

Tuesday, February 19, 2013

Dijkstra's algorithm in ActionScript

Dijkstra's algorithm is a useful algorithm for roguelike developers to know. It basically calculates the distance from a starting point to all other points. Once you know the distances, you can walk backwards from any point to the start. It's great for worldgen, floodfilling, ai, and pathfinding to the nearest something. Dijkstra's algorithm is also the basis for autoexplore in brogue. If you want to know "where's the nearest" of something, use Dijkstra's algorithm.

Here's an ActionScript implementation.

Note that it uses a grid to track parent nodes as well as if a cell has been visited or not. It does this for performance reasons but it's possible to keep a list or dictionary of visited nodes instead.

This implementation takes the start position, a function that verifies a cell can be entered, and a function that determines if a cell is what you're looking for. It returns an array of points from the start position to the end position or an empty array if no path was found. Using canEnter and check functions means that there's no dependancies on details of your game code - which is a very good thing. Passing in your game details means that if you want this to work with land creatures, water creatures, and amphibians, just pass different versions of canEnter depending on who's searching. And since you pass your own check function, you can search for whatever you want. Injured creatures could search for the nearest healing potion. Fleeing creatures could look for the closest tile that isn't visible from the player. Exploring creatures could look for the nearest tile that they haven't seen before. There's a lot of potential uses for this algorithm.

Saturday, February 16, 2013

Field Of View (FOV) in ActionScript

One of the simplest ways of calculating Field Of View (FOV) in a roguelike is also my favorite. There's several different algorithms but I like to keep it simple. Just check every tile within a view radius of the player. If you know how to calculate Line Of Sight, then it's very easy. If the line to the end point isn't blocked, then the end point is visible. Once you can check line of sight between arbitrary points, then it's easy.

Here's a Flash implementation. Use your mouse to see what's viewable from a location.

It's probably the least efficient way to do it - which is why it takes a second or so to calculate. It is super simple to understand and implement though. I also think it looks the best. Not only can this be used for seeing which tiles are visible from a specific tile but it can also be used for seeing what's affected by an explosion or other effect.

Once you have performance problems you can switch to a more efficient algorithm or rely on caching.

Thursday, February 7, 2013

Line Of Sight (LOS) in ActionScript

One of the simplest algorithms in any roguelike is line of sight (LOS). It's basically drawing a line from one point to another and seeing if anything obscures it. Here's an Actionscript implementation of the Bresenham line algorithm (invented in 1962!).

It's not super obvious what's going on. Basically, figure out which direction the line always goes, and how often it goes in the other axis. Then go.

This is the basis for simple field of view (FOV) algorithms and is a quick and easy way of seeing if a tile, item, monster, or event can be seen by the player or another creature. It can also be used to calculate where a projectile will go, corridor generation, or simple pathfinding in open spaces.

I'm sure there are low-level ways to make this perform faster like bit shifting or breaking each octant into it's own function. It could also return an iterator that calculates points as-needed. This would allow really long lines - or even infinitely long lines - while only calculating what's actually needed.

Friday, February 1, 2013

Updates to SocialRoguelike

Just a few small additions.

Apples now grow into trees, trees drop apples, and it's possible to die of starvation or lack of sleep. Wood and dirt are new items that can be picked up, moved, and used to make dirt walls or wooden doors. There's also 60 * 24 turns in a day. The from, at, and to prepositions can include times. This means you could tell your followers to "move 99 apples to the orchard from 11:00 to 13:30" if you wanted to make your own apple orchard.



Reminder: if you want to eat or sleep or do anything other than move, you need to address the command to yourself. like "@me, eat %" or "@player, sleep in my house".

Next I'm going to add seasons, weather, climate, more plants (carrots, grass, cabbage, etc), resources (stone, clay, etc), and terrain (water, mud, stone, etc). I'm not sure how much I'll get done with all the excitement of the upcoming 2013 7DRL in a month or so....

Tuesday, January 1, 2013

Quietly announcing SocialRoguelike 0.1

Here's a little something I've been working on the last 2 weeks.


What makes this different from other roguelikes (that I know of at least) is that you can talk to NPCs. Not through some dialog tree or talk menu or whatever. Instead, you talk to them by pressing [enter] then typing out a command. Not much is implemented yet, but your followers can carry an item, name areas, and change the terrain.

Try the following commands:
    the northern wall is from 5,5 to 75,8
    @Eve, make your house from 3,13 to 8,18
    the stockpile is 20,20 to 25,25
    25,24 is not the stockpile
    move 99 apples from the northern wall to the stockpile
    @Adam make the northern wall
    @Eve give an apple from the stockpile to me

The commands follow this syntax:
<@audience> <subject> verb <number> <object> <prepositional phrases>
"is" and "is not" name, rename, and unname locations; "pickup", "drop", and "move" handle items; and "make" changes the terrain. There's also a few synonyms for most words. The prepositions "at", "from", and "to" specify where the action should take place. For now, if you want to do one of those things you need to specify yourself as the audience ("@me pickup apple"). The language is somewhat flexible with the word order but the vocabulary is still small and simplistic.

When playing, press "?" for details on what your followers understand. This is just version 0.1 so there's no combat, monsters, or anything other than you, Adam, Eve, some apples, and a few verbs and prepositions really. I think the idea has a lot of potential and I wanted to put it out for others to see.

There's a problem where people may trap themselves when making walls but other than that, let me know what you think. After a couple more versions, I'll add it to roguebasin etc.