Monday, January 5, 2015

Having a blast


It's a new year, so that deserves a new post. Last year was a mixed bag. Some things went really well (Ascii Bird and Shogun Assassin), while other things went pretty poorly (Lowest post count for a year ever, generally the entire second half of the year). If nothing else, with a bar so low it'll only make it easier to improve on this year.

The pics today aren't exactly new... I did both of these for donations during Movember last year for my friends gaming group BLAST gaming. He specifically wanted "a crappy pixel logo", "a rip off of a popular gaming site logo... like IGN or Gamespot" and "to incorporate some sanic". Tick, tick and tick.


Monday, October 20, 2014

Sunday, August 17, 2014

4hr Game Jam #1 - 4hr Pong


I had a spare four hours on the weekend so I thought I'd follow through with a plan I had last post. I decide to do a quick little jam to get better at making games in shorter time frames. I didn't want to embarrass myself straight up so I decided to start with something easy.

I figured I may as well start where video games start. I also realised that despite it being the general starting point for everyone learning to make games, I'd never actually made a Pong clone. That all changes now... Play it here.

I'm going to do a post-mortem for it as well but I don't think I need to go into detail as much as the longer jams. Plus this jam wasn't so much about the game as the process of making it. I'll just break it up into good and bad points:

Good:

- I actually managed to finish the coding for a base game of Pong in about 1.5 hours. The break down for the rest was kind of all over the place, but it doesn't really matter. In all, I managed to get more than I planned to do done in the 4 hours, so it's a good start.
- The new thing I learnt this game was how to use fonts properly. Where before I was just making sprites for all the labels, all the text here was done on the fly with strings. It's good but at the same time it's harder to set up composition. I'll need to learn to use these better if I want to do more string related stuff/localistion in the future. Right now, I'm happy to stick with sprites.

Bad:

- There's a weird bug where player 1 can sometimes send the ball out through the top wall. I didn't have enough time to fix it but it happens occasionally. I thought I had enough checks in there that this couldn't happen, so I have no idea why it does. I didn't have time to investigate any further.
- The new feature I thought I'd add (the smash attack thing) didn't really make it harder for the opponent to react. I ended up making it expand the paddle significantly to make it also like a last second save if necessary, but it's still not as good as it should be. It should either let the player pick a corner to aim for, or send the ball to the opposite side than the opponents paddle is on (in addition to the speed up).
- The sound effects are pretty bare bones. I really need to start building up a sound effect catalogue so I don't need to mess around in bfxr ever time I need something.
- I decided to livestream this jam. It went ok, but there were a lot of little kinks that I need to iron out if I'm going to do it again (My headset kept turning itself off, I need a better timer setup, it's hard to talk to yourself about what you're doing for 4 hours).

I'm pretty happy with how this little experiment went. I don't always have a weekend that will allow me to do it, but whenever I can I'll try and do one for the foreseeable future. I think also I'm just going to stick with the timeline of game creation for themes, but if anyone has any suggestions I'll take them on board (as long as it's not a DinoRiders RTS). Next time: Some kind of Space War clone.

Monday, August 4, 2014

Adelaide Game Jam #1 - Post Mortem


So once again I've kind of gone ahead and done a game jam without doing a blog post about it first (or a blog post about anything for that matter). I did live tweet it though, if that even counts.

This time it was for the Adelaide Game Jam being hosted by Jamalaide, which is a 48 (but more like 36) hour jam that's done mostly locally. Previously, I'd also done Ludum Dare with them and produced the abysmal Agents and Assassins, so my main goal was to just do a better job this time. There was also a lot better turnout this time around, almost ten times as many people and roughly 12 games to show for it. All in all it was a pretty fun, if not stressful, weekend.

The theme for this jam was "Reaction". After some internal debate I decided to go down the chemical reaction path. The idea was to make a Bubble Bobble style platform game in which you'd have to stop monsters with chemicals that you could also combine in a reaction to create stronger chemicals to stop bigger monsters. These monsters would then explode, killing other monsters nearby in a chain reaction. I also had really lofty plans of submitting this game for the local multiplayer jam that's currently underway at Gamejolt, so there was also plans to have a second player, and therefore a need to combine shots to get the final colour chemical to kill certain monsters. Suffice to say, a lot of these ideas didn't get implemented into the final game, even though a lot of the mechanics are still built around that initial goal.

