Sunday, December 14, 2014

Time, weather, and geography on the island

I implemented time, some seasonal weather, and a small bit of geology this week.


Time and seasons. Time on the island is pretty straightforward. One turn equals one minute. 1440 minutes in a day, one day per season, and 12 seasons a year for a total of 17,280 turns per year.

One thing I haven't decided is how to implement night time. I could slowly redden and darken the tiles as the sun sets, shrink the view distance, or maybe do something else. Any ideas?


Climate and weather. Most weather on the island is a mix of calculations and simulation. Idealized temperature, cloudiness, and precipitation is calculated by adding sine waves for seasonal variation.

Sine waves added together.

Throw in a bit of randomness and minor feedback from the island height map and you get some interesting things. For example, the ideal temperature is the sum of a daily cycle, yearly cycle, and a short, medium, and long term cycle. The real temperature also includes elevation, cloud cover, and the previous temperature. Current precipitation is affected by random seasonal variation, local geography, temperature, and where the clouds currently are.

This is all simulated at the map level, which is now a 60x60 grid, and rain and snow are animated on the screen when walking around.
Elevation view of an island.

Precipitation view of an island.

I implemented an auto-turn feature too. It's pretty neat to go the map and watch time go by at about 10 to 15 minutes per second. You can see clouds form and move and drop rain and dissipate. Cold rainy winters, brief dry spells, and warm summer days. It's always neat to try tweaking a variable or interaction and watch it actually work.

Walking through the hills during the most extreme downpour I saw.
I'll skip the implementation details but share some funny bugs from when I was trying different ideas:

  • I tried making the temperature, clouds, and precipitation flow like in a fluid simulator. Nothing fancy, just a super simplified Navier Stokes thing that never quite worked. The island was soon covered in a freezing uniform cloud that was always snowing. Except the tops of the highest mountains, they were a comfortable temperature.
  • I tried implementing clouds as particles that would be deflected by high elevations. The first attempt caused them to bounce off mountains like beach balls and scatter everywhere. I was able to tweak it so that didn't happen and added wind that would nudge them back to their original direction but it wasn't very interesting.
  • I tried making temperature affect cloud formation and have clouds affect temperature. I soon had areas with 2000000% cloudiness and over 1000 degree heat.


Geology. The land generation has been tweaked quite a bit. Also, there's a few different types of land that are somewhat determined by climate. No lakes or rivers yet though.

A transition between dirt to the southwest and grass to the northeast. The grassy area probably gets more rainfall.



Thinking of all the different ways to model weather has ben fun despite all the dead ends I ran into but I'm really looking to this upcoming week and adding some randomized plant life.

Sunday, December 7, 2014

Beginnings of worldgen (with pics) and spinoff projects

I got some basic worldgen done this week. Just creating a bare island and walking around on it but that's not bad for one week starting from scratch with a language I'm still learning.



Building the island's elevation uses a blend of a few different techniques:

First, create a heightmap by throwing down a bunch of sorta-centered blobs with a random height and radius. A percentage of the blobs will have negative height and reduce the elevation. Keep throwing blobs until you have enough land. I think this has interesting and island-like coastlines with and good variation of height. It can be weirdly mesmerizing too.


Using the first heightmap, create a second heightmap based on the distance from the water. I think this looks neat on it's own and when there's jagged coastlines it reminds me of what real mountain ranges look like from above.


Using the first heightmap again, create a third heightmap based on simplex noise. Water has zero height and everything else is a noise lookup.


Once you have all three heightmaps, multiply each by a different weight and add them together form a final height map. By changing the multipliers for each, you can adjust the overall look to get the best of each map with few downsides.


Finally, I want the highest parts to really stand out above everything else so I do one last thing: cube each height (that is, set each height to height * height * height). This effectively pushes the lowest parts down and increases the contrast for the higher elevations.


That looks okay. I'm sure it will change more.
An in-game map.
Each tile on the map represents "chunk" of 30x30 tiles for now. As you walk around, nearby chunks are instantiated as needed based on the overall map. It's blocky and not very exciting though.
Much higher elevation to the west, much lower elevation to the east. One level higher to the south and one level lower to the south east.

I think I can do something like a midpoint displacement algorithm to make it less blocky. Adding up-slopes and down-slopes at elevation boundaries and hiding the interior of the higher elevation should help make it look better too. That should keep me busy for a week.

Edit: It took about three hours. The midpoint displacement wasn't working how I thought it would so I lerp the midpoints and add a bit of noise instead.



Doing all that was almost 350 lines of Clojure so I moved some functionality into separate open source libraries.

super-simple-window: Java Swing windows can have a ton of callbacks and settings that need to be done in a specific order and I always forget how to do it right. This is one function that creates a JFrame with a Canvas that uses all the settings and callbacks you supply: title, width, height, on-render, on-key-press, etc. Even makes a timer if you supply an on-timer callback.

render-terminal: Render terminal-like data to a Java Swing Graphics object. Call render with a map of points to character data. Does a bunch of caching to keep things fast. Supports 9x16, 10x10, and a 12x12 font so far but it's easy to extend.

Monday, December 1, 2014

Announcing an unnamed ambitious roguelike

I've had a few ideas bumping around in my head for long enough that I decided to make a real roguelike. A big roguelike. A wilderness survival, city building, and dungeon crawling roguelike.

Wilderness survival. Largely influenced by Robinson Crusoe by Daniel Defoe, The Mysterious Island by Jules Verne, and the potion identification aspects of other roguelikes. You begin alone on an island with randomly generated regions, plants, and animals. You have to find or build shelter, find safe drinking water, find plants and animals that are safe to eat, and explore the dangerous island.

City building. Largely inspired by the The Sims games, the tougher Dwarf Fortress locations, the Dungeon Keeper games, and various history books such as The Outline Of History by H. G. Wells, A Short History of Nearly Everything by Bill Bryson, and the Foundation Series by Isaac Asimov. Eventually you find other people on the island and form a small town. You have a lot of influence but everyone goes about their business of farming, crafting, building, trading, exploring, adventuring, having families, and slowly unlocking new discoveries. But what happens when your town grows large and diverse enough for powerful families, ideologies, and factions to form?

Dungeon crawling. Largely inspired by Sil, Brogue, DCSS, Nethack and other roguelikes. The island has many caves, ruins, dungeons, and fortresses. Use cool items, abilities, and allies to explore and plunder them. Of course, other adventurers are trying to do the same and some dungeons may send their inhabitants out to raid the overworld.


I know thats just a bunch of words with no details or actual gameplay yet, but I'm excited to start a new project and can't wait to get something playable. I made a new git repo today and I hope to have the first playable version out sometime this month.

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