Draw, Animate, Code & Play etc…

Drawing
Over the past couple of days I’ve tried to prioritise sorting out my environmental tiles, but still haven’t really come to a conclusion. I tried to test out my new idea for rocky tiles with real parts of the level design, but so far can’t seem to make them work well as they do on paper! To stop myself from ending up in a rut, I’ve discarded ALL rocky texture tiles for now and replaced them with a plain purple colour, which can easily be swapped for a textured tile when I decide what it will look like!


I made a little progress with the rock pattern around cave entrances however. I considered using straight edges around rock outcrops so that straight edges around other level features wouldn’t stand out so much, but didn’t feel this worked as well as the more natural, uneven design which is closer to my previous trace design.


I tried this design here with my previous rock texture, but decided that the rocks looked better against a more plain background. Even if I bring a heavily textured tileset back for platforms, I may stick with a plainer tile for cave walls.

Whilst trying to ignore all the complications of seamless tiles etc, I’ve diverted my attention to creating more Japanese-looking objects for the level. I’ve started by taking objects I’ve already made and adapting them to suit various instances, which is great for level continuity.


Amongst these smaller features I’ve been working on some large objects inspired by specific Japanese things, like this shrine gate:


and this bridge:


Although, the reason for the bridge’s funny shape is because it follows the shapes of my platform mask tiles. I may round this off later to make it look nicer and have the character follow the tiles rather than the shape of the bridge.

And I finally got round it pixelising the small food stand that I designed about a week ago. You probably can’t tell even if you’re Japanese, but I attempted to write ramen “らめん” in hiragana on the sign!

Without the ground texture tiles, the game definitely doesn’t look as “nice” as it did before, but the more empty spaces of the level are starting to fill up. (I haven’t built the lights in this screenshot either, which is why it looks so dark!)

Animating
In time for a proper working level prototype, I wanted to get many more character animations in. Before now, I’ve simply had one continuous running animation! I’ve only created the basics so far: running, stopping, jumping and climbing ladders.

To make the character stop you could use a single frame of the character just stood still, but I like to keep the character moving to ensure the player that the game is still running! Before now, I’ve used a breathing motion by making the character move slightly up and down, but where Hana is made of so few pixels, any rearrangement of pixels results in something far from “subtle”. I think a breathing animation is out of the question, unless I find a clever way to do this. For now, I’ve created a couple of frames that make her look fidgety when stood still, and a blink frame that flashes up irregularly.




For the jumping animation I’m currently only using one frame, although I would later like to add another to differentiate the character jumping up and coming back down.

My climbing animation is currently universal, used for climbing up and down ladders. This particular animation works best for climbing down ladders, so I may later add another one which looks more like climbing up a ladder.

Coding
The main bulk of the coding I’ve done over the past couple of days has been in the character step function, which controls the way the character moves. With all the new sprite sequences, I’ve had to customise things like image-scrolling speeds for each individual animation and can no longer rely on one over-ruling command.

I’ve split character movement into two separate “modes”-one fore running, jumping etc. and one for climbing. If the player is not on a ladder or in mid-air, the player is on_ground (this is a ready-made variable that comes with the Grandma Engine.) If the player is on_ground, the rules of horizontal movement apply, including sprite sequences and player input. If the player crosses a ladder but does not climb, ie. does not press up or down, then the rules of on_ground still apply.

if on_ground && place_meeting(x,y,obj_ladder) && !keyboard_check( key_up ) && !keyboard_check( key_down ) {
can_c = false; }

But, if the player crosses a ladder and does press up or down, can_c (short for can climb) becomes true, and the rules of ladder climbing apply. This code is pretty similar to the code I wrote before for vertical movement, but I’ve added sprite sequences and image-scrolling speeds. As you can see, I’ve applied the climbing animation twice, once for each vertical direction, so if I wanted to I could use two animations that would represent each direction.

