Archive for the 'dicey dungeons' Category

Dice related stuff

Hello! It’s been a while! Let’s catch up! What’s been going on?


More Dice Stuff

For now and probably for a while to come, pretty much all my news is gonna be Dicey Dungeons related. ¯\_(ツ)_/¯

This last month, in particular, has been really full on. It feels like a lot of people are discovering the game for the first time right now! This is probably because of some combination of our IGF nomination (😊), our new gameplay trailer (below), and word of mouth now that we’re getting closer to finished.

But, far more than anything else, I think lots of people are discovering us right now because of Angory Tom and his awesome youtube series on the game (above!). If that includes you, hi! Thanks for checking out the game!


We went to PAX South

Ahhh, I’m back from my first ever PAX! (Check out our new gameplay trailer that we made for the show!)

I’ve exhibited my work at other shows in the past, but PAX was something very different. For one thing, it’s way more player focused than other conventions I’ve done (which have generally been developer focused).

And it’s huge – people kept telling me that PAX South was “the small one”, but it’s easily the biggest convention I’ve ever been to. It had what felt like an acre of *just* tables for people to play board games on. I heard there were talks and a jumbo stadium sized cinema screen somewhere too, but I didn’t even see that side of things.

I had a lot of fun demoing our game there! We had a *lot* of enthusiastic players come by and check it out, and took a lot of playtesting notes that are gonna make the next version of the game even better. Can’t wait for PAX East!


We’re hard at work on v0.16

The next version of the game is coming out pretty soon! I’m aiming sometime early February for this one, but no promises 😛

For this version, the focus is on finally introducing some light story elements into the game. I was a bit worried about this step at first, but seeing how well it’s coming together, I think everyone is gonna like it a lot. The story is really helping the whole thing feel more connected and complete, without feeling like it’s in the way.

I’m also tackling on a lot of design stuff for this update, most importantly, reintroducing the Jester into the game, and doing a full design audit on the enemies. Also planning to take on as much stuff as I can from this scary list!

It’s really exciting to be this close to completion. I’m not sure exactly how many more alphas we’ll have before the final version is ready, but we’re getting very close.

(usual reminders: if you want to know when the game comes out on steam, then you can wishlist us here! Or, if you wanna try out the alpha version right now, it’s available on itch.io for a discount price of just $7.50!)

* 6 Comments

On a roll

Hey all! Happy new year!

Out with the old

Around this time every year, I clean up my blog sidebar, move old completed projects into annual folders, make room for new things. But last year, for the first time since I started this system in 2008, I didn’t finish any new games. In fact, the only other things I even worked on were State Machine, and a joke jam game, which I didn’t finish.

I’m finding myself weirdly at peace about this. I guess I’m just not in a “small” game phase of my life right now? Maybe that’ll change again in future, but for now, I’m just really enjoying working on this big dumb dice game.

In with the new

In Dicey Dungeons news: we have a new update! v0.15 came out on Christmas morning, and it’s *massive*. It features the quest system, which is the big idea at the heart of the game that I’ve been so excited to finally share. It also showcases the new enemy AI (previously written about in detail here), as well as a bunch of art, tech and design improvements. The whole team worked really hard on this one, and I’m really happy with how it’s turned out!

Finally, I’m incredibly proud our game is up for an IGF this year, for Excellence in Design! We are, I think it’s fair to say, kind of a long shot – but it means a lot to me to even be in the running. I can’t even.

I still don’t know exactly when Dicey Dungeons is going to be finished, but we are into the final stages of development now, and things are starting to fall into place. Gonna be a very busy couple of months for us! Thank you for playing <3

* 1 Comment

When’s the next update coming out?

Hey! So, it’s been a while since the last build of Dicey Dungeons. In fact, it’s been two months. I think it’s time for an update!

First of all, I’m sorry about how long this is taking. In the early days of the project, I was able to commit to updates every couple of weeks, which was amazing. But we’re approaching the end now, and that’s not really possible anymore. I am mostly trying to keep my head down and just focus on the work – but there is a lot to be done. I need to do better at communicating estimates and update plans – I’m sorry about that.

