Pixel Metal Madness

As per request from @Ithryn_...

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.

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?

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.

... 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...

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.

Ludum Dare 29 #1 - Agents & Assassins

This last weekend I competed in Ludum Dare, which is a 48 hour international game jam. This time though, I did it with the folks of Jamalaide, Adelaide's own game jam group. There wasn't a very big turn out but it was a pretty fun experience nonetheless, if not also stressful and busy.

The jam theme was "Beneath the surface", which wasn't the most interesting theme but led to some interesting interpretations. I went hard literal and based it on the quote from Roman Emperor Marcus Aurelius, and the built the game around trying to route out dissenters hiding beneath the surface of Rome's neighborhoods. I also had a side challenge of hiding the "Tree of Life" in there somewhere, which I managed to secret in there.

Getting something made in 48 hours was tough but mechanic-wise I got the basic stuff in there. I spent way too long coding things in unnecessary ways, like dynamically placing the city layout and how the enemies are handled... Things that would be great if this was something I was actively developing but not great when I could've used that time for polish/better graphics/better bells and whistles. More on that in the upcoming postmortem.

If you'd liked to have a go, the game's Ludum Dare page is here, or you can play it at my website here.

Repeat After Me #1- Programmer art ahoy

After the Cyberpunk Jam I decided to continue with previous blog name-drop Drew Fellows on another game of his own design, which is now "Repeat After Me". It seemed like a relatively easy build, but at the same time was going to offer a chance to learn some other features of GameMaker that I hadn't got around to learning yet, so it seemed like a fun little project to do.

I had intended to do this post last night, but I seem to have a habit of coding myself into infinite loops while working on this game, so I didn't really want to stop and call alpha until I had that sorted out. If you want to see progress so far, check it out here: http://www.bigstompyrobots.com/repeatafterme/alpha/

Drew has handled the basic design and will be handling look and feel, but I'll be doing construction and tuning it I'm guessing. At the moment, the basic mechanic is in and working, but it's very rough. Also it's not exactly suited to a computer, but it runs fairly well on mobile/tablet.

Anyway, it's late and I'm tired. I'm not sure if I'll move on from this dev for the moment or get my iOS developer license and make a demo. If I move on though, I might do a quick pass of the main website or move back to Mighty Hammer.

Apex Diver #2 - Demo's ain't dead

Have an android device? Know how to install apps? Why not check out my first android game!
Download it here : http://www.bigstompyrobots.com/apexdiver/android/apexdiver-1.0.0.apk

So from what I was saying the other day:
- It now scales depending on what your phone can handle. Scaling to screen size should be fine and most current phones should be able to run it fine with scanlines and lighting effects turned off. I'm pretty confident this is working as expected.

- Tracking and analytics are somewhat in. It's a really basic implementation, and at the moment I'm not sure if it's working or if using Google Analytics is the right choice. I figured I may as well make stand alone copies that I can just test randomly in the meantime. There's a lot of room for improvement but I'll make sure it actually works before messing with it anymore.

- Ads are in too. They work as they should (I'm pretty sure) but they came with a couple of odd problems that I need to remember for next time. Firstly, they need to be placed according to the device width/height... using the room as reference ended up with it sitting off center. Secondly, while the shaders are on, it drops performance a fair bit (enough to drop my galaxy S3 from showing lighting effects to showing no effects). I was tossing up between having an onscreen banner or having ads appear after retrying or something similar, so the performance loss alone might be reason enough to change it.

- I totally forgot to look into storing user preferences/high scores, so that's not going to be a thing until the next time I come around to Apex Diver.

This is probably as much as I'm going to do on Apex Diver for at least a week. Onto something different in the meantime...

Apex Diver #1 - Now running on Android

So as I discussed previously, while I'm not exactly enamored with the end product (although it did make it to the top 50 of the Cyber Jam somehow), I'm going to continue a little further with Apex Diver and use it as my first release. Actually getting a project to release is something that I've yet to do, and there's bound to be issues and things that go wrong along the way, so I'm happy to use this as a test not only for getting to mobile, but also for adding in the other important stuff like scaling, stat tracking and advertisements.

Presently: I'm pretty sure I've got the scaling working... The game runs on both my tablet and my phone at the moment, both using different resolutions. I've fixed a new and random bug where the shaders were causing a crash and did a lot of optimisation in an attempt to increase the frame rate. Unfortunately, it wasn't enough to make it run smoothly on mobile devices. I found another way to scale away shaders/effects if the device can't handle whats happening on screen. The best part about this is that I don't need to test all kinds of devices and set stuff manually, but the flip side is that I'm a little unsure of what the baseline device that can handle the game is (although apparently, it's around a 2012 Nexus 7 level).

