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!
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:
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.)
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:
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
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 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.
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.
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
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!
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!
Hello blog readers! Apologies for the boring job post! (If you are not interested in being the new Art Director for Dicey Dungeons, you can stop reading now!)
I am looking for an Art Director for a new videogame I’m working on, Dicey Dungeons. It’s a full time position for 10 weeks, with some part time work requirements afterwards. Ideally, you’d be available to start within the next 3 or 4 weeks!
You can play an early work in progress version of Dicey Dungeons RIGHT NOW – I’ve been releasing early versions of the game as I go. Check it out at https://diceydungeons.com/. (The current version of the game is using my own placeholder art, and is not indicative of how I want the game to eventually look.)
The game’s Art Director would be responsible for every part of how the game looks, from top to bottom, to make the whole thing come together. You’d be working with two other people – me (Design/Programming) and the game’s musician.
What I’m looking for
For this game, I’m really interested stepping away from the 8-bit styles I’m mostly known for, and I would love to work with an animator. I think Dicey Dungeons would look great with animated cartoon characters!
The majority of the work will be animating enemy characters – however, there is also a lot of world design, UI work and also a small amount of cutscene work!
Things I’m into for this game: Colourful. Cute. Newgrounds. Adventure Time. Cartoon Network. Vectory. Animated. Expressive. Simple. Readable.
Things I’m not into for this game: Detailed. 8-bit. Retro. Pixel Art. Videogame. Noisy.
This might be a good match for you if: your style fits some of the things I’m into above. You’ve got some experience with both character design and animation. You’re happy working remotely. (If you’re around the UK it’d be great to have team meetings in person occasionally, but I don’t have a good space for you to work out of!). You don’t need to have been involved in making a game before, and your standard working hours don’t have to be UK hours, but you do need to be able to work on the game more-or-less full-time.
A Challenge
Here’s the biggest art puzzle in Dicey Dungeons:
The game is really UI heavy. One of the big things the game’s art director is going to need to figure out is how to make this screen look and feel great, because it’s what the game will look like 90% of the time!
Time
I estimate that this job is about 10 weeks of full time work, and then a couple of weeks of part time work. Here’s the actual list of work involved:
– Monster designs and animations (there’s a LOT of this, dozens and dozens. It’s mostly this, tbh)
– Player character designs and animations (there are six of these)
– Overall design, concept work, figuring things out
– Art for equipment
– Art for UI
– Art for combat stage layout
– Art for exploration stage
– Some cutscene stuff
– Meta stuff – icons, store page art, etc
Money Stuff
Alright! So, I have a budget of around £10,000 – £12,000 for this project. Over ten weeks and including some part time work after, that works out as a day rate of £200 per day. I would strongly prefer to make this game without the help of a publisher, if I can, so I can’t really go very far outside that budget.
Also: I am very open to having a conversation about revenue shares, and about finding a balance between revenue share and day rate. (I actually really like the idea of revenue sharing, as a way to, you know, stake your claim in the thing, make it something you OWN a bit of, rather than something you’re working on.)
Finally, I’m happy to talk about paying some amount of this upfront, as a way to secure your time and commitment to the project.
(My expectation would be that all work done under these terms would be exclusively for Dicey Dungeons, and not for any other projects or video games.)
Applications
If you’re interested, you can apply via this google form! Please fill it in by Monday the 4th of June.
So. For nearly three months, I’ve been working on this thing. And it’s still early days.
However.
I believe Dicey Dungeons is shaping up to be one of my best games.
So, it’s time I made some decisions about where this is going!
In order to tell everyone about it, I have conducted the following interview with myself! My Dice mascot will be asking the questions. Here goes!
Are you going to sell this game, or is this another free thing?
I’m going to sell it! Dicey Dungeons will be my third commercial game.
Ok! What platforms?
I’m probably going to initially release the game on Steam. After that, I’m going to look into doing mobile releases on iPhone and Android shortly afterwards.
How big is this game going to get? How much work is left?
There are currently three playable classes in the game. In the final build, I’m hoping to do six in total. Six seems to be a lucky number for me.
You can also expect the final build to have a LOT more polish, much better balance and a lot more content. Once I have the six final classes, my focus will be on making those as good as they can be.
I’m expecting the project to take another three months or so, so you can expect the final version later this year!
Is it just you, or are you going to work with other people?
This project will be a collaboration! I’m very soon going to be teaming up with an artist and a musician to bring everything together.
I’ve already found an amazing musician for the project (more on that soon), and am currently searching for the right artist. (more on that soon too.)
Are you going to continue releasing public builds?
Good question! Since this is going to be commercial, at a certain point it makes sense to stop releasing builds of the game for free. I’m not really sure when that point should be, but probably before I have all six classes in there. So, probably within the next month or so.
It’s been amazing, sharing builds every two weeks, warts and all. One of the big reasons this whole thing has been going so well is because that process is so good, and because I’ve lucked into an amazing community of people (on my discord, here!) who are playing each update, and giving me amazing feedback on it. Everyone who’s been part of that community before this blog post will be getting a free copy of the game, as a tiny gesture of appreciation.
Are you ever going to have non six sided dice? How about d20s?
Terry
