Capstone - A Postmortem for Dungeon Restocker

It has been 2 weeks since my last update post, and the verdict is in: Dungeon Restocker isn't going forward to next semester. This is being posted later than expected, because it has taken a long time to write and consider. To be perfectly honest, I'm a bit relieved. Despite the sunny disposition of most of my posts, this project has been fraught with issues, and I'm not sure I could take a second semester of this.

The Project

I think I'm going to kick things off with our meeting schedule. I've always been a supporter of short, infrequent meetings that serve to make sure that the team is still on track. Sadly, this was not the case here.
Our meeting schedule consisted of in-person meetings on Tuesdays, Wednesdays, Fridays, and Sundays every week. Each individual meeting lasted between 1 1/2 and 2 hours, resulting in the team spending about 6 hours a week on meetings. Note that while we did meet on Wednesdays in class, this was not the Official Wednesday Meeting. That one was about 5 hours later. By the way, I live about 15-45 minutes from campus, so I spent an additional 3 hours a week in transit because of these meetings, tallying up to a personal total of 9 hours a week spent on these things (although, only 6 were logged).
On the day that our team was cut, we spent almost 2 hours in an online meeting, in which we made the decision to have a meeting the next day in order to make the actual decisions we wanted to. This meeting lasted 3 1/2 hours. That's right, we spent 5 1/2 hours over the course of 2 days making decisions that didn't actually matter. I think this little anecdote best describes our team's decision-making process.

Next I should probably address the game itself. Dungeon Restocker's design underwent numerous changes as we worked on it, and I don't think all of them were good. I think the main problem with the design can be summed up simply: There are two games in this concept that oppose each other. My view of how the game ought to function differed from the rest of the team, and I had difficulty seeing the value in their concept. To some degree, this is my own problem, but I'll try to address each evenhandedly so that you can decide for yourself which direction is more engaging.

Concept 1

The team's concept is that of a slow, methodical game. The player acts as a sort of hidden caretaker for the Hero, taking time to prepare the 'perfect experience', and then watching and waiting as the hero goes through it. An infinite number of heroes pass through the dungeon, but there's a long break between the exit of one and the arrival of the next. To end the stage, the player must complete certain objectives, usually making the heroes do a cumulative X of Y (e.g. loot 20 chests, kill 10 monsters, etc). Hero emotion is treated more vaguely, instead relaying various needs to the player (This hero wants loot! This hero wants to fight things!). Making heroes happy is a secondary objective, which rewards the player with resources.

Concept 2

My concept is a fast-paced, frantic juggling act. The player must constantly sneak around behind the hero's back, resetting traps, closing doors, and refilling chests without being noticed. A limited number of heroes enter the dungeon at timed intervals, such that in a perfect game the previous hero exits just as the next enters. To be successful, the player must prepare while a hero is exploring, while making sure that the current hero doesn't start messing with the old preparations. Hero emotions are given freely, along with the addition of a suspicion/confusion meter that fills if things are out of place. Screw up a hero too much, and they'll start moving and acting more erratically, trashing your dungeon, and ultimately leaving. On the way out, they'll confuse the new arrivals, resulting in a entertaining spiral of destruction where a loss is its' own reward (This is admittedly inspired by the classic Dwarf Fortess tantrum spiral). Making the heroes happy is a secondary objective, but is necessary to keep the show running smoothly.

Who's right? Beats me, but our current concept (closer to 1) was unable to properly convey the hero's needs and emotions, which is what ultimately resulted in our failure.
As a gamer, I find concepts like #2 to be more fun and engaging (Hence the chaos that was Sports Game), but it's entirely possible that the rest of my team was correct here. The main thing that bothers me is that I felt like I was left out of the decision-making process. I could speak, but since the rest of my team had all silently agreed on #1, my input would never be used or even acknowledged.

The Team

 I'm just going to go down the list when talking about my team. Note that I refuse to name any  names here--My teachers will know them already, and I see no reason to call anyone out publicly for anything they did or didn't do.

I should also stress that while I may come off as being rather negative, I really do like these people. Many of them had to deal with external issues, which affected their work, and I don't think they were able to give their all as a result.

Producer

My producer is the easiest to criticize here. On a 4-person team with 504 hours logged, he has logged 50, and never reached the weekly minimum hours on even a single week. He was absent from the majority of our meetings, and pretty much never did anything apart from the occasional piece of documentation. I understand that he was having issues with other classes and his job, but logging 10% of a 4-person team's hours is rather unacceptable.
I think a team can live or die by it's producer, and this one certainly made things difficult for us.

