ruruie

Ludum Dare 51

Witch Contractor Has Enough Ratings Yet Still We Pine For Your Attention (I)

LD51 is drawing to a close and our game, Witch Contractor, has the requisite ratings to score, yet still we pine for your attention. And you know why, don't you? After all, we are all here who have done the same thing and even those who think (wrongly!) that they have birthed an abomination can understand that this is a hunger that cannot be sated. However, if my attempts to pander for clicks is too blatant, I fear that my post will be shunned.

So you want substance in this blog post and I want you to play and rate our game. A transaction then. I offer you an accord: play our game; make our fell child's numbers go up higher, and in exchange I shall show you a glimpse of the spaghettal abyss from which it was spawned.

title.jpg We didn't make it clear but the fiery pink halo is her actual hitbox.

We decided from the start that we would focusing on presentation rather than being different this time around. (Somehow, our 4th game half a year ago, scored 31st in Innovation, which I don't think we will top for some time.) Hence, Witch Contractor is a dumb shooter. Your character faces the mouse pointer, you hold down the button and shoot at things that go zot once you reduce their hp to 0 and you have to do that to all of them fast enough to not game over. The one thing that maybe sets this thing apart somewhat is scale.

Firstly, mobs. It has 11 enemy types and the progression to support it made possible by decent architecture. My partner in crime @alpacalypse has explored this a bit already: https://ldjam.com/events/ludum-dare/51/witch-contractor/solid-architecture-builds-big - I was that horizontal developer. I don't really have a chance to code outside of LD (nor make sprites or music) but the five jams I've been on are where I've learned those things. It's hard for me to solve problems from a blank slate but once I've got a model, I can reproduce it. During most of development, we had three mobs. By about the middle of the second day, Alpacalypse was calling for about four mobs. I was pixeling a clock with squiggly lines underneath it.

no.JPG

I then pixeled up seven more mob sprites, including the infamous Orange.

mobemg.png *Oh how many of you tried to collect it, only to hear the playerdamage sound and find your life hearts draining away. Delicious.*

At that point, I couldn't implement a mob easily - I didn't know how - and our lead programmer was busy with the main game so the issue of how many mobs (and progression) we would have fell to the wayside for the time being. In the end, Day 2 produced a number of things that didn't get implemented like a directional bullet and various ideas coming from me (I wanted beams!) but since I'm not really a programmer, it's hard for me to make things real while the real coder is busy. Not impossible like it would have been two or three years ago, but difficult. I imagine ours isn't the only team faced with this sort of project management issue, especially when I see larger teams that have a lot of sound and art folks but like one programmer who must be absolutely busting the whole way.

So let's fast forward. It's middle of Day 3 and we have 10 hours left.

problem.JPG

At this point, the Dome shoots but doesn't move and doesn't have the movement code. The Tentacle doesn't move. The Blob does move and has the damage on collision and doesn't have the code to shoot even if we wanted it to. They're also different types of things - either Area2D or KinematicBody2D (Godot folks will know what those are). So basically that was a mess and our programmer hasn't had time to fix it yet. I do have time though, so I was going to have to fix it. I tore out all the code from each of the mobs and turned it all into a class.

For all of you proper programmers, a Class is probably just second nature. I'm not a proper programmer. I've been exposed to code for five LDs and a few other occasions and can search documents and copy and paste. What does that make me? I don't know but it took me about half an hour to go from having an inkling that such things were theoretically possible to putting it down in a working form in Godot. I then spun up my seven additional sprites into new mobs. They are still based on two abilities of course - whether or not they follow the Witch, and whether or not they shoot - but they look different and have different numbers. In the end, we went to having a problem that had to be set aside for over a day to the point where, about three hours from release, I decided that we needed an eleventh mob to satisfy the progression through forty levels of play so I just casually doodled up another sprite and then just spun up an eleventh mob in minutes. This was the Flower, which was the last to be added to the game and filled the gap between the early game Dome and the high damage late game Prism.

mob_k.png

So for all of those teams out there with multiple talented artists, many of whom don't think they're programmers but have been exposed to code repeatedly, but relatively few programmers, this might be your ticket to scale. Take the time to make this stuff easy and try to leverage the people in your team who might have spare time but can't contribute with just notepad. You just might end the jam with more coders than you started with.

I think for the next post, I'm going to talk about the level generation but now it time for you to seal our pact. Come! Fulfill your end of our bargain and play Witch Contractor: https://ldjam.com/events/ludum-dare/51/witch-contractor

Ludum Dare 53

WitchDelivr - Actual Proper Sprites

First of all, come play this thing. Rate it. Give us attention and validation!

splash-v2.png

I don't think two years ago when @alpacalypse and I started doing this that we foresaw being where we are right now. Six jams our of six where we manage to produce something reasonably complete and three out of three where we consciously aimed for (and got) clean launches without major bugs. We only had two bugs this time around (one of which has been fixed) and I'm not sure that anyone noticed either before we did. Hopefully, we continue the trend of producing something better and better each time.

I'm the one who does the art for our games but I'm not really a pixel artist. I mostly don't do art outside of LD and whenever the jams come up, I learn a bit more and then just try to muddle through by referencing whatever turns up on google and mimicking what actual artists do as best I can. Traditionally, graphics is one of our team's weakest categories. (Innovation was traditionally our strongest but we swung that so far out of our newbie park with 1001N that we've been actively avoiding it, but that's another story.)

Over the last two games, we identified that the weakness was a lack of art direction. Even though I managed decent art here and there, the different parts never really came together. 1001N (LD50) just had pieces of art placed around to fill the screen resolution and we were using totally default sans serif text and filler bar. The icons were designed to be readable but had no stylistic direction. In WC (LD51), I managed to have a tileset but it only covered the walls and some blood splatters while the background floor was just some Paint.NET filter. The item icons I think were okay but some had black outlines while others didn't. The mobs were just whatever came to mind that could be animated quickly and rudimentarily with Piskelapp and had no real theme and the heroine was 62 pixels tall and didn't mesh with either the mobs or the tiles. I'd given her a glowing ring to indicate her hitbox but the fact she wasn't the same size as her surroundings was still one of the most noticeable criticsms.

For LD53, I made it a mission to improve the graphics as much as I could.

screen-03.png

After the theme arrived, we rapidly settled on the idea of Kiki's Delivery Service with a bit of social commentary set either in a single tower block or a street with multiple buildings. Because the gameplay would be so simple and the setting so small (in fact, we think we underscoped this time around, which is not a complaint many LD teams have I'm sure) the game would have to lean hard on visual appeal, which was exciting but intimidating. About 40 minutes into the discussion I said "Let's just take it on" and from then the ball got rolling.

