Posted on by

Graham Ransom and Simon Pearce are the dynamic duo behind Glitch Games, and the developers of Forever Lost: Episode 1 HD, a new point-and-click adventure game for the iPad/iPhone. Graham asked his Twitter followers for questions on developing adventure games, and shares answers to a handful of the most popular inquires here.

@gtatarkin: How long does it take to make one?

Graham: Naturally it will be different for all projects so we can’t really give a single answer, all we can talk about is our own experiences with our games.

For instance The Hauntening, our first experiment in adventure games, was made in 48 hours as it was for The Techority 48 Hour challenge, however as I’m sure you can guess this isn’t anywhere near as feature complete as Forever Lost.

Forever Lost has taken us around six months but we also worked on three other, much smaller apps at the same time. Those six months also include the time spent deciding on the art style and developing the underlying framework though so we hope to be able to get the second episode out in less time.

If I were forced to make a single answer, I would say you should allot at least 6 months to make a decently polished and lengthy game, assuming you are a small team of 1 or 2 people.

@ftsirigotis: Efficient Inventory System.

Graham: Our system is relatively simple, we don’t have combining of objects or enlargeable item images etc., we decided simple would probably be better.

Our’s works by having a list of all objects that can be collected in a text file. This uses JSON to store all the information about an object like its name, description, text to be displayed when picked up and the frame index into the sprite sheet that contains all the icons.

This file also contains the definition of the actual inventory bar and button used in the HUD that allows us to easily change the look-and-feel without touching any code.

When a player collects an item in the game various events get fired, these allow all the separate systems to get notified and act accordingly.

One of these systems is the inventory itself, it needs to know what the ID of the item was so that it can look up all the required info and display it accordingly.

All the currently collected items are then stored in a GGData box to allow persistence and get sorted based on the timestamp of when they were picked up so that the most recent item is first.

We only display a handful of items at a time in the inventory, requiring the player to scroll left or right to see more. All this does in practice is refresh what icons actually get displayed and destroys the previous ones, this allows for an essentially unlimited amount of items to be collected but no degradation in performance. Naturally if you did have a large amount of items in the inventory you would probably want to develop a better way of navigating it which is something that we will be investigating for later games.

@theDaveB: How is the art produced?

Simon: When Glitch Games began, all of the artwork was hand drawn and then scanned onto a computer and then edited using Photoshop. We used this method for our first few app releases, including The Hauntening. This method was new to me since most of my previous experiences with game art was using 3D modelling software. It was not really possible to use any 3D software for The Hauntening since it was a 48 hour competition and 3D art is far more time intensive than the 2D art that we produced. We originally started this way with Forever Lost, by merging hand drawn art and real textures in Photoshop, but soon realised that we wanted to work heavily with lighting and shadows and the best way to do this was to use 3D rendered images. We decided that we liked this style because of the induced realism and correlating immersion levels so we stuck with it. We modelled almost every visual element using 3D modelling software and then applied textures downloaded from free texture websites. These were then manipulated in 2D editing software and voila.

@theDaveB: Did you play graphic adventure games on other systems (Atari ST, Amiga etc…)?

Graham: I’ve grown up playing all the LucasArts and Revolution games, my favourite game of all time being Monkey Island 2. However these were all on the PC, I’ve never really played any on the older consoles and really should.

I’ve been playing a lot on iOS recently, for research purposes naturally, and have also backed the Double Fine Adventure and Broken Sword 5 on Kickstarter. I am very excited for those as well as The Cave by my gaming idol, Ron Gilbert.

Simon: My first experience with adventure games was with the old ‘choose your own adventure’ books, which I guess was my gateway into adventure gaming. Much like Graham, I have also never really played many graphic adventure games on consoles (that was reserved mostly for RPG’s and platformers) but I do remember playing Myst on the PC from a young age and being very captivated.

I have also been playing a lot of adventure games on iOS recently, and I have discovered a lot of hidden gems. It is nice to see a resurgence of the genre and I am really happy to have worked on at least one in my lifetime.

@davidcondolora: What is a good way to do pathfinding for an adventure game with Corona SDK?

Graham: In Forever Lost we didn’t require any pathfinding as the player sees through the eyes of the protagonist rather than controls his movement directly. This was a conscious design decision that would both allow the player to be drawn into the world whilst at the same time reducing the overall complexity required for our engine.

That being said though I can still make an educated guess into how the pathfinding for an adventure game might work. This isn’t necessarily the best way and certainly not the only way I’m sure but it should work.

The simplest solution in my mind would be to create a grid-system built up of individual nodes or waypoints where the character can stand. You could then use the A* algorithm to calculate the best path between where the character currently is and which node the player wants to get to.

Although this system would be more than functional and fairly trivial to set up it would be quite limiting as the player would only be able to walk to a few pre-determined locations. You could solve this by putting in lots of nodes but that would be time consuming and would also slow down the pathfinding algorithm as it would have lots more nodes to look at.

I would instead define walkable areas which would simply be a polygon around each node, this way the pathfinding code could still calculate the most optimum path between point A and B but the character would be placed perfectly at point B (where the player tapped/clicked) rather than at the closest node.

@faxilux: What I’ve always wondered is how to do polygon collisions for the walkable area. Is there any trick?

Graham: The first rule of polygon collision is: you do not talk about polygon collision.

In all seriousness and as above, we don’t have any polygon collision (or any collision of any sort) in our game so we may not be the best ones to ask, but based on our own experience in playing games that have walkable characters we can make a guess.

Assuming you’ve got a system that is similar to the one described in the above question then all you really need to do is be able to work out of the point that the player has tapped is actually in that polygon. This is pretty simple assuming one thing: your polygons are convex. You can still do it if you have convex polygons but as you are defining these walkable areas yourself you should just be able to make sure they are all convex to make your life a little bit easier.

After checking whether your point intersects with a walkable area you will only have two outcomes, it is either not in any area in which case you disregard it as the player can’t move there, or it is in a walk-area in which case you then pass that position to your pathfinding algorithm and let it work out the best path for you.


Posted by . Thanks for reading...

2 Responses to “FAQs: Point and Click Adventure Game Development (Guest Post)”

Leave a Reply

  • (Will Not Be Published)