Programmer

If I had to pick phrase to describe my counterpart on this project, it would have to be "too little, too late". He did good work, but it was always a couple of days later than I expected to see it, and less complete than I'd hoped. If that was all, I wouldn't mind, but he did a rather poor job of communicating in general.
He was prone to disappearing for days at a time, without any warning, and failing to respond to any communications. One time he lost his phone, and inexplicably wouldn't just check the team Slack on his computer like I did for the entire semester. Another time, he was having family issues right before the day of a major presentation, and failed to even send a text (he had his phone this time) informing us of his absence. Instead, we were forced to present with him effectively MIA, only to find out where he'd been that evening.

Designer

 I'm somewhat torn about our designer, because most of the issues I've had with him relate more to the way he acts, and it's hard for me to tell if what he's doing is intentional or just a simple miscommunication. If we had a more active producer, they probably would have had plenty of opportunities to mediate and 'translate' for us, but as it stands I've just put up with his behavior and tried to ignore anything that feels odd or out of place.
Another reading of his actions, the one that I've been considering more lately, is that he simply takes input and criticism poorly. Every time I try to suggest something or point out a potential stumbling block, he immediately gets to work ripping apart what I just said or otherwise attacking my proposals. I initially figured it might have to do with my point above about there being 2 opposing designs, but then I realized that he'd been doing this since long before we decided to go with Dungeon Restocker in the first place. I might even be as bold as to suggest that he's been doing this from the very beginning.
I don't think it's appropriate to discuss any specific instances of this, given that this is such a personal thing and I'm not even sure if he was doing this on purpose, but I'm prepared to give specific examples if asked.

The other issue, which I will go into more detail with, pertains to this old post, or at least the aftermath of it. After superseding me as the team's de facto artist, he proceeded to achieve...nothing. No assets, no concepts, and no documentation. Over the course of almost a month, he modeled and rigged the character base. He finished it a day or two before our final presentation (with no animation), and it never made it into the game. I would be more understanding, but the last time I checked he'd put in close to 50 hours on it. Those 50 hours could've been much better spent, given the state of our game, not to mention that I found out later that he'd never done this before. What this means is that, having made fully rigged and animated humanoid models before, I would've been a significantly better choice for team artist, at least in this instance. I'm over it at this point, but I wasn't happy finding that out at the time. Worse yet, he also proceeded to completely ignore the standards that I set in our art bible when designing our proper level, but also failed to alter any of our art documentation in the process. Rather than talk to the team and make changes to the art direction, he simply chose to ignore it.
At the time this all bothered me quite a bit, given how abruptly and confidently he took on the position.

Me

I'm certainly far from blameless. For instance, most of the issues that I've had with our designer and other programmer are caused by my own perception, and it's quite possible that the others disagree. I also held on to my beliefs about what was best for the game, despite the fact that my team felt otherwise. All of these factors made it difficult for me to get excited about the project. I put in exactly the amount of effort I needed for a decent grade, and no more, because I any passion I had was suppressed by the situation I was in.

Even now, I feel like I'm betraying my team by writing this, but I need to get these feelings off of my chest once and for all. I can only hope that the others felt the same, because I'm not sure I could face them if they read this.

Conclusion

After reading this post over, I really don't know what to think. This is certainly the worst, most negative and venom-filled postmortem that I've ever written, and I don't know if it should be. A few times this semester, I considered the possibility that I might be the problem with this team. Either way, I hope this little insight into a failed project is useful; I think I've learned quite a bit from this myself. Hopefully, next semester will be better. I've found a team that wants me on board, and with any luck that'll work out nicely.

To the West Postmortem, and 10 lessons for next year

Note: For those uninterested in reading too much, click here to scroll to the list of things I learned this time around.

It's a bit overdue, but here's a postmortem for my latest 7drl entry, To the West.
For those of you who haven't played, To the West is a roguelike that discards the typically 'vertical' gameplay of a roguelike where you go down a dungeon floor-by-floor, and instead replaces it with a long 'path' of naturally terrain, scrolling horizontally. While the game is not super-great, I actually think the jam went rather well, all things considered. My game has been reviewed twice, as far as I can tell, and while the reviews weren't very positive I still feel happy with the result. Here's why:

What Went Right

The feedback I received was very close to my own reaction to the game, and I like that.

