This week's game is a lot like last week's game, only slightly more colourful, and with baddies that come at you!!

Apologies that I wasn't more imaginative, this week!!
Read More

Over the years, @Spinal_Cord has continued to perfect the stylings of the top-down maze genre.
Taking his cues from an old C64 game he once played, Sensitive, he has created a whole host of variations on the theme over the course of his time doing game-dev.

His latest effort in this genre sees him using the Monkey language, along with some lovely simple 2D commands, to generate a faux-3D look, which wouldn't look out of place in an old-school tech, or scene music demo.
Read More

The great big 1.5 update of SpikeDislike2 is now available from the Android or iOS App Stores.

This version brings the HUGE end mode, Choose Your Own Dislike, which features all those lovely options that the original game had, along with a couple of new ones.

SpikeDislike2 v1.5 is available for iOS and Android. If you've already got it on your device, visit the store to check for updates.

I've enjoyed the development of SpikeDislike2!

What started, originally, as a simple minigame in an Advent Calender quickly took on a life of it's own, and the iOS version became a favourite for those who bothered to look beyond it's crappy graphics.

But with an overly complex option screen gave a multitude of different scoreboards, and although that worked in a pre-GameCenter world, the second I came to integrate GameCenter, the whole project suddenly hit a wall.
How could I cram all those options into GameCenter's limited scoreboard methods?

The answer was, of course, that I couldn't. And so SpikeDislike slowed to a crawl, as new ideas simply couldn't be fitted into the chaotic sprawling mess of icons that was the menu system.
It had started so well, but GameCenter broke my game.
Read More

Over the course of July, I'll be working on a nice new edition of RetroRaider.
It currently looks a lot like the old versions, but I'm hoping to tweak things quite a bit, this time around.
No idea how well this'll turn out, but .. It oughta be good!

So, in honor of July being RetroRaider month, here's a nice new RetroRaider Desktop.


Click for MASIIVVVEE (3200x3200)

Estimated Time of Arrival : Let's say July 30th!

1I had planned to make a semi-sequel to NeonPlat, this week.
I'm not really sure why that didn't happen!
Instead, we have a nice swimming floating game, which is in no way inspired by the diving in Animal Crossing..
... AT ALL!!!!
Read More

As we head into July, I've decided to dig my heels in, and aim for another bigger project.
Much like April's "Stringy Things" month, this will probably take over the usual AGameAWeek schedule, resulting in a smaller number of releases over the course of the month.

.. hopefully, it doesn't run into a dead end, like Stringy Things did!

For this project, I'll be using TWO languages.
Monkey will be the main language, and DevKitPro/PALib will be the ported languages, for DS Homebrew.
'cor!

The target will be an all new RetroRaider adventure.

Read More

I'm not very good with "New features" so we'll give this a few weeks before we call it a permanent new feature, but I thought it was about time I start giving shoutouts to some of the other indies and their wonderful games that occasionally blip across my twitter feed, from time to time.Read More

Every Single Week

Not Good Advice

The following is not advice, and should not be taken as such.

People often ask me how I manage to do AGameAWeek. Particularly, how I manage to cram everything into a single week, and then somehow manage to do exactly the same thing every other week, without going crazy.
What follows might possibly help you understand a little more of what goes on in the world of AGameAWeek. Or it might just be a whole bunch of rambling waffling text.
Not sure!!

-=-=-

Language

Keeping it "old-skool"

In the world of AGameAWeek, speed is essential. If I have to spend twenty minutes trying to figure out how a command is supposed to work, that's twenty minutes I'm not getting any coding done.
Familiarity is the key, here.
I grew up in the 80s, in a world full of BASIC. I learned about keywords, variable and loops the old fashioned way.
As systems got more powerful, so did the forms of Basic.
Today, the Blitz/Monkey set of programming languages are my coding environments of choice, mostly because they're an evolved form of Basic.
I'm comfortable with the syntax, the keywords are still mostly familiar, and I find I can usually transform an image in my head, onto the PC, in a relatively short amount of time.