else if (place_meeting(x,y,obj_ladder)) {

vspd = 0;
can_c = true; {

if (keyboard_check( key_up ))
vspd = -S_MAX_V /4;
sprite_index=spr_hana_climb;
image_speed=.1;

if (keyboard_check( key_down ))
vspd = S_MAX_V /4;
sprite_index=spr_hana_climb;
image_speed=.1;
}

I haven’t written much other than this, but I’ve added a few lines of code for more warp objects throughout the level. This has helped me create some clarity where caves are involved, as I have created two new rooms for caves that are joined to the main level by these warp points. Now you can see a definite distinction between the outside and inside of the cave parts!

Outside:

Inside:

Playing

Adding a lot of visual features doesn’t occur easily whilst play-testing, due to the fact that in Game Maker the platforms are made of these red-block objects that cover the background imagery. They need to do this so that I can see where I’ve put platforms! But at the same time, I can’t see if I’ve made a mistake with the imagery below. So when I’m editing tiles and want to see how they look in-game, I have to add these red blocks temporarily and delete them again afterwards. One major criticism of Game Maker is that it doesn’t allow bulk actions to be applied to all instances, so each block must be added and deleted individually, which is a looooong and tedious process. My main focus is still on visuals, but I’ll build the complete level for a play-test from volunteers next week.

This concludes my lengthy summary or the past two days!

I’m still having problems capturing videos of gameplay, so until I work out how to sort this out/find an alternative to Hypercam, I’ve strung together some screenshot highlights of my game so far.

This week’s aim was to create a level which was playable from start to finish and included some of the functions that would be seen in the final game. The result is a playable place-holder graphic level with a basic placeholder HUD (“Heads Up Display”) containing level progression info. Below is a list of all the current features…

Incorporation of the EasyLighting system

So far I mainly have lights inside the first building, some of the lights can be seen in the image above. When the player moves into a light source, the light affects the brightness of the sprite’s colours. A comparison can be seen below, when the character moves into an unlit area.

Ladders

When the character comes into contact with a column of red lines such as this one, the custom variable “canc” is enabled which I’ve set up to allow for vertical movement. I’ve used some of the Grandma Engine’s custom variables such as “vspd” (vertical speed) and “S_JUMP_SPEED” (jump speed). The current climbing speed is half the value of the jump speed, which I’ve currently set to -5.25. This has actually resulted in climbing speed which is faster than the walking pace, but I’m keeping in for now for faster level testing!

if (place_meeting(x,y,obj_ladder)) {

vspd = 0;
canc = true;

if (keyboard_check( key_up ))
vspd = S_JUMP_SPEED /2;
if (keyboard_check( key_down ))
vspd = (-S_JUMP_SPEED) /2;
}

Press up to warp function

Previously, warping from room to room occurred on contact with the “warp” object (invisible in this screenshot!) In this instance, the warp object is placed in front of the door, so that when the character came into contact with the door, the character would be automatically transported outside the building. The X and Y coordinates for the door are the same in both rooms, so the character arrives in the new room in the same location.

Since incorporating this feature, I’ve adjusted the mechanism to only warp when the “up” key is pressed. This was quite simply achieved by adding the line:

if keyboard_check ( vk_up )

to the code!

Item Collection/Level Progression

I’ve dotted some of my sakura objects around the level for player collection. On collision with the character, the blossoms disappear as they did before to avoid the player picking up the same flower twice.

I’ve created a very basic HUD which tells the player how many flowers they’ve collected. Each time a blossom is collided with, the figure (starting at 0) goes up by one. This affects the global variable “gamescore”, controlled by a HUD object which always appears in the player’s view rather than on a fixed point in the level. The object contains draw commands which tell Game Maker to draw the figure “0” followed by a string of text saying “/30”. This is currently just a random figure as there aren’t even 30 collectable items in this level…

Player Hit Points

Underneath the level progression information is a figure representing player health. This needs the most work so far! I’ve currently set this figure to start at 5, and decrease by one every time a black blossom is collided with. These blossoms also disappear on contact, so you can only be hit by something once. The “enemy” objects probably won’t disappear in the final game, for now I have simply set it so that health cannot reach 0. I don’t currently know what will happen when this figure reaches 0! But it will probably re-locate the player to a designated re-spawn point.

As for the rest of the level, I’ haven’t really made any changes but I’m hoping to work on some new tiles soon. Tracing the level design by hand has given me some really good ideas for environmental tiles and objects. Hopefully I’ll get a video up and running very soon!

EDIT: My Devlog Video 1 is now online! And nearly works.

Level Testing

Building Buildings
Today’s level testing began with constructing the Ryokan in Game Maker using the tiles I already have. For the first time, I connected a room with the inside and a room with the outside of the building through a “warp point” at the door. Using the “warp” function in the Grandma Engine transports the character to a another room at the same XY coordinates, so the door is at the same point in both rooms.

Lighting
Today I tried out the EasyLighting extension with my level for the first time. The system requires two colours- one ambient colour which masks the entire screen, and one light colour which is the colour generated by the light source.

The colours I used in my original text were the colours used in this tutorial, which resulted in a murky/swampy ambience!

Too murky


According to advice given in the tutorial, the ambient colour should be a darker colour and the light colour a contrasting bright colour, unless of course you want to create a light which is darker than your background for whatever reason… For this opening level of Hanami, I felt that a pink scheme would be appropriate. I started off by using hex code reference websites to look for bright shades of pink for the light colour, however weirdly when applied it came up with some weird results. My first attempt turned out these very blue lights:

Too blue


To get the right colours, all I could do was test hex codes until I found a good match.

Good light colour match


Ambient light colour too dark (and purple)


Subtle indoor lighting!

Placeholder Tiles
I made these quick tiles to act as placeholder for the rest of the level. They probably won’t make the final design, but they add a little variety to the design while it’s in its early stages! Unlike my “black-block” test level, this tileset contains sloping tiles and add gradients to the level.


Combining this with the building set makes the level design seem much clearer, especially where buildings and caves are concerned. The pink line down the middle is made of my flag tile and represents the waterfall!


This level is now completely playable as it is. For now I’m carrying on the visual design on paper by tracing the mock-up, while I’m working on creating some of the gameplay functions digitally! My first objective is to create a points system when flowers are collected. Here’s where my tracing is up to so far:

“Practical Game Design”

From Practical Game Design: The Rule of Threes on Gamasutra
In the first level of any game, there are three introductory steps which the player should experience before being thrown into the game. These are demonstrated perfectly in the original Super Mario Bros for NES:


1. Introduce the Challenge as simply as possible
In Mario, the “threat” of an approaching Goomba is built up gradually. The player must learn how to avoid or defeat this enemy, and in order to learn the enemy must appear in its simplest form.

With this challenge, the designer tells the player:
“There is such a thing as a Goomba.”


2. Do it again, with a slight variation
After the first threat is defeated, another one appears but in this case, the environment is different and therefore the behaviour of the enemy is changed. The player is learning that challenges will present themselves in different ways.

With this challenge, the designer tells the player:
“The land around the Goomba can take different shapes”


3. Step 3: Do it again, with another twist
In this example, the threat is doubled, but there is more space for error. Is it a more difficult or easy challenge than before? Or is it just that it is different?

With this challenge, the designer tells the player:
“The Goomba will not always come alone.”

These challenges take place in the first 10 or so seconds of the game, but it is the only introduction that the player needs. After this is over, the game can change shape and form and the player knows to expect this and react accordingly.

I’ve taken this into account for opening of Hanami, I may even include a single room at the beginning of the game which acts as the “tutorial level” before the player is taken to the rest of the village. At the moment, I’ve taken a slightly different angle and instead of presenting the player with challenges, I’m thinking of introducing the objectives.


For example, here you the Ryokan on the left. As the player moves to the right, they are immediately met by a Cherry Blossom, which is collected as the player passes over it. The player now knows “the objective of the game is to collect cherry blossoms”. The next two blossoms involve the player climbing and jumping, so the player is now familiar with environmental change. The last blossom is a new idea. It’s a red blossom which damages the character’s health. If the player isn’t paying attention, they may be tempted to try to acquire this deceitful blossom, but here I’m trying to show the player that they should avoid it! I’m currently trying to think of more environmental hazards; spikes are so over-used in 2D games so trying to think of more realistic “enemies”!


In Game Maker, I’ve started to test level design with various character physics settings, to try to get the right jump distances etc. My wood structure tiles make great place-holder blocks for test levels! I’ve used them here to test this very basic opening level (although currently the flowers don’t do anything when they are collected. I’m still working in a modified version of the Grandma Engine and haven’t actually started an original project yet!)

Easy Lighting Extension for Game Maker


One thing I’ve picked up on by reading developer’s forums and various articles on the Internet is that while Game Maker can do almost everything you could want it to, it doesn’t necessarily do it well.

I noticed this myself during my last Game Maker creation when it came to audio. Despite the fact that it gives you the option to use .mp3 format audio, it turns out that it doesn’t support most types of .mp3 (or some such nonsense.) I ended up using some hefty .wav files, which Game Maker compressed during the gameplay and completely changed. The majority of my sound effects seemed to sound like static! This is why people with the technological know-how have stepped in to save non-programmers by providing downloadable extension software for GM, including several which improve audio handling, which seems to be GM’s lowest point.

When it comes to in-game lighting, I’ve previously found ways to cheat by overlaying semi-opaque objects on top of light-emitting objects. In Somnium I used this to make some objects appear to glow, however this ultimately had no effect on the game’s lighting on the whole. The image above is an example of an extension called EasyLighting V7.0.2, which handles light generation in Game Maker. It is the same extension which Gabriel Verdon uses to create his moody, atmospheric lights in The Archer.

As you can see from the top example, there are two types of light generated. One is a dim, yellowish light and the other is a bright white light which casts shadows off the objects around it. Both of these lights use the same sprite image, which is a circle shape with a radial gradient. This is similar to my previous lighting “objects”.

However, the extension settings are used to draw these sprites to certain specifications, rather than simply overlay the same image in the same way repeatedly. This reduces the amount of sprites and used, and helps game performance.
You can read an in-depth description of all the extension’s functions in this tutorial here, which also runs through how the extension works and how to implement it!

The advantages of using a lighting system like this one is that it can help create the game’s desired atmosphere. The lights work by first applying a colour overlay, which immediately changes the tone of the game. Each light then has its own individual colour and brightness, which can give a really good sense of light and dark in the game.

To test the extension, I made some street-light style lights in the Grandma Engine. I recorded a quick little demo of the lights in action so you can see how effective they are in changing the ambience of a room. I’ve tried to capture the difference in the colour of the character (square) when under and away from a light source. These lights worked especially well at highlighting objects when several were placed close together.

Weekend Update #2

Just a recap of the goals for the week just gone:

Continue to create and gather any conceptual work including a Game Design Document (GDD). Experiment with the Grandma Engine in order to configure it for the game. Research software add-ons and extensions which will be useful.

So…how am I doing?
I’ve managed to write and maintain my GDD pretty successfully, but “conceptual work” is currently mainly limited to character designs. Over the coming week I’ll hopefully work up a good amount of level & item designs to being some game assets, as well as continuing to work on the in-game characters. I’ve experimented with the engine to a degree, however I still haven’t worked out things like my physics settings which must be arranged soon before I start any real level design! I don’t want to design any immense jumps only to have a character who can’t reach them… As for add-ons, I’ve previously researched things like lighting engines and sound dlls, which will come in useful, however I can’t say this for sure yet! I’ll have to re-schedule this research for next week.

So what have I been doing?
Whilst avoiding doing any really ambitious game development, I’ve been working on a few more character designs. I started off by thinking about a template for male in-game characters, as so far my character-cast is looking very feminine…

The guy on the left is my “generic man” character. He probably won’t appear in the game, but is the “standard model” for all male characters to be made to (The kanji symbol means “man”). After drawing him, he got me thinking about Japanese hairstyles. In photos, you can probably tell Japanese guys from Western guys just from the tops of their hair. Japanese styles tend to be longer and frame the face, whereas the normal Western man tends to avoid this, probably because it looks quite feminine. The epitome of androgynous hairstyles is demonstrated by Japanese pop/rock-star Gackt, who inspired the hairstyle in the top right. But as well as long, straight styles, I’ve noticed that Japanese males pull off spiky styles really well! This is either the symptom or the cause of many spiky-haired anime characters, famously including Akira Toriyama’s Goku from the Dragon Ball series. However, the first example of epic spiky hair that popped into mind was Cloud Strife from Final Fantasy VII. Although not a real person, there is no match in the competition for awesome spiky hair.

From this short study on hairstyles, I moved onto my first male character…who has no hair. His working title name is Kannushi, based on the name of Japanese Shinto Priests. I’ve tried to write an extremely brief bio on all my characters in the GDD, mainly explaining why they didn’t suffer the same fate as the village locals (although details of this incident are a little hazy at best. I’m thinking of changing my original idea…) For my final GDD I’m hoping to write up a bit more on the characters, including useless information like favourite food etc.

Kannushi:
a Shinto priest who was immune to the curse, and prompts Hana on her journey.

He’s dressed in a traditional Kariginu, with traditional hat and ceremonial wand at the ready. Although he acts as Hana’s main guide throughout the game, I want him to be a silent and mysterious character, who appears and vanishes without warning. On top of this, one of my objectives is to create indecipherable dialogue between all characters, as Western and Eastern characters naturally have language restraints…


The second character I started to work on was a Maneki Neko or Lucky Cat character. I think I originally said that Hana would have a pet cat, as I didn’t want her to be entirely alone. I realised this was silly, as you probably wouldn’t take your cat on this sort of “holiday”. So the cat’s ownership has changed. Maneki Neko now belongs to the owner of the hostel which Hana temporarily stays at. Another mysterious character, at the very start of the game Maneki Neko resembles a Lucky Cat figurine. It isn’t until the “Hanami Crisis” that the cat jumps to action and leads Hana to Kannushi. Whilst not saving the villagers, Maneki Neko enjoys snoozing and dreaming of fish.

As well as this, I’ve done a little bit of graphics development, just trying to figure out how to make tiles that work. I haven’t really started any official research into Japanese buildings, but just from the research I’ve been doing so far I’m starting to get a feel for them! I made this small little Photoshop mock-up of a Japanese hostel room strictly using tiles only. It doesn’t work as a room as it has no access and no space for movement, but it only uses repeated tiles so I’ve made minor progress here.

It has however brought to my attention more proportion issues. These bunk-beds for example are 64 pixels long, which is 4x as long as my character sprites, so this little tester probably wouldn’t be suitable for a game asset.

“Elderly Platforming”

I’ve already mentioned that for this project I will be using Matt Thorson’s Grandma Engine for Game Maker, to give the game code a head-start. I’ve listed some of the advantages to working this way below.

Character Sprite Testing
The engine provides a default character sprite, which is a 16x16px red square. This can be swapped for any sprite of any size, although in my case I don’t need to make too many changes to the sprite size! All movement codes and physics are pre-determined, which presents a great opportunity to test character sprites and animations etc. without having to provide basic code before hand. I don’t currently have any sprite animations ready enough for testing, but I swapped the red square with my Hana sprite in order to get a feel for size and proportions. You may notice in the video that I’ve edited the sprite slightly again, because I felt that the sprite’s colour scheme should match the scheme used by the flowers more closely. I don’t know if this will stick yet.

Physics Testing
The grandma engine has cleverly listed all physics-defining code as one list of custom variables, which can be easily changed by anyone who isn’t familiar with GML or game coding. This is useful for defining your own game-specific physics, and can be swiftly changed and tested in the Grandma Engine before being applied elsewhere!
From playing around with the default settings, I think it’s fair to say that the movement is perhaps a little too fast and the jump distance probably unnecessarily high. This is good for initially experimenting with the engine, but I will eventually slow everything down a little.

Level Design Testing
The engine comes with essential default level design assets, in the form of blocks and slopes which join together to make the platforms of platform games! As well as the standard solid blocks which prevent the player from an infinite drop, the engine provides jump-through platforms, which the player can access by jumping up from underneath but will not drop back through. This is useful for a range of platform types, and something I regret not using in previous developments. I placed flowers around the preset level build to get a sense of how the size of the flowers felt in comparison to the block sizes, and to my surprise they don’t look bad at 16×16. This may all change when the blocks become actual tiles.

Extra Functions Test
There are a couple of nice but unnecessary things that the Grandma Engine provides for you. Things like an optional double jump, which can be turned on and off easily. A more useful function is a warp square, which transports the character from the square to a specific location in any room in any part of the game. This is useful for doors between rooms, rather than using the default scroll room transition.

Synopsis of Study- What I’m Doing And Why I’m Doing It

My learning agreement is nearly complete! The main bulk of the learning agreement consists of the Synopsis of Study, which briefly outlines what I’m doing in as much detail as you can fit into a brief statement. It’s helped me clarify some things which have either gone unmentioned or were simply missing- so here’s an informal breakdown.

Character Sprite concept & inspiration from Adventure Time with Finn & Jake: Memory of a Memory. It's nearly relevant.


What I’m doing
The plan is to create a contemporary 2D side-scrolling platform game. This is a very traditional genre, born from the limitations of early game design. My aim is to use the typical characteristics of this style of game to create something new and fun to old-school players who are familiar with the genre. The object of the game is to collect items and progress through levels, which is pretty much the objective of any 2D platformer if you think about it! Platformers usually follow a simple narrative which explains why the character is running from left to right picking up , and my plot is about revolves around the Japanese tradition of Hanami (for me details see the rest of the Blog).

Mario runs from left to right to collect coins and progresses through levels to find the Princess.

Why I’m doing it
The popularity of 2D platformers has wavered throughout the past couple of decades, but with the strong emergence of Indie game developers since about 2008 they’ve risen to popularity again. From a design perspective, it’s an incredibly easy genre to develop, which is probably why small teams of Indie devs picked it up again. There is now potential to incorporate stunning high-resolution graphics into these games, however the retro “pixel-art” style remains ever popular amongst developers and players. I too intend to use implement a retro graphical style into my game, because it’s such an important factor in the history of computer technologies. If you were to ask what made Super Mario Bros so good?” part of the reason would be that its low-res 2D graphics had a sort of “mysterious digital-world magic” to them. 2D platform games and pixel art are almost synonymous with retro. Mario’s original silhouette is still universally recognised by gamers.

You know who it is.

How I’m doing it
I’m going to draw all game assets myself, using a combination of Photoshop and pixel-art drawing program Graphics Gale. The game will be made in Yoyo Game’s Game Maker 8.1, which is almost the perfect tool for creating 2D games of any genre.
John Sandoval:

Game Maker can do anything.
It’s magic.

(from somewhere on The Archer Devlog!)

For a better insight into the game-making possibilities of Game Maker, see this post from a previous Blog. I initially chose to use Game Maker because it was free and very easy to pick-up. In the creation of games, I’m an asset artist before a coder, so it was important for me to use an engine which didn’t require years of programming knowledge to be able to use well. Since I wrote the post on my old Blog, I’ve bought the standard version of Game Maker, which has opened up even more possibilities.
During this project, to help me focus on asset creation rather than using up valuable time on coding, I’m going to use Matt Thorson’s Grandma Engine, which runs in GM and acts as an easily adaptable platformer basis.

To clarify, I’ve prepared a list of things the Grandma Engine does not have in common with the stereotypical grandma:
Old
Slow

To highlight the positive features of the engine, I also found it necessary to provide a list of the things the Grandma Engine does have in common with the stereotypical grandma:
Gives you candy

Other features of the Grandma Engine include a custom movement system (meaning it does not use the built-in Game Maker movement system), slopes, jump-through platforms, and an An Untitled Story-style room system.


The image shows the building blocks of the engine, which make up the solid platforms in a platform game! When the game is complete, these black blocks will be invisible to the player, replaced by more aesthetic visuals.
As for sounds, I will be looking to sites like freesound.org for sound effects. For background music, I’m going to keep an eye open for any willing composers, if not I will probably use a few royalty-free tracks.

EMP Countdown Day 2

The Archer Gabriel Verdon

This is another persistent source of inspiration for me for several reasons. For a start, the game is currently in development and it just keeps getting better. The reason I can make comments like this is because the creator of the game, Gabriel Verdon, has been keeping a constant online development log since the very beginning. Even if the game turned out to be awful, this 77 page backlog of development is a pretty good tool for someone like me who is still working on finding the perfect game design structure. As a bonus, the game is being made in Yoyo Game Maker 8.0, so most of the development is really relevant to me. As well as a constant update on how things are going, Verdon has found the time to produce several devlog videos which really show how the game is coming along…

From these videos, you can see the full scale of this project. The game must really push the limits of the software in terms of graphics, although I believe the physics are fairly basic for the most part. The development log for The Archer introduced me to a Game Maker document called the Grandma Engine, which works as a 2D platformer engine within Game Maker. The document comes with a simple range of assets and physics, ready for the developer to add graphics and music etc. This is great for non-coders, but has been made in a way that the settings can easily be tampered with to make slight changes.

These images show really early development of The Archer, using the provided assets from the Grandma Engine and a custom playable character. Later, custom graphics are added to the level design and the solid black blocks are set to invisible. So although I really like where this game is heading in terms of inventive gameplay and a lovely pixel-art visual style, what makes this really inspirational to me is its devlog and again, for providing a showcase of software capabilities and possibilities. It looks likely that I will implement something like the Grandma Engine into my next project, especially if it takes the form of a side-scrolling platformer.

Links for The Archer:
The Archer Official Website
The Archer on Indie DB
Online Development Blog on Tigsource
Gabriel Verdon’s Blog