One of my big goals in with the game was to have an engine that would allow me to create interesting things for players to encounter, and it seems like I was able to accomplish this, at least on the engine side. Of the positive feedback in the game, most of it related to the variety, and the fact that there were some interesting and unique things to be found. One of the reviews mentioned liking the Potion of Lakes, and item that forms a lake wherever it lands. The other mentions liking the occasional pieces of flavor text that vary from area to area.
I also really like the negative feedback. Much of it reflects problems and frustrations that I personally had, and parts of the game that I knew weren't very good. This is actually a good sign, because it means that the premise I was working with was sound.

What Went Horribly, Horribly Wrong

Unfortunately, not cool bugs like this one.

BUGS!

This game is an incredibly unstable kludge. In fact, I'm amazed it runs at all. About halfway through, the engine began to collapse under itself in a veritable torrent of segmentation faults. Turns out, when you rush and play willy-nilly with your pointers, bad things happen! You'd think I'd know that by now, but apparently not. Anyway, the result was the loss of multiple cool features, as well as hours of good development time. The faction system that allowed for interesting interactions between different units had to be totally scrapped, which is why there are no sheep, mountain dwarves, or other friendly sorts in the world anymore.  On top of that, the lost time meant that I had significantly less time to polish and balance things at the end. I can actually still think of a few major issues with the game, including a game-breaking crash that no one else seems to have noticed.

My other big issue during the week was in fact balancing. At the end, I must've spent close to 5 hours playing the game over and over, constantly tweaking numbers. In the end, I had to stick to a beatable game, but the result was the loss of a lot of interesting strategic challenges and scary early-mid game fights. Instead we just have a boring grind that ends in an interesting but too easy boss fight. With another day, or even a few more hours, I might've had a good shot at making a well-balanced game. However, I simply ran out of time. It didn't help that I had some interesting variety, but there wasn't enough content to keep the game interesting.

The last issue, but certainly not the least of them, was the porting. My first issue was trying to figure out how to cross-compile a console application to Windows. It *should* be so easy, but you can't search for a solution on Google. Due to the nature of the subject, you'll only find tangentially-related topics, making it much harder to learn the process. I then had to try pdcurses, which can handle curses output to a proper window. Unfortunately, this comes with certain issues of its own, which delayed the windows release for way too long. It wasn't until someone left a comment here asking about it that I found the motivation to sit down and fix all the issues and get the build out. On top of that, pdcurses has limits that I didn't expect from the windowed version. (For more information on color limits and such in curses, look here) I don't know why the version that renders text with SDL has a 16-color limit and can't render bold or blinking text, but it's pretty ridiculous. I've heard tales of a patch that removes these limits, but I haven't had time to explore further. The result was a working but half-baked colorscheme that pulled my review scores even lower. (Also, there's the bug where for some reason the cursor won't move in the SDL version, so I had to rewrite parts of the tile targeting code to match. That was extra-dumb).

Lessons Learned

I learned a lot, so this list may be incomplete. That said, here are 10 lessons that I learned during 7drl, mostly the hard way:

1. The panel curses library is pretty great, but next time I need to be more careful how I use it.
2. There are a few other curses libraries/techniques that I ought to learn, especially scroll.
3. With enough care and diligence, it's actually possible to get some fairly decent performance out of curses. I can make it pretty snappy if I'm more careful about my draw calls!
4. If the jam is 7 days or longer, I need to spend more time on architecture and setup. Some of the issues I had might've been better avoided with a nicer structure, and the small amount of architectural work I did payed off nicely.
5. I must stay consistent to my coding style, no matter how short a jam is. If you actually look at my code, it's a mess of naming conventions, which probably slowed me down considerably.
6. In retrospect, switching to NeoVim mid-jam might not have been the brightest idea.
7.  I should get all of my tech working on all of my target platforms pre-jam, even if I already know they'll work later. I should also relese binary demos if time permits it.
8. Before next 7DRL, I should put together a small set of useful utility functions that will make my life easier during the jam. Logging would be extra-useful, as would some form of color palette management.
9.  People like interesting and varied content, and I should reserve at least a day or two for just content building. However, I shouldn't start too soon, or it might end up making more work for me in the long run.
10. Valgrind, everything, always.

I enjoyed last year's 7drl, and I loved this one even more. I haven't made anything great so far, but I think I'm improving well. Hopefully, next year's entry will be really great!

If you read all the way here, then enjoy this little announcement: To the West isn't over! I really like this idea, and I want to see it reach it's full potential. Thus, I'm going to continue working on it until I feel like it's done and polished. Obviously, this will require me to rewrite all of the code, so don't expect much anytime soon, but I figured this was a good time to say it.