I understand that people learning today, might be more familiar with GUI driven languages. I can see the appeal in those sorts of languages. But they just aren't my sort of language. I find myself struggling to get any actual "coding" done, when I'm instead spending hours at a time trying to "build a scene" or "define a layout". In Basic it was CLS, and then a bunch of drawing commands! I find that much easier to deal with, but that's a personal preference.

-=-=-

Tools

They're not the best tools. They're simply the tools that I use.

The best tools for the job might not necessarily be the ones that everyone else suggests. In my experience, the best tools are those you're comfortable using.
If you've learned all the keyboard shortcuts for one particular program, and can use it swiftly and reliably, then that's the best one for you to use.
If you're just starting out, and haven't yet had any experience with a particular type of tool, then pick one, any one (preferably free/cheap) and then stick with it until you've gotten the hang of it.
Jumping around from one package to another will only mean you'll be spending all the time relearning how to use each and every one, whereas if you stick to a specific one, you'll grow accustomed to it pretty quickly.
Be sure to make good use of the keyboard shortcuts. That's what they're there for!

For art, I use PaintshopPro 7. It's a version I bought whilst still at college, so that makes it at least 11 years old! Scary!
I've recently also started using the App SpriteSomething on iOS. It's handy for doodling quick little sprites on the go.

For sound effects, I use a combination of FLStudio, CoolEdit and BFXR. FLStudio or BFXR are used to quickly generate the little blips and boops, then CoolEdit is usually used to add reverb, pitch bending or other after effects, as well as compressing everything down to smaller filesizes.

Music wise, it depends on the sound I'm going for. Mp3 audio is usually done in FLStudio, Mods are done using ModPlug Tracker, and anything else is done using my own JMTracker, which creates nice random twiddly tunes as the game is played.
For what it's worth, you won't find a lot of music in my games. I prefer to listen to my own music collection whilst playing games, and generally switch off the ingame music whenever possible.

-=-=-

Code Style

It doesn't matter how clean the code is, as long as you know where all the bits are.

I have a terrible memory. I can't seem to hold thoughts in my head for more than about ten minutes, if I'm lucky!
But my Code-memory seems to be a completely separate part of my brain.
For some reason, I seem to have the uncanny ability to put myself back into the exact mindset I was in, whenever I last had a particular piece of code open.

I can jump through the file, pinpoint a particular section of code, and remember exactly what each little parameter of a function will do.
Over the years, this has led to an absolutely appalling code style. If anyone dares to look into my code, they'll be horrified by the methods that I use.
I rarely comment, I use hardcoded arrays EVERYWHERE, and those oddball 80s style 1 or 2 character variable names that everybody hates, are a particular favourite of mine.
For anyone else looking in, it's a freak show.
But for me, it works.
And since nobody ever DOES look at my code, it does it's job.

-=-=-

Reinventing the Wheel

Constantly rewriting the same thing, rather than making overly complex functions that you'll never actually use.

Everybody tells you that it's a good idea to write a reusable function, and who am I to argue. If you know something's going to be showing up again, make it a simple function, then strip it out so you can reuse it later.
This is good practice.
But sometimes you can go overboard.
A good example is a Tilemap Engine.
What would you want a Tilemap Engine to do?
It might do multiple layers, parallax scrolling, animated tiles, colour cycling, collision.
.. Or it might not, and instead be just a flat scrolling map.
It's hard to know before hand, so any good reusable Tilemap engine will have to account for all possibilities.
Your "simple" Tilemap will inevitably end up spanning thousands of lines of code, to account for every possible circumstance.

In my eyes, that's a mess!
Instead, every time I need a Tilemap, I redo it from scratch.
It isn't hard to achieve. A simple little for-loop, screen boundaries, grid points, keep it simple.
And if you need any special abilities, you can simply tweak the code as you go.
Once you've done a whole bunch of these things, it becomes second nature, and you can quickly whip up a Tilemap, particle engine, or anything else, in a few minutes.

-=-=-

Include the Includes