WitchDeliver would become our first game with "proper" sprites and "art direction". The art direction wasn't much at all. Initially I only gave myself two rules: -I'll use the default palette of Paint.NET and stick to those colours. I don't know why they are what they are but maybe someone smarter than me picked them for a reason. -Pink and Cyan are pretty 80s, punky and cool.

I looked up how one might pixel a witch and found good examples at 16, 32, 48 and 64 pixel height. I eventually settled on 24. The biggest factor was that in order to have a unified art direction, all the sprites should have the same level of fidelity and 24 was the most I felt I could handle and still produce a reasonable number of assets. That was the next rule - people are approximately 24 pixels high and everything else scaled from that. Hence each floor of the buildings became 48 pixels high and so forth. In order to make procedural generation of pedestrians work with the palette, I imported the whole thing into a bunch of arrays by hue and parts with highlights were separated into two parts, one of which would have a colour two darker than that of the other. This all turned out to be a bit of a trick since apparently Paint.NET and Godot don't quite speak the same language as far as colours are concerned. Thanks to @alpacalypse taking over music and the overall mechanical parts being so light, I was in full Horizontal Mode by 36 hours. One window with no variation or open state became four windows with four variations, each with an open state. Two stores and two doors (from which pedestrians spawn or despawn) became ten and ten, which was enough for us to enforce uniqueness during generation. And barren roofs and alleys came to life with multiple layers of doodads. All in all nearly 300 frames of sprites plus procedural generation of dogs, pedestrians and the street, so we managed quite a bit of variety. Most importantly, having some direction to the art seems to have worked well if the comments are anything to go by. Crucially, some of the most frequently criticised assets were the delivery markers and the arrows, which is great because those were hastily implemented prototype assets that we somehow never got around to replacing (with three hours to go, we decided we needed dogs instead). The fact that people caught onto those flaws is pretty affirming.

Okay, I'm done. Go play and rate! https://ldjam.com/events/ludum-dare/53/witchdelivr

Ludum Dare 57

trust

copy.PNG