AMAZE Postmortem

With this post, the little saga of AMAZE will be over.

It's rather freeing to be able to move on to other projects, but I think it's good to give it a bit of closure first. Normally, when I make a postmortem like this one I list what went right and wrong with the project. However, very little went right, so I think it's better to focus on what I learned so that I don't make the same mistakes again. Without further ado, here's the list:

When handling things asynchronously, watch out for race conditions:

This is a big one. It's the source of the stupid crash bug that I can't fix. The issue lies in the engine's scripting. Specifically, the ability to put delays in script. Originally, scripts were executed synchronously, in a single frame. By adding delays to scripts, I introduced an asynchronous element that meant that multiple scripts could run concurrently. This quickly became a nightmare, and eventually led to the bomb crash. Specifically, a delay occasionally causes a bomb to be destroyed while a collision script involving it is running. Because the remaining script is now trying to mess with something that doesn't exist, the game crashes. If I'd just made the script activate a timer on the bomb, the script would run on one frame and naturally would be prevented from running unless the bomb existed. This is the method that I'm going to try next time.

Don't put off art/audio:

For that matter, I shouldn't put off levels either. Because I focused solely on the code for so long, the end of development was just a mad rush to crank out as many assets as possible, and the quality suffered accordingly. Had I been working on the assets throughout the process, the game would probably be much nicer now.

Entity Component Systems are great, but don't forget prebuilt objects completely:

ECS was probably the biggest success of the project, but I still screwed up with it. I made creating levels slow, and updating objects next to impossible by not having any means of making predefined object 'templates' that I could stick everywhere and modify as necessary. Not only did this make designing levels take a long time, it also worsened the final product's polish immensely. For instance, I wanted to make a little ding sound and some sparkles when treasure was collected. However, this would've required me to alter every single bonus in the entire game by hand! Seriously, I'm not even joking. Had I made prebuilt objects possible early on, doing this would've been trivial, and taken 2 minutes at most. Whoops.

Preparation is key:

This rule applies to basically everything related to this project. Had I decided on a concrete art style, the game would've looked better and I wouldn't have had the issues I did(Like how some sprites are top-down, and others are from a slightly angled perspective). Had I planned the engine out more from the start, I wouldn't have had to rewrite as much as I did and the game would have been finished quicker. Had I spent more time thinking not just about what to put in the game, but how to do so, I would've started with a much smaller scope. I could keep going for a while, but I think you get the idea. Without a clear direction, the project became a nasty mixture of ideas that didn't quite fit together right.

Start Small:

When making the first version of this engine, I shouldn't have tried for a major project. Instead, I should have tried to make a bunch of small, varied games. It would've given me a better idea of where my strengths and weaknesses lay, and I could have spent more time fixing and upgrading the engine.

So, you might be wondering what will happen next with the engine. To make things simple, I'm taking a mulligan. I'm going to rewrite the engine from scratch and try to apply all of the lessons I've learned this time around. I'm going to plan more, make more small games, and also try to practice art and sound more. Then, hopefully I can try for a major project around version 3. Finally, I'm going to try and be more open about my work. I'm going to set up a public repository for the project so that others can see and contribute to the project if they want. I'll write more about that soon.

Eh, Screw It! - A Postmortem for Doomsday Darren

Last night I made a tough decision: I'm going to stop trying to port Doomsday Darren Goes Fishing to Windows, at least for quite a while. This may disappoint any Windows users who were planning on trying this out, but hey, at least they got Chainsaw Deathrace. Of course, I do have my reasons for this. The biggest reason is time. At the start of this week, I was already behind schedule, having failed to complete Singularity prior to the jam. With only a month left before it becomes a necessity, I need to complete it and test it now. The cross-compile progress that I was making was quite slow, and I'd already lost a week with nothing to show for it. The last thing I want is a repeat of Chainsaw Deathrace where I decide to make a few simple updates and it becomes an enormous, months-long undertaking. On that subject, I swear I'll get it done eventually. Maybe. With that explained, on to the postmortem:

What went right:

1. The sounds. I realized partway through making them that I'd already made quite a few for previous games, grabbed a couple of those, and saved myself the time of making them myself. As for the music, Peter continued his trend of finishing the music just late enough to make me seriously worried, but not quite late enough to cause too many issues. Still, I think it's usually worth the wait.
2. I got a ton of work done on the final weekend. The amount of productivity was mind-boggling, especially during the final 6 hours or so.
3. As with many of my previous jams, I knew what to cut, and when. I'd wager that's the reason I keep managing to complete these. The game was originally going to be much bigger, and much more open. For starters, you were going to be going underwater to catch things originally. You'd get rumors about Big Red's whereabouts, and you could go to different parts of the ocean to get different catches. Naturally, this proved to be WAY too big, and it took me a while to settle on the design as it is now.