v0.15 is taking a long time because it is not like other updates. It’s foundational. I’m basically taking on all of the biggest, scariest, fundamental problems in the game at the same time. In my post after Day of the Devs, I identified five major issues that I wanted to address in the next version of the game: Story, Tutorials, Enemy AI, Quests, and the final character (the Jester).

Given how big this update is shaping up to be, I’ve decided to split these issues up into two updates!

v0.15 will now focus on the following:

  • Quests: This system is my plan for more playful repeated runs and meta progression, and I’m really excited about it.
  • New Enemy AI: Lots of work done on this recently! See this huge blog post for more info!
  • Basic Tutorial Features: This includes things like tooltips, seeing enemy moves on your turn, animation speed, etc.

While v0.16 will focus on:

  • Finishing the Jester: There’s not much left here, but I don’t want to rush this.
  • Story: We’ve been making a lot of progress on this over the last two months – as a team, we’ve figured out the story we want to tell, and we’re working with a writer to help us tell it. But this is something that’s going to take some time to get right.
  • A full tutorial: The other side of “tutorialisation”, I want to make a really good introduction level that both teaches new players how to play and introduces our story. Again, this sorta thing is really hard to get right, and we don’t want to rush it.

While I don’t want to give an exact date, we are hoping to have v0.15 ready before Christmas.

Thank you for your patience! The whole team is really excited about how the game is coming together, and we can’t wait to share the new version with everyone!

* 6 Comments

How Enemy AI works in Dicey Dungeons

Hey all! For the past month or so, I’ve been tackling one of the biggest technical problems in my new game, Dicey Dungeons – improving the enemy AI enough for the final release of the game. It’s been pretty interesting, and lots of it was new to me, so I thought I’d write a little bit about it.

First up, a sort of disclaimer: I’m not a computer scientist – I’m just one of those people who learned enough about programming to make video games, and then stopped learning anything I didn’t have to learn. I can usually muddle through, but a real programmer probably wouldn’t have approached all this the way I did.

I tried to write all this in a fairly high level approach in mind, so that hopefully the basic ideas all make sense to other non-programmers. But I’m for sure no expert on all this stuff, and if I’ve gotten any of the details wrong in explaining the theory, let me know in the comments – happy to make corrections!

Let’s start by explaining the problem!

The problem

If you’ve not played Dicey Dungeons, here’s a crash course: it’s a deckbuilding RPG, where each enemy has a selection of equipment cards that do different things. Also, they roll dice! They then place those dice on the equipment to do damage, or cause various status effects, or heal, or shield themselves from damage, or lots of other things. Here’s a simple example of a tiny frog using a big sword and a little shield:

A more complicated example: this Handyman has a spanner, which allows it to add two dice together (so 3 + 2 would give you a single 5, and a 4 + 5 would give you a 6 and a 3). It also has a Hammer, which “shocks” the player if they use a six on it, and a Pea Shooter, which doesn’t do much damage, but which has a “countdown” which persists across turns.

One more important complication: there are status effects which change what you can do. The most important of these are “Shock”, which disables equipment at random until you unshock it by using an extra dice on it, or “Burn”, which sets your dice on fire. When your dice are on fire, you can still use them – but it’ll cost you 2 health points. Here’s what a clever Handyman does when I shock and burn all his equipment and dice:

There’s more to it than that, of course, but that’s basically the gist of it!

So, the problem: how do you make an AI that can figure out the best thing to do on it’s turn? How does it know which burning dice to extinguish, which dice to use for unshocking and which dice to save for important equipment?

What it used to do

For a long time, my AI in Dicey Dungeons just had one rule: It looked at all the equipment from left to right, figured out the best dice to use on it, and used it. This worked great, until it didn’t. So, I added more rules.

For example, I dealt with shocking by looking at the unshocked equipment, and deciding what dice I would want to use on it when it was unshocked, then marking that dice as “reserved” for later. I dealt with burning dice by just checking if I had enough health to extinguish them, and choosing whether or not to do it by random chance.