If you'd like to check out the final product, it's online here (although, the sound may be a little loud so be careful).

The Good

I guess the best part about What Has Science Even Done For Us Lately? is how much I was able to do in that tiny time-frame. I was a lot more prepared compared to Ludum Dare, so I had a better idea of just how long I had to spend on certain things. The animations are crappy, but they're still there for all of the seven monsters and one player character and with the exception one aspect, most of the mechanics work almost as intended. Content wise, I'd like to think there is more here than the other games in the jam.

Further more, there was still plenty of scope for more levels. I kind of feel I only got out roughly a tutorial, but I would've needed a few more hours there really. The levels I did complete seemed decent enough though. Watching people play seemed like they were a little harder than I had anticipated while making them (even now I can breeze through each screen in a couple of seconds with no deaths), so I dunno, maybe I'm just too good at games. One positive out of the levels that I did get through was the sense of powerless > powerful. Navigating the level without anything to deal with monsters proved challenging, but after picking up the chemical players can then go back through the hard bits destroying all the monsters that previously gave them trouble. That seemed to get the best reaction out of players.

I had also realized that all my previous games featured male main characters (except for Ascii Birds, which is genderless I guess), so I wanted to make a determined effort to make the main character female. Mission accomplished I guess, even though there's not really any characterization about her and her game isn't very good. Luckily there will be more games in the future to improve on.

The Bad

A game made in 48 hours is only rarely going to be amazing, so I don't want to be as harsh on myself as I was with Agents and Assassins. The truth is that I learnt a lot from that experience, and I've learnt a little more from this one. As long as I keep learning more, that's whats really important.

So firstly: While last time I learnt that I really need to drop scopes as much as possible to get stuff done in the time limit, I only partly followed that this time. Realistically, there is a whole lot more I could've cut down here that I kind of ignored because despite the fact it was a jam, I really wanted to make something look like it was a complete thing. That's fine for longer jams, but it's kind of not what these short term things are about. I need to learn that it's OK to not try and be a perfectionist when it comes to these kinds of jams and leave stuff looking abstract if it means more time to make it feel more fun.

Secondly: The most practical issue with the game is the collision detection. Much like last game jam, I got stuck early on trying to code something a lot more complicated than it needed to be. This time I only lost about 3 hours to it compared to the most of a day I lost previously. Despite making two games so far that are kind of like platformers, I hadn't actually made a proper platformer before. Rather than look at how that should actually be done in GameMaker, I just went ahead using whatever I already knew to approximate something that worked. It ended up causing even more problems, so in the end I super simplified it to something that kind of worked enough.

The real problem came the following day when I started adding all the enemies in. Turning on precise collision detection so that you could better jump/dodge enemies meant that you'd interact with the platforms in weird and inconsistent ways. I was already out of time, So I had to decide between a game that felt off or a game that was nearly unplayable at some points. If I had an extra couple of hours, I might have been able to fix it entirely, but at the time I was clueless as to what I could do about it.

I think next time, if I'm doing something that's unlike something I've done before, I might spend 20-30 mins reading an online tutorial before jumping straight into it.

Lastly: The game is pretty boring. There's not really a lot to it, and there's nothing really amazing that happens during it. The levels feel really straight forward and aside from the platforming there's not a lot to the puzzle aspect. Sure, it's technically a game, but it plays it really safe and doesn't do anything that every other platformer before it has done, and that's what really makes it worse. Jam games should always be breaking a boundary of some kind. They should be about stripping back the conventions surrounding games and get the player directly to the new and interesting part. Previously I'd identified that you need to engage the player within 30 seconds of the game starting. Having directly watch people playing my game this time I feel its more like you need to provide them with a "Wow" moment with in half of that. A few minutes into this one and they're still in a tutorial essentially.

The Ugly