What went horribly wrong:

1. I slacked off early on in the jam, only putting in 1 or 2 hours of work in some cases. I think this was because of the jam's length being a week, so I didn't feel much pressure until the last 48 hours.
2. Despite not getting work done, I wasn't making sure that I got enough sleep either. It didn't start too badly, but I was exhausted by the time it really counted.
3. This was my first time in months using GLUT. Worse yet, I hadn't touched C++ in quite a while thanks to Singularity. Due to that, I made a ton of rookie errors, which led to hacks and weird fixes, which eventually led to the nightmarish monstrosity that my codebase is now.
4. I didn't bother with an IDE. I spent the whole time instead using CMake, even though I hadn't used it much with C++. Had I just used Code::Blocks instead, porting to Windows would've taken an hour or two. As it is, I spent a week and pretty much got nowhere.

What I might've done differently:

1. One of the most obvious things I'd do is try to get more work done during the week. That alone would've allowed me to make a much bigger game.
2. I should've gotten a bit of a start on the engine before the jam began. None of the gameplay, or anything, but it would've let me run into my problems early on, leaving me with more time to create rather than bugfix. Of course, I've always felt a like too much Game Jam prep is cheating, so I can't say for sure that I would actually do that. Still, doing a little project to make sure that everything was working would've been nice.

So, with this over, I'll be back to finishing up Singularity quickly, then I'm going to work on AMAZE and my editor. I'll post on that later.

Looking back: A year of college game programming

Sorry for the late post. I hope the length makes up for that.

It's been a very long time since I last got much work done on a personal game project, and I must say it's a bit sad. Singularity has consumed my dev time, and when that's done I still need to work on my level builder. Since I can't really work on a game much right now, I thought I'd take some time to write about all of the school projects that I never really mentioned in detail. I guess this is going to be sort of like a postmortem for them. I'll write about them in the order that I made them:

1. Game History and Development - Planets of the Plant

This was my first game project for school, and it was a bit of a trainwreck. The original design was for a light-based puzzle game/waiting for crops to grow combination game. However, this being before Chainsaw Deathrace, I had absolutely no idea what I was doing. It certainly didn't help that I was stuck as the sole programmer, AND also ended up making all of the art assets. A few days prior to the deadline, I gave up on figuring out the light mechanics and threw together a quick demo of the growing mechanic in love2d, which actually ended up looking quite nice(because I put in a couple of simple but impressive seeming effects like parallax scrolling).

2. Game History and Development - Octocow: Reckoning

This was our second(and final) project of the first semester. The idea was to make a multiplayer arena shooter that started out cooperative, but could swiftly transform into a human v. human cagematch. In that aspect, we kinda failed. As it is, players never really run into a situation where it makes sense to attack their comrades. I primarily blame the fact that development took slightly longer than I had anticipated, and I think I could've added that in given a few more days. This project was also a bit more challenging because I had to deal with two less experienced programmers who didn't understand how my code worked, but my grade depended on getting them in on the action as well. In the end, I took the easy way out and tossed a couple of easy functions at them, like getting the direction from an enemy to the player.

3. Game Tech I - Untitled maze game

The very first flash game that I had to make, though unfortunately not the last. The general idea was that we had to make a maze game where the player followed the mouse and touching various obstacles, like walls, would kill them. I decided to go beyond that by adding items that you could grab for points, and switches that would open/close trapdoors and blockers. I also tossed in a 'boss' at the end(the wizard guy), and made toss fireballs around. It was a hard game, but I think it turned out to be rather fun.

4. Game Tech I - Untitled Vertical Shmup

For our second project, we had to make a vertical shooter. By the way, you may notice that most of these Game Tech projects are just thinly veiled 'standard tutorial projects.' Technically speaking, we weren't expected to be capable of programming games properly at this point, so this was supposed to be an intro to that. Anyway, I was a little too ambitious with this project, and had to cut back a bit to get it in on time. Instead of a proper level, the game just had an infinite loop of enemy formations. It was also quite hard. Seriously, it was really hard not to die. Remember this entry for when I discuss my final...

5. Game Tech I - Untitled Horizontal Shmup

Horizontal now?

I try to avoid putting memes in this blog, but the opportunity was too good to pass up