Rule after rule after rule to deal with everything I could think of, and ended up with an AI that sorta kinda worked! Actually, it’s amazing how well this hodge-podge of rules held together – the AI in Dicey Dungeons might not have always done the right thing, but it was definitely passable. At least, for a game that’s still a work in progress.

But over time, this system of adding more and more rules to the AI really started to break at the seams. People discovered consistent exploits to get the AI to do stupid things. With the right setup, one of the bosses could be tricked into never actually attacking you, for example. The more rules I added to try to fix things, the more weird things would happen, as rules started to conflict with other rules, and edge cases started to crop up.

Of course, one way to fix this was to just apply more rules – work through each problem one by one, and add a new if statement to catch it. But I think that would have just been kicking the problem further down the road. The limitation this system had was that it was only ever concerned with this question: “What is my next move?”. It could never look ahead, and figure out what might happen from a particular clever combination.

So, I decided to start over.

The classic solution

Look up AI stuff for games, and likely the first solution you’ll come across is a classic decision making algorithm called Minimax. Here’s a video that explains how it’s applied to designing a Chess AI:

Implementing Minimax works like this:

First, you create a lightweight, abstract version of your game, which has all the relevant information for a particular moment in time of the game. We’ll call this the Board. For Chess, this would be the current position of all the pieces. For Dicey Dungeons, it’s a list of dice, equipment, and status effects.

Next, you come up with a value function – a way to measure how well the game is going for a particular configuration of the game – i.e. for a particular board. For Chess, maybe a board where all the pieces are in their initial positions is worth 0 points. A board where you have captured an enemy Pawn is maybe worth 1 point – and maybe a board where you’ve lost one of your own Pawns is worth -1 points. A board where you have your opponent in checkmate is worth infinity points. Or something like that!

Then, from this abstract board. you simulate playing all the possible moves you can make, which gives you a new abstract board. Then, you simulate playing all the possible moves from those boards, and so on, for as many steps as you want. Here’s an excellent illustration of that from freecodecamp.org:

What we’re doing is creating a graph of all the possible moves both players can make, and using our value function to measure how the game is going.

Here’s where Dicey Dungeons splits from Minimax: Minimax comes from mathematical game theory, and it’s designed to figure out the best series of moves in a world where your opponent is trying to maximise their score. It’s so named because it’s about trying to minimise your loss when your opponent plays so to as to maximise their gain.

But for Dicey Dungeons? I actually don’t care what my opponent is doing. For the game to be fun, you just want the AI do make moves that make sense – to figure out the best way to play their dice on their equipment to make it a fair fight. In other words, all I care about is the Max, not the Min.

Which means: for the Dicey Dungeons AI to make a good move, all I need to do is create this graph of possible moves, and look for the board which has the best score – then make the moves that lead to that point.

A simple enemy turn

Ok, examples! Let’s look at this frog again! How does it decide what to do? How does it know that it’s chosen action is the best one?

It basically just has has two options. Place the 1 on the broadsword and the 3 on the shield, or do it the other way around. It obviously decides that it’s better off putting that 3 on the sword than the 1. But why? Well, because it looked at all the outcomes:

Place the 1 on the sword and you end up with a score of 438. Place the 3 on it, and you end up with a score of 558. Great, ok! Then, I get a better score by placing the 3 on the Sword, done.

Where’s that score coming from? Well, the Dicey Dungeons scoring system currently considers:

  • Damage: The most important case – 100 points for every point of damage dealt.
  • Poison: An important status effect that the AI considers almost as important as damage – 90 points for each poison.
  • Inflicting other Status effects: Like Shock, Burn, Weaken, etc. Each one of these is worth 50 points.
  • Bonus status effects: Inflicting yourself with positive status effects like Shield, etc, is worth 40 points each.
  • Using equipment: Using any piece of equipment is worth 10 points – because if all else fails, the AI should just try to use everything.
  • Reducing countdowns: Some equipment (like the Pea Shooter) just needs a total value of dice to activate. So, the AI gets 10 points for every countdown point it reduces.
  • Dice Pips: The AI gets 5 points for every unused Dice Pip – so a 1 is worth 5, and a 6 is worth 30. This is intended to make the AI prefer not to use dice it doesn’t need to use, and does a lot to make its moves look more human like.
  • Length: The AI loses 1 point per move, making it so that long moves have very slightly lower scores than short ones. This is so that if there are two moves that would otherwise have the same score, the AI will pick the shorter one.
  • Healing: Worth just 1 point per health point healed, because while I want the AI to consider it in a tie break, I don’t want it to be preoccupied with it. Other things are always more important!
  • Bonus score: Bonus score can be applied to any move, to trick the AI into doing something they might not otherwise decide to do. Used very sparingly.