Live tweeting this has made breaking this down a little easier:
30 mins - Concept and Design Document
4.5 hrs - Platforming (Running, Jumping, Landing, etc)
30 mins - Shooting
1.5 hours - Colour System (Pick ups, UI, Globs, etc)
3 hours - First tier enemies (Collisions and AI)
1 hour - Win/Loss states/Level setup
4 hours - Player, Enemy, Pickups and Level pixel art
2 hours - Player animation
3.5 hours - Enemy animation
1 hour - UI art
1.5 hours - Background pixel art
30 mins - Glob pixel art
1 hour - Sound Effects
2 hours - Level creation
1 hour - Code tweaks
1.5 hours - Eating
1 hour - Travelling
1 hour - Breaks
5 hours - Sleeping

Roughly:
2.5 hours - Design
11 hours - Code
12.5 hours - Art
1 hour - Sound
8.5 - Misc

Considering there's a lot of overlap between design and coding/arting, that's a pretty balanced breakdown. However, as I was getting at in the previous section, I think for a short time frame jam like this I need to spend much more time on design/code than art. I'm also wondering if maybe I should be trying to have a planning stage at the start now that I'm getting a little better at gauging development time? It seems like it could cost more time than its worth but it might be a good practice to get into.

A Fistful of Dollars

The things I've learnt this time are more applicable to jam games, but they're important to note nonetheless:
- Strip the scope down as much as possible. I learnt this last time and didn't follow through with it. I was trying to make a game that:
       - Could be played single or multiplayer
       - Had seven different enemy types
       - Relied on having multiple levels
       - Needed a tutorial that could be set across multiple levels
That's just way too many things for 48 hours. At the start I should've decided either single or multiplayer and then specifically built the mechanics around that. Rather than have all the enemies be vastly different, I could've just had one sprite that got recoloured and moved differently. As far as the platforming aspect went, it really wouldn't have deviated from the finished game much.
- Make sure there's some kind of "Wow" moment that happens early and can keep happening. It doesn't have to be something big and visually impressive. It can be something funny, or something dumb but surprising, as long as it gets a positive reaction from the player. The best games I played at this jam where the games where just dumb stuff happened all the time.
- Worry less about making something perfect. A short but fun experience is better than a long, thought-provoking one for these kind of jams. It might also be better to try and have something you can technically finish in half/two-thirds the amount of time, and then spend the rest of the time polishing the fun aspect as much as possible.

For a Few Dollars More

As much as I want to make my own Bubble Bobble, I don't think I'll be continuing from this game. I do need to know how to do basic genres in GameMaker though, so sometime soon I'm going to have to work on that.

The other thing is, I'm a competitive asshole. I really want to win these jams, but I need to get better at doing things super quick. However, I can't keep doing jam games because I also need to keep working on something I can sell as well. After watching the Art of Screenshake vid, I had searched for other videos regarding rapid development in GameMaker. I came across Cactus' (who made Hotline Miami) talk on 4 hour game development. It wasn't really a helpful talk, but the concept is interesting.

On the tram ride of shame home, I was thinking maybe I could do a little personal 4 hour jam every weekend/second weekend. I was trying to think of how it would be fair to theme it, and had thought maybe
I could just get a random page from wikipedia and use that as the theme... But then I thought that wont really expose me to more of Gamemaker, so maybe I should pick a random function/aspect and make a game featuring that instead. What if its a better idea to randomly pick a game genre and make a tiny version of that though?

Monday, June 9, 2014

LowRezJam #1 - Post-Mortem


I kind of failed to do a blog posting about it because I'm terrible at self promotion/social media, but I ended up doing something for the LowRezJam. After the Ludum Dare jam I wasn't really feeling too great about game dev skills and I really wanted opportunity to rectify that. I kind of felt like none of the games I'd made so far were very "true to myself" or "an indication of what I'm about", or however a wanky artist would phrase it. So: Shogun Assassin. Where the goal was to make a well presented action game with samurais, because that's what I'm about. Play it here at GameJolt if you haven't already.

The LowRezJam had a pretty interesting limitation: The game could only be presented through a 32 x 32 pixel window. Everything else, like theme, was entirely up to the creator. I like working in pixel art so this was exactly what I needed.

If you've seen many samurai movies, you'll know it's obviously heavily inspired by Lone Wolf and Cub, but also by previous-gen beat 'em ups like Devil May Cry and Dynasty Warriors. Oddly enough there aren't many games based on Lone Wolf and Cub. After I'd finished I found an old arcade game that actually had a bunch of similar elements, but it's not surprising considering the strength of the source material. To be honest, I'm surprised there haven't been more games based on it.