What works for one might not work for the other fifty.

Similarly, includes are handy. For the past few years, I've built a "framework" in my current language, which takes care of sprite drawing, multiple resolutions, scoreboards, menus, and all those other things that are typically the same on all projects.
The problem you find with AGameAWeek, however, is that some things aren't necessarily perfect for all tasks.
My current framework, for example, includes a set of functions to draw and use an onscreen DPad. But a DPad that feels great in one game might not be as good with a different game. The other game might need a more analogue style slider.

If all the code used a single "include" base, this would be tricky to implement, without breaking either of the two game's code.
If I dare to tweak a function for the newer game, it might break the old one, thus making future updates impossible.
For this reason, I've learned to keep all my includes within the individual game's sourcecode folder, so that every game has it's own unique copy.
It starts from a simple copy of the template folder, with framework and everything ready for use, then each game is created in it's own unique environment.
All major useful changes are then put back into the template, for future reuse.

-=-=-

Ideas

Head scratching time in the middle of the night.

My ideas come from a variety of sources.
One of the most frequent methods is the "start coding something, and see what happens" method, which usually involves me trying to create random swirly effects on the screen, somehow, then attempting to make it playable, somehow.

Sometimes, I might open up my art package, and start plotting random points until a character emerges, then creating a game around that.
Other times, I might be fiddling around with BFXR, generating random sound effects, when a particular effect jumps out and an idea pops into my head.
A recent source of inspiration is Twitter. Having so many random tweets in your feed can occasionally lead to odd phrases sticking out, and silly ideas forming.

Whichever way it happens, the challenge is to act on it as quickly as possible, before you've forgotten what it was! It's probably also a good idea to jot them down somewhere. I have a fairly large "Sticky Note" pinned to my desktop, with a whole lot of random phrases on it!

-=-=-

Freeform

It doesn't matter, as long as it's fun.

Since AGameAWeek gives me the freedom to constantly try new gameplay styles and ideas, it also brings the ability to develop games in a much more freeform nature than other developers might like.
I don't ever plan out a game. I never have a target, or a specific set of goals.
Things like number of levels, and general layouts are usually generated on the fly, and I tend to work within the confines of what gameplay is emerging from the code, rather than trying to fit the code into a pre-designed set of parameters.

The same sort of thing goes when building pseudo-random generated levels. I'll tend to get some sort of rough level building to work, then fit my game around it's output, as opposed to struggling to get a level generator to work towards a specific style.
It's quicker to build around what you can easily achieve, than struggle to get a certain kind of output.

-=-=-

Schedule

Cramming everything into a tiny amount of time.

The only specific point in my schedule is "New game release : Tuesday morning". Everything else is done as it occurs.
I tend to generally start a game on a Friday, and work on it over the weekend, but sometimes I'll have a great idea earlier on in the week, and spend more time on it.
Every so often, you'll spot a terrible "quicky" game. Those are usually started late on a Sunday and rapidly cobbled together within just a few hours! As anyone who's tackled a Ludum Dare style coding event can tell you, these sessions can be intense, and fraught with danger. But that's half the fun!

I try not to set myself a specific schedule, though. Good ideas don't come from sitting down at a pre-determined time, and forcing them out. They're spur of the moment, random things, and can happen at any time. Go with the flow!
.. Unless it's getting too late, then you really need to come up with something!!

-=-=-

Failure

Anything is possible, as long as you bother to attempt it.

Doing AGameAWeek, I've learned that failure is a possibility. And not only is it possible, it's sometimes fun to do! What most developers tend to do, is imagine an idea that will definitely work, and then build the game.
AGameAWeek allows for the alternative. Since I'll be starting something fresh, the next week, it doesn't really matter if a game idea doesn't work out.
As such, I have an almost infinite supply of game ideas.
Anything that other people have thrown out, I can usually give it a whirl.
If it fails, it's no biggy. Next week will be another game.