Finally, there’s also two special cases – if the target of the attack is out of health, that’s worth a million points. If the AI is out of health, that’s worth minus a million points. These mean that the AI will never accidentally kill themselves (by extinguishing a dice when they have very low health, say), or never pass up a move that would kill the player.

These numbers aren’t perfect, for sure – take, for example, these currently open issues: #640, #642, #649 – but it actually doesn’t matter that much. Even roughly accurate numbers are enough to incentivise the AI to more or less do the right thing.

Harder enemy turns

The frog case is simple enough that even my shoddy code can figure out every single possibility in 0.017 seconds. But, then things get a bit more complicated. Let’s look at that Handyman again.

It’s decision tree is, uh, a little more complicated:

Unfortunately, even relatively simple cases explode in complexity pretty quickly. In this case, we end up with 2,670 nodes on our decision graph to explore, which takes quite a bit longer to figure out than the frog did – maybe as much as a second or two.

A lot of this is combinatorial complexity – for example, it doesn’t matter which of the 2s we use to unshock the equipment initially, this algorithm considers them as two separate decisions, and creates a whole tree of branching decisions for both. This ends up with a branch that’s a totally unnecessary duplicate. The are similar combination problems with deciding which dice to extinguish, which equipment to unshock, what dice to use in what order.

But even spotting unnecessary branches like this and optimising them (which I’ve been doing to some extent), there is always going to be a point where the complexity of the possible permutations of decisions leads to huge, slow decision trees that take forever to figure out. So, that’s one major problem with this approach. Here’s another:

This important piece of equipment (and things like it) cause a problem for the AI, because they have an uncertain outcome. If I put a six in this, maybe I’ll get a five and a one, or I might get a four and two, or maybe I’ll get two threes. I won’t know until I do it, so it’s really hard to make a plan that takes this into account.

Thankfully, there is a good solution to both of these problems that Dicey Dungeons uses!

The modern solution

Monte Carlo Tree Search (or MCTS, for short) is a probabilistic decision making algorithm. Here is a, uh, slightly odd video which nevertheless explains the idea behind Monte Carlo based decision making really well:

Basically, instead of graphing out every single possible move we can make, MCTS works by trying out sequences of random moves, and then keeping track of the ones that went the best. It can magically decide which branches of our decision tree are the “most promising” thanks to a formula called the Upper Confidence Bound algorithm:

That formula, by the way, is from this very helpful article on Monte Carlo Tree Searches. Don’t ask me how it works!

The wonderful thing about MCTS is that it can usually find the best decision without having to brute force everything, and you can apply it to the same abstract board/move simulation system as minimax. So, you can kinda do both. Which is what I’ve ended up doing for Dicey Dungeons. First, it tries to do an exhaustive expansion of the decision tree, which usually doesn’t take very long and leads to the best outcome – but if that’s looking too big, it falls back to using MCTS.

MCTS has two really cool properties that make it great for Dicey Dungeons:

One – it’s great at dealing with uncertainty. Because it’s running over and over again, aggregating data from each run, I just let it simulate uncertain moves like using a lockpick naturally, and over repeated runs, it’ll come up with a pretty good range of scores of how well that move will work out.

Two – it can give me a partial solution. You can basically do as many simulations as you like with MCTS. In fact, in theory, if you let it run forever, it should converge on exactly the same result as Minimax. More to the point for me, though – I can use MCTS to generally get a good decision out of a limited amount of thinking time. The more searches you do, the better the “decision” you’ll find – but for Dicey Dungeons, it’s often good enough to just do a few hundred searches, which only takes a fraction of a second.