Anyway... on to the standard Post-mortem.

The Good

I'm a lot happier with the overall state of this game compared to my other jam games so far. I think I'm a lot better when it comes to hard restrictions on the end product, rather than restrictions on how it's made. This obviously goes double if the restrictions mean it has to be done in  pixel art, since I feel I'm pretty capable with that style. In terms of volume of sprite work, I'm using slightly less frames of animation than Apex Diver, but I'm reusing stuff better. Background art is more varied as well, I was pretty happy at being able to match so many staple locations from samurai films and have them blend so well into each other. I'm also proud of the little touches like being able to cut down the grass, trees and bamboo. Having to only worry about 32 x 32 pixels at once certainly made it a lot quicker to make more content.

I really wanted to hammer that classic samurai feeling where the player is surrounded by enemies, then in a flash everyone freezes, before all the enemies collapse dead. It wasn't easy to do with only such a small playing area, but I feel like I pulled it off. Using the screen area successfully was also a challenge I like to think I handled well. An action game needs to give players plenty of time to react to danger, so almost every dangerous element was designed to give the player enough time to anticipate and then handle. I'd liked to think there's never really a moment that feels unfair or confusing to the player in this game.

Going into the jam, the biggest improvement I wanted was to make the gameplay simpler and feel better to play. I feel like I've done a lot better this time and a lot of that is thanks to Vlambeer's awesome "art of screenshake" talk. In terms of simplicity, it's certainly a lot easier to pick up and play than my previous games. I'm particularly happy with the in-game instructions and how they convey a lot of information via a small amount of pixels. There is still a lot of ambiguity in this game that I'm going to have to keep working to improve, but I'll cover that later.

This is also the most sound complete game I've made so far. Having such primitive graphics meant I could use old school beeps and boops for sound effects. I also had a chance to mess around with some music programs and make my own music this time, which was a lot of fun. It would've been great to be able to spend some more time on it to give it some more depth and character, but I am most pleased with the way the gameplay music transitions when the player dies.