This is something other developers can't afford to do. You can't devote months/years of your life, developing a game which might fall flat on it's face. And when it does, it can be devastating. Living with failure is a very difficult thing. I think I'm lucky in the fact that I've learned to just move on, but even still, it can occasionally be tough when a project I really enjoy seems to get completely ignored.

Motivation is the key, and my motivation is simple.
.. Next week's game could be awesome!

Note : This app is included with my Monkey Skeleton, so if you've already grabbed that, you needn't bother grabbing it again!

If you're trying to write games for all these different systems that Monkey can handle, you've probably wanted to shout at Apple and Google for having created so many stupid sodding icon sizes.
It's enough to drive you crazy!!

When I first started building my Monkey Framework, I figured it'd be handy to have a program to create all these silly little things.
This is that!Read More

I wanted to have made a nice big super-sized sequel, this week, but I got sidetracked.
For starters, I played a lot of Animal Crossing, so there's that!!
But that wasn't all, as this week's game took an alarming amount of time to settle into a groove.


Read More

Ever wanted a really insanely high-definition version of the AGameAWeek logo?

Tada!


Click for HUGE!

Now you can hop from your pocket, as Hoppy Bobby makes his way onto iOS!
The initial release is FREE, so you've no excuse not to grab it.

At a later point, I'd like to make a bigger-longer-better adventure mode, and add achievements and things, too. That'll be a Pay-for edition, but for now the original's there, and it's just as swear-inducing as ever!



You can Download Hoppy Bobby here for iOS.
If you're on Android, you can Download Hoppy Bobby here from the GooglePlay store.
And if you're playing on Windows, or want to try it in your browser, you can Download Hoppy Bobby here for those!

It's Hoppy Bobby Madness!!

For the past few years, I've been building and rebuilding a silly little experimental shooter thing called "Horizontal Shooter"
The basic gist is that it's a bog standard horizontal shooter, but with a weird control scheme, and a tail to catch things in.
I also tend to use Horizontal Shooter as a simple testbed, to see what a language can/can't achieve in the realms of simplistic blurry lovelyness.

This time around, since we're also focusing on mobile devices, I've decided to flip things around, and make it a Vertical Shooter instead.
Read More

It's Saturday, and I've not really started a game for this week.

Well, that's not entirely true.
I've actually started three games, this week, but all of them seemed to hit a dead-end pretty early on, so I've not really got anything to show for it.
Read More

As unplanned as AGameAWeek usually is, I at least have a rough idea of what'll be occurring.
Tuesdays, release a game. Wednesday's think about a game idea. Thursday/Friday start a game. Saturday/Sunday bulk the game out where necessary/possible, and Monday finish things up before we release it on Tuesday and start it all over again.
Along the way, we get trips into the AGameAWeek Gold archive, and there are other oddities like the Uninteresting Wallpapers, and other silly little things.



Imagine my surprise, then, when halfway through E3 week, I realised I'd been posting a new/old game, every single day, onto GooglePlay!!
What started out as a shocking "OMG! It Worked!" event for Hoppy Bobby, quickly turned into me digging through my archive of Android games, and slapping up a different one each day.
Read More

Time for an update to my Monkey Framework!
This week I noticed that, having upgraded my version of Monkey recently, Android's Back Button was no longer being recognised, so I took a bit of time to figure out why that was happening, and updated the Framework to suit the new methods.

The Download

Jayenkai's Monkey Framework, as of 20th October 2013 | Blog Post

Older versions

Jayenkai's Monkey Framework, as of 13th June 2013 | Blog Post
23rd March 2013 | Blog Post
25th February 2013 | Blog Post
28th January 2013 | Blog Post

Also in this update..

* The new "Testcard in place of a Credits Screen" stuff.
* A few quick-to-access name based settings, up at the top of the file, because it was starting to wind me up having to keep opening .monkey files, just to change the name of the game!
* URL Data quicky test. You'll want to remove it, but it's in there, and it seems to work ok.
* New version of the Icon Resizer (See below for further details)
* A few tweaks that I've probably forgotten all about.

You can Download Monkey_Skeleton_2013_06_13 here
Read More