A brand new game
for Windows, Linux, Mac, HTML5, 3DS Homebrew and more
27th July, 2013
@Madgarden's wonderful little retro shooter has finally been released to iOS, this week, so that's getting the Weekend Retreat treatment!
It makes quite a change from AGameAWeek's fast pacing and insane difficulty levels, as you leisurely float from side to side, gently blasting away at the bad guys!
23rd July, 2013
The BoopyBots return, to dance in this week's teensy little game.
Yes, it's a quickly cobbled together game, and it isn't all that big, or clever.
What can I say, I've been doing a lot of background stuff!! Crazy times ahead.
18th July, 2013
I don't give up, very often, but on this occasion, it's unfortunately going to happen to my big Month-Long project.
I seem to have narrowed the problem down to the following issue.
... Wasn't hard enough!
It seems that, nowadays, I can only tackle a project if it's got enough of a challenge attached.
Either a game has to be coded in a stupidly small amount of time, or the game needs to have lots of new things required, to keep my interest held.
16th July, 2013
This week's game was suggested as a silly idea by someone who plays Words With Friends against my mum!!
The two started chatting about Spiders, or something, and the idea of battling spiders with toothpicks somehow came up.
I'm not quite sure, it all seemed a bit odd and random, but in the spirit of AGameAWeek, here's a game of it!!
16th July, 2013
13th July, 2013
I was going to post about @Madgarden's upcoming shooter "Chillaxians", this week, but when I asked him if it was safe to post it, he replied .. "Well I dunno, not done yet, heh."
So, guess that's not happening, then!
Still, follow him anyway, the game's looking great!
Instead, here's @GlenMcNamee's latest PlayMyCode game, which is a platform/math game.
You can play Number Runner here in your browser.
12th July, 2013
In yet another example of AGameAWeek Gold plucking out examples of games I'm currently reworking, here's a great little blast from the past!
AGameAWeek Gold is our occasional dip into the pool of previously released games, taking a look at what I've previously released on this day in history.
9th July, 2013
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!!
5th July, 2013
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.
4th July, 2013
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.
3rd July, 2013
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!
2nd July, 2013
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!!!!
1st July, 2013
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.
The target will be an all new RetroRaider adventure.
28th June, 2013
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
26th June, 2013
Every Single Week
Not Good AdviceThe 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.
LanguageKeeping 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.
ToolsThey'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 StyleIt 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 WheelConstantly 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 IncludesWhat 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.
IdeasHead 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!
FreeformIt 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.
ScheduleCramming 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!!
FailureAnything 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!
26th June, 2013
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
25th June, 2013
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.