I think that this is/will be the most well received jam game I've made so far. Its currently sitting at a rating of 4.5, which would be a little bit higher if someone hadn't given me a scumbag 2 rating (It's been nothing but 4 and 5 ratings otherwise). It's also got more views/plays than Scrolls of Candy and Apex Diver combined already, despite me not doing anywhere near as much promotion. It's unlikely it'll get featured like Ascii Bird did, but it's not that high profile of a jam. I don't think it's going to win the jam either, but it should get pretty high. Of course, that's providing the jam ever has a final scoring, which may not even be a thing any more since the host has seemingly given up on it.

The Bad

For the first time in my game jam history, I don't have any major problems with the core gameplay. I think it feels kick-ass and controls in a nice, obvious way. As always, there are things that could be done better, and as always they're kind of things that definitely could have been improved with more time. However, they're not as bad as say, the relative "samey-ness" of Apex Diver, or the confusing rule set of Scrolls of Candy. It's not a post-mortem if you don't address the issues though, so here we go...

The biggest thing missing is probably a lack of obvious goals. During the instructions I do the whole "Survive... Kill" message but it feels too open and doesn't give the player a hard enough objective or long term goal. It doesn't suggest to them how they should do it, where they should go to do it, or who they should do it to. All it basically does is tell them to do the thing they were probably going to do anyway. They already were expecting to hit people, and to try and not get hit back. It's an action game after all. I was aiming for something endless and open, but I think it would've been better if players had some kind of long term goal in mind like "kill 200 samurai" or "get to the Shogun's garden". Something that gave them a hard target to aim for (or ignore, depending on the player) which can then also provide a platform to gauge their progress against while playing.

Secondly, there's a problem of the player being a little too powerful and how that shapes the way they play. I really wanted players to feel like an unstoppable slicing machine, allowing me to just keep tossing more and more enemies at them to balance things out. I was really lazy and didn't want to do individual attack animations while running or standing or jumping. I basically implemented in each key press results in one slash, but it happens so fast the player sprite doesn't change. It felt great, but it had the knock on effect of making it too easy to just run along and hammer the attack button with no consequences.

I tried some things to limit the players ability to attack freely, like having a stamina bar or adding a recovery time, but it made the gameplay feel really bad. It wasn't a concession I wanted to make, so in the end I added 3 new systems to try and force the player to stop running and stop attacking: the arrows, the supers and the ranking system. The arrows did their job pretty well and I'm pretty happy with how they worked out. However, the instructions for the super didn't explain well enough that you need to stand still and not attack to charge the super. Similarly, the ranking system didn't get explained at all, so any effect it was supposed to have was lost unless players were replaying.

Both of these issues have a couple of different ways to fix:
For Supers:
- Change the instructions to include a message for "Stand Still / Don't A / Charge/ S = Super". This is probably the strongest change, but I was a little worried the instructions were too long as they were.
- Rework the instructions to only pass once player has demonstrated they could follow the prompt (i.e. dont move past the attack instruction until the player has pressed A). This still runs the risk of players not understanding what was going on and getting stuck and frustrated.
- Starting the player with full super bar, allowing them to call a super when the instructions tell them the buttons, displaying the value of charging the super. It still might not adequately explain how to get the charge though.

For Ranking:
- Tips on restarting that give details on how to get higher scores, i.e. "kill multiple enemies in a single slash for more points" etc. This doesn't really help the first play through though, so it's probably not the best option for a new player and therefore doesn't help with retention.
- An on-screen score counter, so people can directly see how much (or how little) their actions increased their score. I was strongly considering this but It would've been a lot of extra work to make it work with the 32 x 32 screen size and I'm not sure if it would've been able to fit on screen or look good anyway.

There were also some other possibilities I could have looked at as well, but those probably would've required extra systems/artwork and taken a lot of extra time. But because this also directly impacts the difficulty of the game, it might have been worth the time. Playing the game wildly slashing and running is easy but ultimately boring.

The final thing I've identified is a a lack of variety. I think I did better than previous games when it came to the sheer ammount of content in this game, but it still would've probably been better to add some different enemy types. I mean, for a game where the title is "Shogun Assassin" there's not really a shogun to assassinate. A boss character might have added that kind of final goal the game needed. Further, a blocking type character might have been the thing to stop the players aggressive running and slashing. Normally, this kind of thing might take too long for a jam but because of the small pixel count I probably could have added another specialist enemy. Maybe I need to look at my enemies less as complete "character" with multiple options and keep them as simpler threats that only perform a singular action?

The Ugly

It's hard to gauge exactly what time was spent on what for this jam because I did so much just here and there while doing other stuff. Further, I started the Jam late... then jam got extended. I ended up finishing a day early, so it's hard to gauge anything, even in terms of loose time frames. I should probably start noting down times or whatever so I can get this better understood.

I do remember the initial sprite work and background work taking quite a bit of time. Enemy sprites also took a while until I worked out some tricks to speed the process up. Actually getting in the functionality into the code didn't take anywhere long as I thought it would, and even now the way it's all set up makes it pretty easy to edit and add stuff. I remember that once again it took me ages to source decent sound effects. Even though I was using Sfxr and happy to use beeps and boops, it still took me a while to find effects that worked. Music didn't take too much time at all comparatively, and I managed to crank out 2 loops, an intro sting and an ender in an about an evening.

A Fistful of Dollars

I learnt a lot of little things this jam, or at least, had plenty to think about:
- That "art of screenshake" video is full of great practical examples of stuff you can add relatively quickly to make a game feel more fun. Not all of them were applicable here because of the tiny resolution and game concept, but I think anyone making an action game should check it out. They primarily focus on gun shooting action, but think about the genre you're aiming for an then think about what makes that genre stand out, then amplify those elements as much as possible. For gun shooting action movies its explosions and screen shake, for samurai films its flashes of light and blood spurts.
- Strongly consider the end goals the player is presented or expects while playing your game. Ensure that the way you present your game highlights exactly what the player needs to do, even down to the title. Make as many elements of the art/gameplay/UI/sound reinforce that goal as you can.
- I think I need to make a little personal database of sound effects to draw from quickly from, rather than try to source a new set every jam. Every jam I've done sound for so far, the time spent sourcing sound seems like the biggest stalling point.
- I really enjoyed making the music for this game, and trying to make the music match the theme. But I think I need to think harder about how the music reflects the action. I made the in game music driving to reflect how players were playing it currently, even though that's not necessarily how I wanted them to play it. I should've tried to make the music lead them to how I wanted them to approach the gameplay, or better yet, have the music adapt to how they play.
- I also need to do better at getting feedback from test builds. I think specifically I need to start asking friends to play and then begging for anything that felt bad/could be improved. I got some decent feedback towards the end but at that point it was too late to make major changes. Twitter/GameJolt feedback seems pretty useless at the moment, although judging by the high score table the game's either too hard or gets too boring.
- For objects that relate to other objects (specifically the enemy characters compared to the floor), let the dynamic object handle how interactions should work. Here, I had the floor objects tell the player/enemy how high they should be without using collisions, but this lead to issues where the floors couldn't tell specific enemy sprites where to go. I ended up having to cheat with the enemies to stop them from falling all over the place. I could have more explicitly created my enemies, but I think it would've been better to just have enemies check their collisions with floors and act accordingly. I'm pretty sure all computers would've been able to handle it.

For a Few Dollars More

I actually enjoyed making this game and am pretty pleased with how it turned out. Continuing it might be a little problematic though, since it's based pretty heavily on a known IP and the 32 x 32 resolution is a little limiting. I could go and rebrand it, expand the resolution, add a level progression, more content etc.  I think I'd also entirely restructure the attack system, give the player a 3 hit combo and make the rapid attacks a super or something. It might actually be cool to expand it fully to character action game standards, have multiple attacks, special moves, juggles, etc. I'm just not sure that's the best idea though.

So, do you have any feedback? If so, I'd love to hear it... Otherwise I guess just stay tuned for whatever is next.

Thursday, June 5, 2014

... In the kitchen.

A friend of mine was after a pinup style pose for a baking stall she was planning on running at the local markets, so I decided to give it a shot. If you're ever in Katherine, NT keep an eye out for it!

I hadn't drawn anything proper/non-game related for a while so it felt good to get back into it. I've also been doing some other stuff. I should probably post about that too...

Thursday, May 1, 2014

Ludum Dare 29 #2 - Post-Mortem


Ludum Dare 29 was my fourth jam this year, and definitely the one with the toughest restrictions. LD is a 48 hour competition (or a 72 hour casual team jam, but who wants to be a filthy casual?) which, compared to the time-frames of other jams I've done so far, proved to be the biggest challenge. This is also the first jam I've entered where the theme wasn't directly related to the purpose of the jam, meaning that you really start this jam cold as far as ideas/concept go. When it was released, the theme, "Beneath the surface", didn't really get my motor running, but doing something that you don't necessarily want to do is what jams are about. Lastly, I did this jam in a more social setting, instead of my regular "hidden away in my bedroom" situation. I worked alongside Jamalaide a bunch of local jammers. It meant I had to get shower and get dressed daily. Luckily it was only for two days.

The Good

Despite the current state of the game, it mostly works as I envisioned it during that first hour of planning. I knew I only had a tiny amount of time to make something, so I tried to shave down the scope as much as possible without losing the key concepts (i.e. using units to uncover information, using different units to work with that information). There were plenty of other things that got cut during the planning, but nothing that got finalized in the planning was necessarily cut (just badly implemented). So far, this has been the only game that I haven't had to change scope mid development.

Additionally, this is probably the best application of time I've done so far. Graphics-wise, this game was never going to be anything special, but code-wise, I think I did as much for this game as I did for the Candy jam, but this time I did it in 2 days compared to a week.

It was also the first time I'd done a jam in a social setting, which was both fun, terrifying and kind of disappointing at the same time. Fun because it was great to meet other like-minded people. Terrifying because by the end of day one all I had was a bunch of circles and lines on a screen that did nothing and I felt like people would judge me. Finally, disappointing because out of the people there only one other group really worked on something.

The Bad

The biggest personal shame is that Agents & Assassins has at least one major crash/stall. In the final hour I noticed it because it was causing an endless sound loop... So I stripped out the sound effect and then couldn't find it again. I had assumed it was fixed. Unfortunately, it was not and in trying to get the end game screenshot for this post I had it happen about 4 times. Additionally, I also found a bug where killed units weren't being removed from the screen which is pretty annoying as well. I can't really remember any major bugs from the previous game jams but this is definitely the first showstopper I've had.

Obviously the next biggest issue is the general confusion and lack of feedback to the player. With such a tiny time-frame, getting any amount of polish into the game is a tough ask, but plenty could have been done better while building the base mechanics to firstly make it more obvious what is happening where, and also improve the flow between turns for the player. Some examples:
- When an agent moves to a new neighborhood, it should take a couple of seconds to highlight if this neighborhood is corrupt and then a couple of seconds per new unit found (as well as moving the camera to highlight them. Maybe with some kind of animation, or sound effect.
- When a known corrupter unit infects a new neighborhood (and is consumed) it should make a point of moving the camera there so its obvious to the player where the unit went instead of just disappearing. Similarly, it would be better if all units slid across the map instead of jumping neighborhood to neighborhood.
- You should be able to scroll the map around, or zoom and and out, to get a better view of where enemy units are.
- When a unit is killed, there should be more notice given to the player, especially if they're killed by an unknown assassin.
- When a new unit is created, it jumps to the front of the turn queue.

Some of these I attempted to fix in the time I had, but since I hadn't done much with the camera before I wasn't really sure how to make it work consistently. In the end, I decided a consistent average camera was better than a sometimes working decent camera.

The root cause of most of these issues stems from the crazy overblown ways I attempted to implement stuff. Because I've been so focused recently on building stuff that's easily extendable in the future, I kind of wasted a lot of time ensuring everything was placed dynamically and that the various systems could handle additional units or mechanics... I wasted a lot of time on the first day trying to get the neighborhood and road placements correct. Really, I could have placed them all statically in the room in an hour or two and it wouldn't be any different for a player. For a week long jam, it might have been a good idea, but it was pretty unnecessary for this one.

The Ugly

Speaking of time spent, the breakdown went something like this:
1 hour - Research and planning
12 hours - Coding the neighborhoods/roads/links
9 hours - Coding the turn system
5 hours - Coding unit behavior
5 hours - Coding the A.I.
3 hours - Art and UI
1 hour - In-game "Tutorial"
0.5 hours - Sound effects
1 hour - Preparing for submission
2.5 hours - Eating
1 hour - Driving
7 hours - Sleep

Development wise, I'd already cut back the initial idea a lot during the planning phase, so the end product is pretty close to what I had imagined. Obviously I had envisioned something a little more polished of course, and I think next time I do this I'm going to have to cut scope more to give more polish time.

A Fistful Of Dollars

I didn't really try anything new this jam, so I can't really say there was a lot of new things to learn/note about Game Maker. I guess there are some things to remember for next jam though:
- Even if you've cut things down as much as you can, you can still probably cut it down more. The key concept this game was to use one unit to scout and other units to do stuff with that information the scout uncovers. I could have changed the loss condition to having half the neighborhoods dissenting or something similar, cutting out the need for assassins and guards entirely. Alternatively, I could have had one unit that remains hidden while not moving, and have it capable of either investigating or purging a town if waits a turn.
- A 2 day jam probably wont lead to a marketable product, even if it could make a decent prototype. Its still not worth putting in a lot of time to make sure you're left with something that's easy to build on. That extra time can be spent doing stuff from scratch post-jam, really.
- After this and the Candy jam, I kind of think I need to focus less on big ideas and more on presentation/communication. It's pointless to have some kind of new concept if it gets lost within a clunky interface. I need to get better at providing a better, more concise experience in a shorter amount of time. Next jam, that should probably be the goal.

For a Few Dollars More

While I still kind of enjoy the basic concept and think it could possibly lead to some interesting stuff, I don't think I'll be going back to this game anytime soon (except to maybe fix that crash). I've got the submission cut off date coming up for AV-Con, plus I really need to do something I can release, and I'm not convinced that this concept has a wide array of people that would be interested, be them passers-by or potential customers.

I also don't really know what jam I'll do next. I was interested in the LowRezJam, but I dunno if I'll have time to do something and work on something for the AV-Con submission at the end of the month.