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!