Some cool tangents

So, that’s how the enemies in Dicey Dungeons decide how to kill you! I look forward to introducing this in the upcoming version v0.15 of the game!

Here are some tangential thoughts that I don’t really know where to put:

Those graphs I’ve been showing gifs of? Including this one on twitter:

I created these by writing an exporter for GraphML, which is an open source graph file format that can be read with many different tools. (I’ve been using yEd, which is great and which I can recommend a lot.)

Also! Part of making this all work was figuring out how to let the AI simulate moves, which was a big puzzle in and of itself. So, I ended up implementing an action scripting system. Now, when you use a piece of equipment, it runs these tiny little scripts that look like this:

These little scripts are executed by hscript, a haxe based expression parser and interpreter. This was definitely kind of a pain to implement, but the payoff is great: it makes the game super, super modable. I’m hoping that when this game finally comes out, people will be able to use this system to design their own equipment that can do basically any cool thing they can think up. And, even better, because the AI is smart enough to evaluate any action you give it, enemies will be able to figure out how to do whatever weird modded equipment you give it!

Thanks for reading! Happy to answer any questions or to clarify any of this in the comments below!

(And, finally, if you’re interested in playing Dicey Dungeons, you can get alpha access on itch.io right now, or if you prefer, wishlist us on steam, which will send you a little reminder when the game comes out.)

* 7 Comments

Day after the Devs

Hey! It’s been a while since I posted anything here. Let’s catch up!

Since March this year, I’ve been working on a new game called Dicey Dungeons! You might have seen me talk about it a bit on twitter. It’s a deck-building RPG that I started making for this year’s 7 day roguelike. (I’ve gone a bit over the seven days now, though.)

I’m incredibly excited about this game, and could talk all day about why I think it’s great – but what’s really huge about this project for me, personally, is that I’m doing something that I’ve NEVER done before. I put a team together.

Team Dicey Dungeons is me, and three other full timers – Niamh “Chipzel” Houston on the music, Marlowe Dobbe on the art, and Justo Delgado Baudí on the programming. I’m also getting help from Lars Doucet with steam workshop and modding support, and Dana Trebella, who’s helping me figure out how PR and Marketing works in 2018. Oh, and I’m translating the game into 16 languages. It all kinda just happened, one person at a time.

I feel very lucky. The team is amazing, and I think our game is gonna be great. It’s the most fun I’ve had making stuff since I first went indie, and I think that’s something you can really feel when you play it. I spend as much time playing the game as working on it.

But, occasional gifs on twitter aside, I really haven’t been as good about talking about this game as I should be, and I want to try changing that. So, I’m gonna try blogging about how things are going a little bit more! Here’s what’s been happening lately:


We went to Day of the Devs

I’m just back from San Francisco, where Marlowe, Niamh and I showed the game in public at Double Fine’s Day of the Devs! Marlowe has shown earlier versions of the game before, at local events in Portland, but this was my own first time demoing the game in public.

Day of the Devs is a really fun event! They show 70 or so unfinished games at different stages of development, open to the public, for free. And the line up was amazing! Check out that video, omg!

Dicey Dungeons went down really well. Everyone who played our demo played all the way through to the end, which is honestly a great sign in an environment like this, and we got a lot of really, really enthusiastic feedback. I have a ton of useful notes about improving stuff in the early game that I’m looking forward to implementing.

Personal highlight of the day: a kid, who had played the game twice, dragging their friend over to try it out. I overheard them say “it’s actually really good“! Yay 😀


We’re working on the next update

In the early days of the project, I was doing updates every week, then every two weeks, and then… whenever they’re ready. Open development is still pretty new to me, and I guess this is just how things go when a project gets bigger and more people get involved.

v0.15, our next update, is shaping up to be the biggest update we’ve done yet. We’re finally taking on some of the really big, scary problems with the game that we’ve kept pushing back. This includes:

A quest system! I’ve got this cool idea for a meta progression system that I’m dying to try out. People have talked about wanting more from each playthrough – about making the game longer, or harder – but that’s not the direction I wanna take things in. I want to keep Dicey Dungeons short, snappy and fun – and instead, push the design in other directions – weirder, more playful. A good reference point I think about here is doing a level one run in Dark Souls: it’s not interesting because it’s hard, it’s interesting because it gives you this narrow focus on a subset of the design, and makes you think about the systems that you know in a new way.

Finish the Jester! I want to finally finish up the Jester character, and take them out of alpha. Being so different from the other characters, the Jester’s definitely been the toughest character to get right. They’re getting pretty close to done now, though.

Smarter Enemies! I’ve been working on a new AI system, using the same algorithm as AlphaGO, Monte Carlo Tree Search. It’s, uh, maybe a little overkill for Dicey Dungeons, actually. But it is nice to finally have this problem figured out!

Tutorialisation! I want to finally do some work to improve the early game for new players. This includes new features that make it easier to figure out what’s going on, like tooltips and being able to see the enemy deck on your turn, but also better signalling of what’s happening with animations and sounds and UI, and a short tutorial mode to explain how to play. All this stuff is really overdue!

Story! Or, the beginnings of it, at least. We’ve been putting this off for a while, and we’re not planning anything too elaborate – but we have a lot of ideas about this world we’ve created, and we’re looking forward to introducing some of it in the next update.

I consider all five of those things essential for the next update, and we won’t release it until we have all of them. This means that things are going to take a little longer. Thanks you for your patience!


We’re thinking about the end

There’s an argument to be made, especially with roguelikes, that you can, maybe should, work on it indefinitely, constantly tweaking and changing and adding stuff. I don’t agree with that. Ultimately, I believe it’s best for there to be a definitive, final version of Dicey Dungeons. We don’t know exactly when it’s going to be finished, but we are thinking a lot at the minute about what we want in v1.0 of the game.

If you’re interested in the final version of Dicey Dungeons, the best thing to do is wishlist us on steam, which will notify you when the game’s released:

[Wishlist us on steam]

Thanks for following us through all of this. We’re really excited about this project, and hope you’ve enjoyed playing all the early alpha builds so far! <3

* 8 Comments

Help Wanted: Additional Programmer for Dicey Dungeons

Applications are now closed. Thank you!

Hello all! I’m looking for a programmer for a new videogame I’ve been working on, Dicey Dungeons. It’s a full or part time position for at least two months, and possibly longer. Ideally, you’d be available to start as soon as possible!

Dicey Dungeons is currently available in early alpha on itch.io, and it’s coming to Steam and Mobile in the next few months – i.e. we’re into the last few months of development. You can get the latest version here, or play some earlier free builds here. (Here’s a great youtube video of the most recent version!)

Dicey Dungeons is a three person project right now – a musician, and artist, and me, on design and programming. For the last six weeks, I’ve spent almost all of my time on programming work, and it’s meant design work has come to a halt. I think that’s been bad for the project, and I want to do something about it!

What I’m looking for

Dicey Dungeons is created with Haxe, using my own framework, which is an extension on top of OpenFL and HaxeStarling. I’m looking for someone who’s familiar with at least some of that!

  • Experience with Haxe is a prerequisite.
  • Experience with OpenFL and Starling would help a lot, but isn’t mandatory.
  • Experience with Haxegon isn’t expected.

What kind of work would you be doing?

I’m basically looking for someone to tackle the more technically focused programming jobs, so that I can concentrate on the design focused ones. These jobs include:

  • Optimisation: reduce draw calls, reduce cpu use, and skip unchanged frames where possible to reduce the system requirements of the game and make it run better across all devices.
  • Create a system to automatically create 1080p assets from our 4K assets as needed, and restructure the code so that it can automatically handle different asset resolutions as an in-game setting.
  • Expand the audio tech in the game to increase the range of cool things we can do – we’re really interested in exploring dynamic audio – particularly syncing sounds to music, using real-time filters like reverb, and layering tracks.
  • Figure out a workflow for getting our After Effect animations working in starling fast and efficiently. Potential solutions range from building our own animation tech, to converting the animations to starling friendly file formats.
  • Restructure and simplify the game’s “action” system so that we can implement a minimax AI for the enemies.
  • Do the tech side of getting the game working well on mobile devices (which is mostly about reducing texture memory use – carefully unloading and reloading assets as needed). (I’ll be doing the design side – i.e. resolution independence, UI changes)
  • Work towards making the game more moddable – this mostly means making it possible to load and unload different mods at runtime and creating a system to support that, refactoring existing systems in the game to make it easier for people to create radically different enemies, equipment and characters, and working with the existing modding community to add stuff they might want!
  • Implement platform specific features like cloud saving and achievements for steam, iOS and google play. In particular, I’d really like to add Steam Workshop support.
  • Help out with the more technically focused bugs on this public github issues list.