Still to come: I've gotta look at adding stat tracking, which seems like it should be a pretty easy thing to add, but it doesn't look like I'll be able to use mixpanel which makes me a little sad. Google's tracking seems like a possibility though, so I'm interested to see what that entails. If nothing else, I can use Flurry. As for Advertisements, at the moment I'm happy to use whatever is in there, but maybe Tapjoy would be a better fit (if that's even possible). Oh... and I've got to remember to set the onscreen instructions specifically if it's running on a touchscreen/keyboard (and maybe control pad?).

I'm not too worried about extending the gameplay at the moment, but I do need to store settings and stuff permanently (like what shaders should be left on/brightness levels). I may as well look at adding in highscores or minigoals. If I change the gameplay at all the first thing will be something to discourage sliding all day.

I think I'll either make an .apk available within the week, or put up a private build on Google play or something when I've got most of that stuff done. Then, I'm just going to sit on it and decide what else to do with it after playing it a bit. I've also decided I'm going to work on a couple of other things at the same time (as discussed previously, Mighty Hammer, as well as another project with Drew called Repeat After Me).

I think I'm also going to try and make a point of posting Mondays, Wednesdays and Fridays from now on. If you know me in real life and I miss this, feel free to harass/hurl abuse at me.

Cyberpunk Jam #4 - Post-Mortem

And so concludes my third game jam of this year... Out of the three so far I think I'm most disappointed in this one. Mostly this is because the original scope was a little too large for the time frame of the jam, but also because I lost a lot of time due to unavoidable family commitments. What was supposed to be an extension away from an "endless runner" type of game ended up being cut back to a bare basics. It stings all the more because I was really interested in the theme for this game jam, much more so than the Candy and Flappy Jams before it.

That's not to say I'm disappointed in all elements of Apex Diver or the process of making it. If anything, this game's pushed me harder than any previous game I've worked on. I've learn't much more about using GameMaker, its strengths and limitations, and even where I can develop (in a car, in a bed, everywhere!). But now on to specifics:

The Good 

Prior to starting this jam I wanted to make this game look much better than the previous two, which luckily is not too hard considering how Ascii Bird looked. I was aiming to make this look like a commercial mobile game as much as possible, and I think the animations and shader effects work pretty well in that regard. For the animations I was kind of flying blind a lot of the time, aiming for a bigger loop and more frames per second than any previous animation I'd done. Despite that, I'm pretty happy with the run loop, and considering the short amount of time I had to work with, the other animations weren't too bad either. There's quite a lot of movement going on between the player and the enemies, and everything has at least 8 frames to it.

Similarly, while I'd done some research into shaders before the jam, I still wasn't at the stage where I could actually get them working as intended for the finished product. In Apex Diver, I used two separate shaders (one for the lighting effects, and the other for the scanlines/postprocessing effects) and by the end not only could I get them to work, I could adjust them to do additional things as needed. I'm still probably not at the stage where I can code my own shaders, but it's still a pretty good start.

Apex Diver is also the first game I've made where I've had sound (despite how it turned out, but more on that later) so that's a good achievement. GameMaker's new sound system makes it super easy to do 3D/Stereo sound, which I added a lot, but annoyingly there are some limitations in HTML5 that ended up derailing the project for a little while.

Overall, I was pleased with the amount of polish (in most areas of the game at least) I managed to do in such a tight timeframe. Plus the game runs and there's not any major bugs (that I know of at least).

The Bad

The biggest issue with this jam was time management. Annoyingly, it's also the one thing I couldn't really do anything about. I think I ended up losing something like 2.5 - 3 days of time I thought I was going to have, out of the 8-9 allotted for the jam, due to some inescapable commitments. In terms of development time, that would've been another (planned) mechanic, or some additional/background art, or additional bells and whistles.

Obviously this biggest problem stems from the gameplay: I was making a runner but I wanted to throw in a new mechanic to make stand out and match the theme more. After all, jams are suppose to be more about trying new ideas rather than just playing it safe. At the same time though, One of the bigger lessons I learnt from the Candy Jam was that jam games need to be super quick and simple to play. I was hoping that by starting at something known and simple, I could then transition into another aspect to keep it interesting.

That aspect was going to be falling (and dodging obstacles). While not exactly original either, I hadn't seen a game that that combined the two styles before, and it lead naturally from the running gameplay and the theme image. However, it would've been another day  for animations and background art, and maybe another day for coding. Needless to say, it was the first thing that got cut when time started to run out.

I had intentions to bring it back if I could. At one stage it looked like I might be able to get about a day's worth of time back, but in the end I had to struggle with a huge amount of bugs stemming from browser compatibility. As it turns out, not all browsers support shaders (via WebGL), nor do all of them support GameMaker's new sound system. Further to that, for some (still) unexplained reason, global variables don't work in HTML5 as they do on in a regular executable.

Tracking down why these things were happening, and then coding and testing workarounds, ended up taking up that recovered day plus some of the time that would've gone towards UI. Even then, some of the workarounds weren't enough (Attempting to run anything to do with WebGL on Internet Explorer crashes, you can't use the new and old sound system together to cover multiple browsers). I was hoping HTML5 would be an easy way to reach a wider audience, but I swear it ended up making it less simple than just uploading a windows, mac and linux build.

In addition, this was the first game I did as a collaboration. I suspect I didn't really communicate enough of the details to my team mate. It was harder to work long distance than I was anticipating, and particularly because we were both busy during the early part of the jam. At least communication is something I can easily improve if I do another jam collaboration.

I kind of feel like I'm just going on and on at this point, so the other things that need work but aren't quite as as big:
- The UI doens't have a lot going for it, and doesn't have a lot of bells and whistles either. Kind of not such a huge deal for a jam game, but when you're trying to up the graphic quality, things like this stick out.

- The sound effects really blow... It was way harder than I was expecting to get decent sound samples, and in the future I think I'd just prefer to record my own stuff or rely on beep-boops and music.

- The way the difficulty scaling was implemented works, but it could've been tweaked a little more. As it stands, its too easy just to keep sliding forever. Ideally the lying enemies should probably start shooting earlier than the other enemies in an effort to make slides seem less godlike. Similarly, there probably should've been some kind of enemy/obstacle that you couldn't jump for to prevent hugging the right wall and jumping.

- While the main character is a pretty good representation of the jam theme image, I totally missed hitting "height" as a theme because that aspect of gameplay got dropped. It's annoying because I spent time coding in variable floor height (as seen in one of the earlier build versions), but in the end it's just all played on a static floor height.

- The game runs/doesn't run correctly depending on browser. Ideally I'd want at least a functioning game with little effort from the player. At least after this game I know what does and doesn't work in each browser.

The Ugly

The rush I was in to make the most of the time I had, plus all the other external factors, makes it hard to remember exactly how much I spent on everything (I should probably write stuff down next time). But roughly:
1.5 days - Player animations
0.5 days - Enemy animations
1 day - Foreground/Background art
0.5 days - UI/Splash/Menu implementation
2 days - Main mechanics (jumping, sliding, hitting, dying) + Screen scrolling + Enemy placement
0.5 days - Sound effect sourcing and implementation
1 day - Testing and fixing (mainly browser specific issues)

Development wise, I had a pretty good idea in my head where it was going to go and then just gradually dropped scope as I ran out of time. I really should've spent an hour at the start to do up a quick doc or flow chart for my collaboration partner though.

A Fistful of Dollars

I think from now on out I'm going to start recording "Things I've learnt from this jam" for the sake of remembering them for next time. So for this jam:

- In HTML5, Chrome and Firefox can handle WebGL (and therefore shaders). Safari can supposedly handle it but only if you call a HTML window from within an official iOS/MacOS app. Internet Explorer Crashes whenever a shader is included in the progam (even if it's not being called). Chrome and Safari can use GameMaker's new audio system, although Chrome can't use some of it's features (messing with master_audio_gain or whatever seemed to kill sound entirely). Legacy audio should work on all.

- There is no way to play video in GameMaker, but you can convert a video file into a series of stills and then strip the audio and put it in separately. This ends up taking up a lot of space though and may cause lag. I wouldn't recommend this if possible.

- For some reason, global variables in GameMaker do not work the same in HTML5 as they do normally. It seemed to me like you couldn't set a global variable in the room it was created (but even that might be wrong). The work around seemed to be to have a initialization room at the start that does nothing but sets these variables and then transitions on to the next room.

- Jam games need to be simple to pick up and grab someone in the first 30 seconds. Difficulty probably needs to scale harder than a normal game. For someone to keep playing on past that point, they need to add something drastically different (mechanic or art) every 20 seconds. Players will sit and wait through stuff if they have control of something and its clear something is going to happen. Getting someone to replay a game looks like it might be really tough, so looking specifically at that might be a good idea. (This is based on comments/watching videos/livestreams of people playing the games... I should really set up tracking next time though).

- Jam games probably also need their rules explained quickly and obviously within the game as well. There's not a great deal of time left in 30 seconds to leave to ambiguous or adaptable play strategies. Most players will try one way of playing, it'll either work or not work for them, and they'll move on. It's important that they play in a way that makes the most of the mechanics involved and still remains exciting.

- On the flip side to that, considering most of the players are designers/programmers, they will probably also be looking at how they can optimise/"break" they game mechanics. There's no shame in this, but make sure if somethings going to look "breakable" it's actually fun rather than monotonous.

As far as tracking goes: Apex Diver is currently doing slightly worse view-wise than the other two jam games. Ascii Bird is a bad comparison since it got Wired coverage and the Flappy Jam was generally more popular, but it would seem Scrolls of Candy had slightly more natural draw. I can push the view count higher by reviewing and commenting on other games, but even that returns slightly less than it did on Scrolls of Candy.

Presently I'm sitting on 13 ratings and 7 comments for Apex Diver, compared to 14 ratings and 11 comments for Scrolls of Candy. The quality of those ratings are still a mystery, but at the moment I don't see me making the top 10% in any of the categories, least of all overall.

And a Few Dollars More

Since the graphic quality is pretty good, and I need to test releasing for mobile/adding tracking/adding advertisements, I'm going to use Apex Diver for that. I'm already in the process of adding in touch controls, and then after that I need to work out view scaling, but it shouldn't take long.

I also have the option to continue on development and add new backgrounds/gameplay features, but I'm not sure if that's something I want to spend a lot of time on. I think with this, I'll probably make some small changes based on feedback from the jam and sit on it for a while, get some more feedback and then revise again. That being said, if you have any comments or criticism about the game I'd love to hear it so I can work off of that as well.

Cyberpunk Jam #3 - Game Complete!

Admittedly not a huge amount of difference between the previous screenshot and this one, but I assure you, a lot of work happened between them. So I'm not 100% happy with how this Jam went but if nothing else, I learnt a whole bunch more. More of that in the post-mortem in the next couple of days, but in the meantime, why not give the finished thing a go here:

http://bigstompyrobots.itch.io/apex-diver

If you are going to play, I recommend playing in a Chrome browser so you can get the fancy graphics and sound.

Cyberpunk Jam #2 - Leaps and bounds

Not as much posting as I should've been doing, but its mainly because I've been too busy trying to catch up. I haven't, but scopes have been dropped and I'm getting pretty close to a finished thing, as seen in the screenshot above, or if you use chrome, in this latest build: http://www.bigstompyrobots.com/apexdiver/seventh/

Cyberpunk Jam #1 - Running behind schedule

Another week another gamejam... This time though I'm collaborating with Drew Fellows on the Cyberpunk Jam. While the previous games have been pretty vague in their themes, this one is supposed to be inspired by a specific image.

I was late starting due to some family business and unfortunately I haven't really caught up yet (and probably wont tomorrow either). However, I've finally finished the run loop for the main character, which is pretty important for a run and jump kind of game. Next up: Jumping, sliding, falling, etc.

Flappy Jam #First and Final - Game Complete + Post-Mortem

So towards the end of the Candy Jam someone decided we also needed a Flappy Jam in support of Dong Nguyen's decision to take down his hit mobile game Flappy Bird. Personally I didn't see the point... Candy Jam was about something I legitimately felt strongly about, but Flappy Jam didn't really seem to have a purpose and as much as I wanted to do as many jams as possible this year, I wouldn't have felt bad for skipping it.

Meanwhile, while checking out some of the other Candy Jam entries, I came across Twine. Twine is a tool for making old school text adventures in a web friendly format. Being a big fan of text adventures, I decided to make a point of checking it out at a later date. A couple of days after that I end up in a conversation with another game developer, bemoaning Flappy Bird's success. I was feeling cocky, so I bet him I could remake Flappy Bird in a Twine. One day later and here we are.

Play Ascii Bird here:
http://bigstompyrobots.itch.io/ascii-bird

I don't really want to drag this game out too much so I'm also going to launch straight into the post-mortem in this post.

The Bad

The most horrible thing here from a game designer standpoint is that there are certain scenarios that can happen in this game that make continuing impossible. The way the "engine" works is if there's no pipes on the screen, it has a random chance of spawning a high gap pipe, a low gap pipe, or having another screen with no pipes. The high gap pipe only has 1 bird height that can pass through it, so if you can't get to the right position in time you can't get through. If the player gets 2 screens with no pipe and then a high gap pipe, it's impossible to get into the right position. I could've changed this, but I kind of felt like if there was more of a gap it would be way too easy to flap forever and the game was supposed to be near impossible anyway, so instead I added the easy low gap pipe to add some variety and make it seem like the game was a little more possible to play.

Twine is pretty good for what it's intended to be used for, but pretty limited for doing anything crazy out of the box. Originally I was just going to literally break every decision down and do a page each decision, but that seemed like madness. So then I started looking at drawing the game world textblock by textblock, but Twine doesn't like having nested code (i.e. if statements within if statements) so that got nixed.

Then I decided maybe to just have a single page that reacts differently depending on what variables you pass into it. This would've worked, except that my brain wasn't in the right place and did the wrong syntax all over the place. Retrospectively, if I did do this that way it would've made debugging a pain in the ass so I'm glad I didn't do it.

Eventually I ended up doing a different page for each possible bird/pipe combination, which seems excessive but didn't really take that long. The Twine editor has visual links between pages, which makes it really easy to check the gameplay flow. I ended up with something that looks a little like this:

It's pretty janky but it works, and that's what's important.

The Good

I got it done in about a day despite knowing nothing about Twine. I could've cheated and done a bunch of stuff in javascript, but I stuck to my guns. After I did settle on a methodology I was surprised at just how well it did work. It lacks animation and sound, but mechanically its about the equivalent of the mobile game.

I don't know if this is really good or just an indication of how popular Flappy Birds is, but the views on itch.io for this game have already surpassed the views for Scroll of Candy. So in that regard, 1 day of effort gets you more views than 1 week of effort. It could be though, that the nature of how Twine works means that it refreshes the screen and hence view count every action. I'd look into it but I couldn't be bothered.

The Ugly

Broken down really roughly, time was spent as such:
1/2 day - Working out how to use Twine
1/2 day - Manually editing ASCII art

Development-wise, I was playing this by ear because I had no idea what the capabilities of the engine would be.

And a Fistful of Dollars

I wouldn't continue any development on this game, not even if people wanted me to. I would however make some more stuff in Twine, and may do something at a future jam, depending on the topics.

Mighty Hammer #1 - Rumble in the streets

So that game I was working on before the jam... This is it.

I've put up a demo of the stuff so far here: http://bigstompyrobots.com/mightyhammer/

However: While what's there works fine in the GameMaker, it's really hard to pick up the hammer when it's running in a browser... It's an odd bug but I'm sure I'll be able to work it out. In the meantime you can just rumble the ground a bunch.

The gameplay should go as such: You pick up your mighty hammer and toss it upwards, performing a bunch of random tasks (i.e. hitting stuff) before your hammer loses momentum and starts plummeting back down to earth, giving you a second chance at any targets you might have missed before. The amount of tasks you get depend on how well you manage to throw/flick the hammer at the start.

The code for picking up and measuring the hammer throw is there and works to some extent, but it doesn't feel good or controllable. I think that's probably going to have to be the first thing I improve before I start looking at the main part of the game. If I can't get it to feel better though, I do have a couple of other options;
- The super-lame but safest way to work it is to add a fluctuating "power bar" and have the player click/tap to launch the hammer, ala track and field 1980's nonsense.
- The more gimmicky but involved way would be to have players spin up the hammer by dragging their finger around in a circle a few times before throwing, ala a hammer toss.

As for the rest of the game: I have a bunch of art assets already made, but aside from that nothing else is really set in stone. I had plans to kind of make this a lot bigger and detailed, but at the moment I almost feel like I should simplify the end goal to get it done quicker, and then maybe go back to developing Scrolls of Candy into something more substantial for release.

Candy Jam #Finale - My favorite games

After making Scrolls of Candy I obviously wanted it to do well. I don't believe the point of the Candy Jam was to be competitive, but being a competitive asshole is something I'm pretty good at, and you should always play to your strengths.

The jam format itself initially only tracked views, but as it went on they added comments (for site members only) and ratings (for Candy Jam entrants only). All of this made it a little hard market myself or my game, and apparently it was the same for most other people in the jam, based on the low-to-zero amount of ratings most of the games had received. Abandoning hope of being able to "win" by any definition of my own, I decided to instead "become the change I wished to see".

I made it my mission to play and rate all of the games entered into the candy jam. In retrospect, it was a dumb decision, and in reality I think I may have made it through about half of the games, but intent was what counted. There was simply too many games spread across too many mediums, and too many that didn't really try enough that really sapped my will to continue. "All the games" soon became "all the browser games" which then became "Games with nice thumbnails".

But jointly save any of you from the same fate, as well as celebrate those who did do great work, I would like to present my picks for the best of the Candy Jam:

Candy Escape Goat Saga
by @MagicalTimeBean
http://magicaltimebean.itch.io/candy-escape-goat-saga

Probably the one of the most polished games in the jam. It's based on the Escape Goat 2, the sequel to the puzzle platformer game Escape Goat, currently being made by MagicalTimeBean. Rather than reskinning the graphics, MagicalTimeBean has created new levels with new mechanics inspired by Candy Crush/match-3 style games. The whole concept works amazingly well and features great level design. It doesn't take long to play and it'll probably convince you to go and check out Escape Goat as well!

The onslaught of the almighty candy biotics
by @benjamin_soule_
http://benjamin-soul.itch.io/candy-biotics

To put it as simply as possible, Candy biotics is like a heady mash up of Legend of Zelda and Boulderdash dressed up in finest EGA graphics the 1980's could afford. The best part about this game is the sheer amount of content hidden away just waiting for the player to come find it. This is pretty much a fully formed game, done in an extremely short amount of time by one guy. It's also probably the only game on this list that I'd go back and play more of willingly.

Candy Match Forever
by @realnoyb
http://noyb.itch.io/candy-match-forever

Candy Match Forever takes match-3 games at their basic design, looks at how Candy Crush Saga handles things, and then flips it entirely on it's head. Where CCS  is designed to make you fail, CMF wants you to win. CCS makes you wait before it'll give you any reward, CMF does nothing but reward you. CCS splits and dilutes it's narrative and only drip feeds it to you after passing it's checkpoints, CMF lays it out on the table no matter how well you do. Amazing stuff.

King of Candy Fart Saga
by @_iq12_
http://ulu.itch.io/king-of-candy-fart-saga

Crass as all hell, but it's really hard to not appreciate the art style of this game. There were a couple of other interesting art styles floating around the jam (LCD game-and-watch style being another of my favourites that I'm totally going to be stealing sometime soon) but I don't think any of the other ones were quite as unique or polished as this medieval/playing card look. It also helps that the gameplay is pretty solid and satisfying (especially when you luck out on a few Jesus combos).

Kukulki
by @Sosowski
http://sos.itch.io/kukulki

While the gameplay concept in this game has potential, I don't think it was fully realised here. However, this game gets many bonus points for a few things:
- The informative and educational look at communist Poland.
- The soundtrack, possibly best music of all of the games submitted.
- The incredible ending.

Candy's Crushes Saga
by @Oujevipo
http://pierrec.itch.io/candys-crushes-saga

Possibly the cleverest interpretation of the jam words, Candy's Crushes Saga is a puzzle game that plays out like a pixelated autobiographical arthouse movie that examines the relationships of a girl named Candy. The puzzles and the way they are presented are extremely fitting and well done for something made in puzzlescript.

Candy Jam #4 - Post-mortem

So overall I was pretty happy with how things turned out for the roughly week's worth of time I had. I don't really think it was a great game, but I think with some additional tweaking time and maybe time to develop the art a little more I could have actually made something fairly decent out of it.

The Bad

The biggest problem I feel comes from the lack of variety... The tile matching mechanics were pretty fleshed out but because it's just playing the same guy over and over, a fairly static goal, it gets a little boring. I tried to quickly add a narrative during the last day to give it some additional kind of progression, but I think that it really required more art time than I had to properly sell it. Candy Crush Saga has a similar problem but covers it with the changing playfield. Alternatively I could have followed Bejeweled's design and rejigged the gameplay to be more geared towards beating time/score so that the goal could change as the player gets better, in turn hopefully leading to more playability. That focus on simple gameplay and replayability seems to be the key to jam games, so I'll have to keep it in mind for future ones. 

There is also a lack of player reward during and after play which was something else the narrative was supposed to address, but it didn't quite work. The fun parts of these match games (for me at least) is when you manage to get a combo going and the game starts to play itself. I wanted to have something like that, but it was hard to balance that with the back-and-forth aspect of the battle mechanics, which was the main concept I was aiming for. I had options that I could attempt in that regard, but doing it quickly and without complicating the basic rules of the game didn't seem realistic for the jam.

Speaking of which, the last major problem I'd noticed was lack of player guidance/instruction. By the end, I'd added in more GUI stuff than the original design included to try and make it more obvious, but it's still a stumbling block for new players in my opinion. Added sound cues might have helped a little, as would've better designed GUI elements and a tutorial. I might have even been able to spread the difficulty levels out more, making the first couple of battles even simpler, but I don't think that would've solved the overall problem.

Minor issues I could spot are probably more due to nature of game jamming. Obviously there's not a lot of variety to the art, and some of it is pretty rough. The narrative is terrible and goes nowhere. There's a complete lack of sound or music. The difficulty curve is less of a curve and more of a flat line. All of these are problems that could be solved with more time, but obviously time is always going to be a limiting factor in challenges like this. 

So with the negatives out of the way, on to the positives:

The Good

I was pretty pleased with how much I had managed to actually do during the timeframe. It took quite a few long days, but I think what I've done is one of the more complete games in the jam that wasn't built on top of an existing game. Plus I'm a little more confident in what I can accomplish on my own again. That being said I probably would like to do a team thing next time, if only so I can focus on one thing instead of everything. Especially if the time frame is even shorter (like a weekend). 

I'm also pretty glad my coding ability still seems acceptable. I haven't had any bug reports yet aside from a couple of graphical issues, so that's pretty positive. That all being said, I wouldn't like anyone to read the mess of code I wrote, but at least it was all annotated and when I had to rewrite the main game loop late into the week it wasn't that big of a deal. Still though, one of these days I'm going to need to learn how to write functions in GameMaker.

I'm also pretty proud of the mechanics behind the tile matching aspect of the game. It comes out looking relatively simple but the way I built it made it very easy to add more stuff to it (which I was ready to do if I ended up with spare time). Bejeweled style combos, Puzzle Fighter style merged blocks and Candy Crush style powerup tiles could have all been added relatively easily. Similarly I could've dropped, flipped or randomized the candy strength hierarchy. 

The difficulty function was pretty effective as well, making it really easy to add individual aspects at certain levels. There's only three different levels in the game for simplicity's sake, but I could have extended it out to five without too much hassle. Not only that, but it was a lot easier to extend the AI through the difficulty levels than I was expecting. Even though the game's not exactly hard and the AI makes some dumb moves sometimes, those dumb moves are deliberate.

The Ugly

So broken down very roughly, according to my memory, time was split up as such:

1.5 days - Gameplay sprites and UI

1 day - Tile mechanics

1.5 days - Battle/turn mechanics

1 day - Title and narrative screens, screen navigation

1 day (total, but this was kind of split up and between days) - Testing and fixing

There appears to be a day missing, so lets assume I just slept that entire day. 

Development-wise, this was less "planned out at the start" and more "do a bunch of stuff and see where we're at". I had a very rough idea in my head of what I wanted to do but not a lot of specifics. I am definitely finding that I'm better at getting stuff done after I have a bunch of the graphical materials prepared ahead of time. That's probably something I'll continue doing if I'm working on something solo. 

And a Fistful of Dollars

If I was going to continue working on this with the outlook of releasing it as a full game, I would probably do the following:

1. Change the theme away from candy to robots (mainly to prevent trademark issues, but more so because robots are awesome). This probably wont catch the crucial middle-age lady audience that powers Candy Crush Saga, but robots fighting makes more sense than candy magic. Plus I'd have more fun with it. Also screw specific demographics, puzzle games are pretty popular with everyone.

2. Improve the UI and gameplay flow. Add some more concepts that can be added piece by piece to increase game depth. More clearly define and simplify the battle system. Add more bells and whistles/rewards to the main gameplay. 

3. Add RPG elements to the progression to the player can have more control over playing it the way they want. For example, having each tile type as a different attack, allow each player to choose what attacks they want to specialise in for big damage, etc. Hit combos to power up and do a special attack. Choose the parts you want for your robot to make your own designs.

4. Add a better goal, or multiple minigoals for the player to aim for. A bigger focused overarching narrative might be better but also give players other goals to pursue or ignore as well. Make collecting parts rewards for games, compete in infinite arenas for highscores/cash. 

Candy Jam #3: Game complete!

So after a week of hardcore crunch I managed to complete my entry for the Candy Jam! Check it out in all it's glory here:

http://bigstompyrobots.itch.io/scrolls-of-candy-the-apple-of-memory-saga

I really need an early night after some of the nights I've had recently, so I'm going to save the postmortem for tomorrow, and maybe also check out some of the other entries, but please check mine out and give it a rating! Oh and if you have any feedback please do let me know... It's the only way I'll get better:P Thanks!

Candy Jam #2 - Non-random random tiles

Today was pretty productive, so why not check out this demo of how it works so far?

http://www.bigstompyrobots.com/candy/

Edit: demo has been replaced with the Beri-remix of the completed game.

I thought I had the tile stuff pretty much done and dusted, until I exported the demo and run it in the browser... So in the dev environment everything comes in randomized but for some reason the html5 version doesn't want to randomize on a tile by tile basis for some reason. There's also a weird bias in the clearing mechanic as well... but I'm not sure I'm going to have time to look into it. Since it doesn't break anything, for now it's totally an intentional feature.

Tomorrow I'm hopefully going to be able to get the battle mechanic working. Essentially the player and an AI take turns at seeing who can pick the best batch of candy in a short amount of time, loser of which takes damage. I have some options for adding a little more depth to it, but it's all going to come down to time really.  If I can get it done quick that will hopefully leave Sunday to add a little more depth or some nice bells and whistles. I still have a couple of other art things that should probably get done as too, like a title screen, and every time I look at the game I see another element that could be done better, so I suspect I'm going to be using all the time I have.

Candy Jam #1 - Scrolls of Candy: Apple of Memory Saga

So, apparently the people (and there's been 2 of them so I assume "the people" is more accurate than "a person") demand more BSR.

Since it's been a while, and indeed it's a new year, I may as well state for the record where I'm at... So towards the end of last year I was made redundant from my job as a train whisperer. Since I hadn't really had a proper holiday for a few years I decided to take a break and spend a little time taking it easy and playing video games/wallowing in self pity. Then Christmas happened. Then searching for a new job happened. Then my sister's wedding happened. Then Australia Day happened. Now we're here.

It's sadly looking more and more like I'll be unable to pick up a new job in the industry any time soon for a number of reasons, but I don't want to stop making games or trying to improve myself as a game designer. Regardless of what I end up doing employment wise I want to get back to the stage I was at at a couple of years ago, where I was at least making new things weekly. This time though, with more of a focus on game design or at least improving the skills I already have.

So with all that in mind: I plan on entering as many game jam type things this year as possible. I had intended on entering the Global Game Jam 2014 to start the year off, but unfortunately it clashed with my sister's wedding. Instead, I ended up latching onto the Candy Jam, a protest jam against King.com's suspect legal practices. I wont bore you with specifics, so check out the link if you want to know more.

Because I like overkill, I've named this attempt "Scrolls of Candy: Apple of Memory Saga". I guess the gameplay will be a mash of Candy Crush Saga with Puzzle Fighter and a side of Magic: The Gathering. I've done the majority of the art (see above) but I've been pretty slack over the last few days. I've still gotta do the code, and I haven't really made a falling tile puzzler (or at least, haven't really attempted on in a while) but I think I can handle it before the deadline of February 3rd. However, the other Jams this year that are only over two days, I might have a bit of trouble doing everything by myself.

Oh and also... This isn't the only thing I've been working on. I actually started something else before the end of the year that's maybe around a third/half done, but at the time I was more in the mindset of just getting things done rather than talking about doing things. As it turns out, that might have been the wrong way to go about it... If I've learnt anything from these last two months, it's that it doesn't matter anywhere near as much how good you might be at something, it's more important that you talk the talk. I guess that's something I need to work on. Also, I'll show stuff from the other game after this jam. Maybe.