The Pretty-fication Protocol

Welp, it’s been a busy couple of weeks. So busy in fact I’ve actually not had the proper time to come on down and write a new post. Once upon a time I used to write these after I was finished working for the day, which explains the occasionally morose and loopy tone. But now I’m more like, “Oh, I am sleepy. I will go to sleep now.” You know, it doesn’t matter. I’m here now and I am happy as a clam(?) to talk about the current updates for Dungeon Quest: Adventure and Paper Zeppelin. The first is going great, and on the latter I’ve run into a, well, a truly sticky problem.

But, let’s start off with the coolest thing. In our last episode, we talked about how we needed to rebuild the card file, which got me to thinking about writing a software that would let me read data off of a spreadsheet and output my cards. But then I thought that maybe, just maybe, I won’t do that. Instead I went to my local board game developers group (thanks guys!) to ask about other options. After looking into it, the best option was Card Creatr Studio which is, honestly, the hotness. It allows me to combine the card file with a software that allows me to drop art assets and card templates directly. All of that is to say that this is the software that I will be using to create the final cards too. Which brings me to the next thing – the cards themselves, presented for your enjoyment next to the original playtest versions.

Next up, here are some of the cards themselves. You’ll notice that there are some colors at this stage to show off different elemental properties. It’s easy to implement, which is something to keep in mind when working with a graphic designer (who, in Star Frog parlance will be referred to as “The Graphic Designer” when hired).

…and I’m aware that these are not all the same cards. But I’m using free art and, well, you know (although yes, the extra damage clause on Ice Shard is missing on the new card). But altogether, I’m super happy with how the cards are coming together as I rebuild the card file and add new designs as I go. I have a rough timeline of having a full card file on tap by the end of the month. Let’s see how that goes.

Finally, here’s some enemies. Again, not quite the same and you’ll see that the our happy looking Orc friend here is just a demo card for layout purposes. Few things. The blue and gray card icons mean exactly the same thing (how many Player Cards this enemy is worth and how many Loot Cards they are worth). The Skull in the upper left is the BOSS icon, but would have Allies otherwise. The Shield icon (also on the characters) is the Shield Value of the card, and the drop icon is the total HP (I really, really wanted to avoid a heart icon).

Now of course, these have the classic caveat around here that all of these a demo art or placeholder layouts. They’ll all change before Dungeon Quest: Adventure goes out, but this is a lot closer to what the finished game is going to look like, which is pretty damn swell.


Now with Paper Zeppelin in my coding time I’ve been working the parallax effect which looks nice for the most part. The issue is that the ground looks like ass. I’ll explain. I explained previously what a parallax effect is, so I’ll save us all a lot of time here. The issue with the ground is that I have objects that all load at the same time, move at different speeds, will animate, and must line up with each other.

Starting from the top, the background objects all load at the same time since PZ loads them column by column. For the sake of argument, let’s say they are all 32 pixels wide (a standard tile size). That means that tiles at the virtual horizon will move at 1/2 the speed of the foreground (which the load rate is linked to). So Tile A will be 16 pixels from spawn when the Tile B loads in 32 tics. So they will overlap.

This is, bad. Because if they overlap I cannot get them to animate since the animations won’t line up right and it will all look like an NES on the verge of crashing. But that’s roughly the issue in a very dumb nutshell. I have some options. One option would be to change the tic counter for different levels of the background. This sounds not bad, but leads to a situation where the level will finish but only half of the background will have loaded (ie – we’re on tile 300, but due to the out of sync tic timer the horizon tiles are only on 150). This will make it impossible to design things since I won’t really know where anything will actually appear.

Currently, I have a method wherein I scale the objects to how fast they go, which means that Tile A would just be drawn at 16 tiles wide, so when the next bit loads up it will not overlap. The issue there is that the tile is also 16 tiles tall. Which means that maybe, just maybe, for background tiles I need them to be taller than they are wide, with all of the action on the upper half(ish). Hmm, that sounds like a positive idea. Update imminent.

Leave a Reply

Your email address will not be published. Required fields are marked *