Money

Payment stuff is negotiable! I can probably afford a rate of £25/hour GBP for two months, but I’m up for discussing more for less time depending on your qualifications and experience!

This job is for someone working remotely online – I’m based in London, but it doesn’t matter where you’re based.

Applications

If you’re interested, you can apply via this google form! Please fill it in by Monday the 3rd of September.

[Applications closed]

Thank you!

Comments Off on Help Wanted: Additional Programmer for Dicey Dungeons

One more week

Hi! I really hate to do this, but I’ve decided to push v0.11 of Dicey Dungeons back by another week. That means I’m now aiming for the 3rd of August. I should have done this last night, but I really wanted to keep to the schedule. I’m sorry. 🙁

The new version is an absolutely huge tech overhaul. We’re totally ditching the old pixel art canvas approach and we’re using 4K art everywhere. Getting this to work has been no small thing, and, if I’m honest, has been something of a learning process for me – it’s not something I’ve ever really done before.

I have a version of the game that more or less works, but it still has some pretty serious tech issues, and I’m very uncomfortable releasing it like this. So, I wanna take another week. Do it right. I think making the game as good as it can be is more important than sticking to what’s ultimately a pretty arbitrary schedule.

I’ve been stressing about this a lot! I’m really sorry! I’m really excited to share it next week!

Edit: Hey. This is taking way, way longer than I expected. I’m basically working flat out to get this finished, but I don’t know when that’s going to be. As soon as I possibly can, is all I can say right now. Thanks for your patience <3

* 6 Comments

Dicey Dungeons v0.11 delayed a week

Hey! Just to let you all know, I’ve decided to push the next version of Dicey Dungeons back a week. This means that the next build, v0.11, will be coming out on the 27th of July instead of the 20th.

I obviously hate doing this – delaying a build is basically a last resort, and this is only the second time since March that I’ve done it. But this is a big, important update, and I don’t want to rush it. I appreciate your patience!

Also, gosh, I’ve been terrible about keeping this blog post up to date! Here’s a recent catch up of Dicey Dungeons related stuff:

  • I finally announced the team! The final version of Dicey Dungeons will feature art by Marlowe Dobbe, and music by Chipzel. The next update is all about finally getting their work into the game, which I’m very excited about.
  • Now that things are getting closer to completion, I’ve stopped releasing alphas for free. However! Alpha versions are still available on itch.io! Buying the game on itch gets you access to the newest alphas, as well as a copy of the finished game.
  • v0.10 is out! This one introduces the fifth character, the Robot!
  • Got a steam page too! Coming soon!
* 3 Comments

Dicey Dungeons v0.8

New Dicey Dungeons update! v0.8 introduces a new class, The Witch!

You can play it here: https://www.terrycavanaghgames.com/dice/8/

<3

* 10 Comments

New Dicey Dungeons build coming on the 8th instead

Hey hey! Had some unexpected things come up recently (including being stuck in an airport for two days!), and it’s really slowed down work on the the upcoming version v0.8 of Dicey Dungeons.

So, I’ve decided to push the next version back by a week! v0.8 will now be coming out on the 8th of June, instead of the 1st.

This is the first time I’ve delayed a build of Dicey Dungeons, and I really didn’t wanna do it 🙁 But ultimately, I think it’s important not to rush the new class. I’m really looking forward to sharing this new character with everyone!

I’ll post a little blog post with details about the new character on Friday to make up for it! Thanks!

* 19 Comments

Next Page »