I’ve been spending a lot of time thinking about the concept of power, especially in terms of Dungeon Quest. I recently ran a playtest, and one of the things that I was interested in was the concept of leveling up, especially since I had instituted a test rule that stated that if you trashed 3 cards that shared a color, you could add a Level Up card to your tableau. Level Up cards allow you to increase the total resources of a color that your have available, as well as increase you available HP.
Well, my playtesters do what they do, and they managed to game that particular system in a way that I had not anticipated and had managed to create streamlined decks very quickly and basically drop their entire hand with impunity. The limiting factor quickly switched from being the total resources available to instead being the total cards available to play.
This got me to thinking about, well, power and asking rhetorical questions. What does a late game Dungeon Quest deck look like? Is it more about being able to throw 4 cards that all cost 3 in one turn? Is it about being able to use single cards that cost 8? And if so, what sort of effects would an 8 drop have, and how would that effect the balance of combat?
So starting with that last thing, I don’t really like the idea of having ultra powerful effects that can probably end an encounter by themselves. There’s a word for when you shuffle, draw a card and go, “I guess we win,” and that word is boring. A big old 8 drop is either so powerful that it renders the core game loop irrelevant, or the sort of things that could survive such a hypothetically ass kicking would also be the sort of things for whom all of the other cards are basically moot.
That also means that for my part, designing cards has just become a lot more difficult. I’ll explain from the top. So if we are going to work under the assumption that an end game deck for Dungeon Quest is based around the idea of throwing around multiple 4 drops per turn, then those 4 drops need to be pretty damn good.
And since the difference between two 4 drops and two 3 drops is two levels in the same color, then there needs to be an obvious step up in power between those classes of cards. I’m not just talking about efficiency either. A hyper efficient rare 3 drop should still never be confused for a lower power 4 drop. But, that means that I cannot simply create cards that outclass everything once you start getting up a few levels. Those 3 drops needs to be good all the way to the end game. It’s no good if half your deck turns to garbage because your group is fighting a higher class of monsters. That, of course, is without getting into the 2 drops. After all, two 2 drop effects <> one 4 drop.
Further if I’m going create 6 drops, then those cards need to be exceptionally powerful, but also very narrow or situational. Something like, for Green – Destroy all Non-BOSS with a status effect. That’s really good, especially for 6, but it also needs a bunch of setup, so it might be worth it. At the very least, that would be the ballpark that I ought to be playing in when it comes to those kinds of effects.
So to sum it up, I need to find a way that I can create obvious tiers in power, while also having cards that are useful at all points in the game (for the most part – the cards in a player’s Starting 6 are not very good by design). And they need have a more or less flat power level across the colors, so Red can’t be better at 3 than the other colors since it would encourage people to level up in Red until they hit that sweet spot threshold.
The other thing which is somewhat obvious, is to find a way to functionally limit leveling. Being level 15 is bad for the game, since it more or less eliminates card cost. I’m thinking that each level costs a different amount of trashed cards, so that eventually it’s just too prohibitive. It would also give back the feeling of accomplishment for beating a boss since it gives you a free level up of your choice. I’ll run some numbers and add that to the next playtest. That and make a bunch of cards.
– In Paper Zeppelin news, I’ve been bashing away porting the project over to Monogame and also, like, making the code work the way that it is supposed to instead of the way that is sort of didn’t. I’ve learned a few things. First of all, if you spend a lot of time not using a C based language, those little semicolons give you murderous rage when you forget them.
Today I went ahead and modified the drawing functions, and started consolidating them into the Core function. A few days ago, before I wrote the last post, I also ported the UserControlledSprite class and the appropriate Update() functions for it. I had some issues getting some stuff to load, and after bashing on it for a while (the Monogame asset pipeline is, to put it charitably – shit) I finally got the thrice damned thing to compile, and there it was – my player sprite animating away. It’s been a while since we’ve seen you buddy, and we’re so glad you could join us.
I’ve become unsure if putting the update logic in Core is the correct move at this point. Right now, the game works (worked) by powering everything through the spriteManager class in the function called spriteManager.Update(). Well, I could put all of the code that lives inside of that function into Core.Update(), or I can just call the spriteManager version of that function out of Core.Update(). They are functionally equivalent, with the notable exception that all of the subfunctions that live in the SpriteManager class would also need to be moved (since they are private, not public – which means that they can currently only be called from within the Class that they live in). I’m unsure if the extra work is worth it at all. I’ll give it some thought when I have spare brainspace.
I’ve also come to grips with some concepts that before I had a limited understanding of, but now make a lot more sense now that I have a lot more context to consider them. For example, in C# the default behavior of a function is to return a value. So imagine that you have a bit of code that you can feed something (like a cookie) and it will process it and give you something back (like a brownie). That’s what’s call a Return function, since it does a thing and gives you a result. Now, you can define the nature of those results, which means that you can use that function like a variable. So let’s consider something like Sum(Integer X, integer Y). Since it is a return function we can treat it like a variable and do stuff like Z = Sum(5,6).
This is all a long way of saying, that C# just assumes that everything is a function like that. Now, in a game, you use a lot of functions (like the ones that power the different classes – previously referred to as “Robot Chicken Code”) that don’t return a function, but instead do updates or work or something. So that means you have to define them explicitly as not a function that returns a value. The magic word for that? Void. Previously I added Void to all of those functions because the game refused to compile otherwise. Now I know why they are needed, which is the difference between knowing that something works and knowing why something works. The latter is way more useful if something doesn’t actually work.
– In website news, I’ve come to appreciate that sometimes older posts are hard to read because I format things like a weirdo, and for the most part have done it the same way since post #1 so I’m not going to change it. I will add these little lines ^though, when I remember. You know, like a compromise. You’re welcome.