To be fair, we weren't supposed to have scrolling in our last game. The thing is, though, I did. That made this project feel a bit redundant. Anyway, this was notable for being my first Flash-less flash game. Instead of relying on that program, I just compiled .as files with Flex, which made this project difficult but simplified future projects. This was more on the bullet hell side of the spectrum, but it was actually winnable unlike the last one. It also featured randomly generated terrain that you could in fact collide with, although the collisions were a bit weird.

6. Game Tech I - Defender!
This was a fairly open project, where the only real requirement was that we had to use Flash's drawing api to make our graphics. I created a defense game where you control a large turret situated a planet and must destroy incoming... red triangles. I also messed around with a very basic menu of sorts, which came in handy for later projects. After every wave, you could buy upgrades for either your health or your damage stat using points gotten in the level. However, health was always a bit useless, since you wouldn't get points from enemies that hit you. To be honest, it was rather poorly balanced.

7. Game Tech I - Hexerpent
Oh god, this game. This one and the next were a nightmare and a half to make. The goal here was to make a simple snake game, so I decided to do something unique by placing it on a hex grid. Somehow, what should have been a fairly simple game became riddled with bugs, and generally sucked.

8. Game Tech I - Leave Black Alone DX
A limited, partial remake of my first ever game jam game, Leave Black Alone. I still can't believe how hard it was to get some parts of this one working. In any sane programming language, this would've been fairly simple. In Actionscript... Well, I still get nightmares about this stuff.

9. Not a game, and not interesting.

10. Game Tech I - 1DP: The 1-Dimensional Platformer
Now THERE'S something fun! This game turned out to be a blast to make, and it felt more complete than most of my other games. As you might've guessed, the project this time around was to make a platformer. I went for a pseudo 1-dimensional look, just to make it a little bit different. All of the action took place on a line, where 'height' was represented by something's brightness. The visual aesthetic made it hard for other people to play, but it was still pretty cool.

11. Game Tech I - Untitled Final Project

Man, I love this game a little more than I should. The professor gave us complete control over what we wanted to make, so I chose to go with another bullet hell game. This one, however, was much better executed. It has sound, music, lots of enemy variety, 2 levels(with 2 unique bosses), and enough difficulty that I might be the only person on the planet who's actually competent at playing it, and even I'm stuck on the final boss! Anyway, I'm somehow drawn to playing this game even after  finishing it. I'm considering  remaking it sometime, and putting the result up on the blog. The downside: I'm still wicked burned out from making this, and I may have temporarily messed up my hand from all of the testing.


So, that's all of the crap that's prevented me from working on personal projects! 11 games(plus 4 from game jams) in only 8 months seems like a pretty good result. Next year promises to bring even more with it, and I'm considering posting about the next game projects(and maybe putting them up). As a final unrelated note, I'm trying to finish the next version of Singularity before going back to other projects. After that, I'll get version 1 of LevlEd up and running, finish AMAZE, and hopefully have time left to work more on Chainsaw Deathrace. Someday, that game will be back in production! I hope.

Another week, another jam

This may not have been too obvious, but I mentioned wanting try the 0 Hour Game Jam some time ago. Well, the day was today(at 2 am). I would call it a success of sorts. (You can play it here, the name is Zombie Delinquent Shootout)

Here's how it went:

 

What went right:

• The concept
• I came up with something simple right before the jam began. This was very helpful, as I knew exactly what had to be done.
• The engine
• My engine worked quite well! I've really come a long way from when I was using love. 
• The graphics
• I drew them quickly, but they didn't turn out as poorly as I had expected. still not great, but whatever.
• The new scaling algorithm
• I rewrote the code for scaling images literally just minutes before the jam started. Sprites now scale from an origin point(default center) rather than the top-left hand corner. Having said that, it's not perfect. I'll need to play with it a bit more.

What went wrong:

• The graphics
• As nice(ish) as they were, I spent far too long on them. It made the coding more rushed than it had to be.
• The RNG
• It would either always show your cat, or never show your cat. There was no middle ground. I opted for never in the end.
• Porting
• There is no Windows version. I considered compiling the game not to be a part of the jam, so I did it afterwards. After 30 minutes of fighting the compiler, and only getting a white screen, I gave up. I may revisit this, but not right now.
• I ran out of time
• I still made a game, but 10 minutes more would've really helped.

Oh, yes! Here's a screenshot full of Zombie Delinquents! Yes, their arms are guns. No, they cannot fire them. I didn't code that in time. :(