Point n Click Adventure Game Demo

View the Project on GitHub RichardMarks/islandadventure

Island Adventure Title Screen


Developed for a NOGDUS contest. This very short point-n-click adventure game sits on top a powerful data-driven adventure game engine.

Developer Journal

Below is my developer journal with the more recent entry at the top.

Journal Entry Oct 31, 2009 10:04 AM

This is my final developer journal entry for this project, and I wanted to close with a small update. I modeled a 3D hand and rendered it in Wings 3D to use as the mouse cursor. I've never made a hand model its not the best, but it does the job I think. The items never were able to be redrawn. Rachel had no time, and my attempts didn't work out, so the ugly programmer art version still exists.

I thought of a way to make the game more like a game, though I didn't have the time to finish the idea, so it was scrapped in the contest build. Perhaps later I will expand the engine to support the ideas that I had. (animated scenes, puzzles, keys, locks, timed scenes, scripted events, and world inhabitants)

This project was a double-first for me. I've never written a point n click adventure game, and I have never made a fully data driven game before. Both of which, my entry to the contest are. It was a lot of fun, I learned a lot, and I have yet another item to add to my ever expanding experiences.

Journal Entry Oct 31, 2009 6:37 AM

At this point everything is done. It's not particularly fun, because its so short, but making it any longer really isn't going to be possible, as there isn't time to design and draw more scenes. The few items to collect give you something to do, and finding your way through without dying and having to start over give it at least somewhat of a challenge. I'll try to get Rachel to draw the collectible items so that they are consistent with the other graphics..but as of now, they clash horribly because I'm just not an artist. So programmer art is all that they are.

The "engine" that I developed during the past 30 hours is actually quite cool. It uses external files for setting up the available resources (images), and which scenes to use. And, the scenes themselves are setup using external files as well. This means that the executable could be used to create more games that work the same way. The title, credits, and menu screens are all implemented as scenes, so even that is configurable. One of my best pieces of work to date in that its reusable out of the box. Compile it once, and can make a lot of games. There is no limit to the number of scenes, or pickups.

So all in all this was lots of fun. I'll post the code and binaries later.

Journal Entry Oct 30, 2009 6:08 PM

As of now, all scene art has been completed by Rachel, and I've got the navigation system working. My next goal is to add end-game logic so that the game doesn't just leave you at a scene with nothing to do as it does now. Then, following that, my intention is to create the title and credits screens and tie that into the game with a game state module. I had to take a break for a few hours thanks to real life situations..blah.. I guess I needed a break after 16 hours of non-stop sitting here working on this! I'm not going to show the new art until its release time, to keep a surprise.

Journal Entry Oct 30, 2009 11:01 AM

The game art has been delegated to my good friend. and it looks fantastic! Thanks Rachel! I'm having difficulties with the navigation module..and I just split the project into a bunch of files because it was a nightmare to find anything in that one large source file. still moving forward...back to figuring out that world nav issue.

Journal Entry Oct 30, 2009 7:38 AM

I've implemented the scene loading stuff, so now I'm going to start on the world navigation code. Then all that is left I think is drawing the rest of the scenes .. and then testing/debugging and cross-compilation for you winblows users

Journal Entry Oct 30, 2009 5:40 AM

Decided to implement my scenes as an external script. Just got the scene definition file parser implemented. About to start the scene generation code that implements the functionality of the scene loader.

.scn language definition

begin {scene|pickup|exit}
end {scene|pickup|exit}

in scene block

name = string
pickups = integer
exits = integer
background = string

in pickup block

name = string
image = string
x = integer
y = integer
bounds = integer integer integer integer

in exit block

image = string
x = integer
y = integer
dest = string

parsing rules:
trailing and leading whitespace means nothing
empty lines mean nothing
lines starting with a pound # sign are comments
tokens MUST be spaced out

Journal Entry Oct 30, 2009 3:19 AM

I just finished up a resource manager, scene manager, and implementing item pickups. My runtime still looks the same as the last screen shot, so I'll just show my debug text.

$ ./island-adventure 
loaded scene1.bmp
loaded scene2.bmp
loaded scene3.bmp
loaded scene4.bmp
loaded scene5.bmp
loaded scene6.bmp
loaded scene7.bmp
loaded scene8.bmp
loaded scene9.bmp
loaded rope.bmp
loaded candle.bmp
loaded matches.bmp
loaded north.bmp
loaded south.bmp
loaded east.bmp
loaded west.bmp
setting up scene manager
adding scene West Beach
found rope.bmp
destroying scene West Beach
releasing resource scene1.bmp
releasing resource scene2.bmp
releasing resource scene3.bmp
releasing resource scene4.bmp
releasing resource scene5.bmp
releasing resource scene6.bmp
releasing resource scene7.bmp
releasing resource scene8.bmp
releasing resource scene9.bmp
releasing resource rope.bmp
releasing resource candle.bmp
releasing resource matches.bmp
releasing resource north.bmp
releasing resource south.bmp
releasing resource east.bmp
releasing resource west.bmp

Journal Entry Oct 30, 2009 1:02 AM

I've decided to scrap using pre-rendered art, as rendering will take way too long. The first render said it would take 20 hours, and I need no less than 9! So, I'm going old-school and hand-drawing everything in KolourPaint.

Attached is a screenshot of my runtime Island Adventure Screenshot 6

Journal Entry Oct 30, 2009 12:15 AM

Okay, at this point I have about 80% of my art modeled...but the time consuming shit follows. The rendering process. This has me worried. I only have one computer where I am now, and so if my laptop is stuck rendering models...I'll not have a way to code the game! I'm going to use the Kerkythea stand alone commercial renderer software (its free and renders better than 3ds max and maya!)

Journal Entry Oct 28, 2009 6:32 AM

I have decided that I am going to develop as much of the art before the contest, and instead of using the Rubicon engine architecture, I'm going to just hack the entire game during the contest. I think I'll have a better chance of having a game at the end of the contest in doing this.

Journal Entry Oct 28, 2009 3:20 AM

Just got a clean build of my engine project. Its not much from the outside, but its a nice start. It consists of 27 files, 1772 lines of code, 658 lines of whitespace, 1494 lines of comments, and 7 lines with comments and code on the same line, reaching 3931 lines total. Stats courtesy of the Code::Blocks Code Statistics Plugin.

I've got a Newton Physics system, a Multi-Emitter Dynamic Particle system, PNG image support, a reliable random number generator, a custom high resolution timer, and cross-platform support thanks to using Allegro as a back end. Next I think I'm going to start the world editor tool project. Until next update...

Journal Entry Oct 28, 2009 1:53 AM

I'm creating my project directory hierarchy now. I chose to use a nice structured hierarchy for my project to help speed up the development cycle a bit. Its far easier to locate things when they have a proper place to be, than if everything is tossed in a single massive directory.


Next up, I'll start writing the engine core. I have chosen to call my engine Rubicon.

Rubicon (ROO-bi-kon) noun

A point of no return, one where an action taken commits a person irrevocably.

I'll write more once I have that finished. Until next update...