As well as AGS, the Wintermute Engine is worth looking into as well: http://dead-code.org/home/

Things in the game

-----------------------------------------------------------------------------

Key

GREEN - Definitely happening.
YELLOW - Probably happening, need confirmation.
RED - No idea whether it's happening.
-----------------------------------------------------------------------------

Basically I really need feedback on everything red or yellow, as it effects the code, story, artwork, and overall quantity of work we all have to do. The sooner I know the better.

Just to expand on some ideas...

Mini Games: When I say mini games I mean anything that takes us to a new interface (except the inventory).

I like the idea of having a reoccurring puzzle that's just part of the game mechanic, something like the Elder Scrolls lock-picking system, or maybe something like this for repairs/upgrades: 

Are we having a fake operating system?

Conversation System: Interface needs discussion, as in are we going to have text floating above their heads (like in The Dig), text in a box (like in Gemini Rue), or a new screen (like in Gabriel Knight: Sins of Fathers)? Or something else entirely?

Protagonist -> Stats : We discussed upgradable parts and combat systems, if we're doing either of these things we need to decide on a system.

Camera -> Pan -> Up/Down : This is self explanatory right? We need to decide this soon!

NPC -> Click to Interact -> Animation : Having a "facial expression" conversation system would eliminate any need for animation cutting down work, (unless we did animated faces within the conversation system).

NPC -> Buddy : Did I dream that we talked about a "click on your buddy to generate a hint" system?

Environment -> Click to Interact -> Doors to Access Connected Environments -> Animated or Static Images: What's the setting and how shall we make the door mechanic work?

Audio -> Voice : Personally I don't think voice acting adds anything to a game, and can detract a lot from the overall quality when done badly. Just my opinion though. What do other people think?

"Asset Creation" explained

This is not an amendment to the previous asset creation posts. I realise from your collective feedback that I was doing a pretty crap job of communicating (sorry about that) so I'm going to try to explain things more clearly.

Basically when we put sprites into the game the way it works is it reads that image file in a vertical order at a set height and width. So take this example: This is what the entire file looks like.

You could tell it to divide the file up into 128 by 128 pixel "rectangles", resulting in this output:

It only reads from the top left hand corner in the y direction, but you can offset it in the x direction by adding the width to the default value (which is 0). Here is an example of the output of a 32 by 64 pixel rectangle offset by (1 x width) in the x direction:

Since I'm offsetting using the width rather than a different value each time, every graphic needs spacing at equal distances. Here is a diagram to summarise everything I've just said:

The game automatically calculates the size of the file and will apply the cropping to everything in that file equally. The best way to store images in this manner is to put similar sized images together in one file. Here is an example from the last game I made.

File ONE:

File TWO:

In that game the image file was processed horizontally. This game processes things vertically. Either way, same principle.

As you will notice from the last image, there is an awkward quantity of white space at the end, which leads me onto my next point, which is FOR CHRIST'S SAKE I'VE WRITTEN THIS SENTENCE 14 TIMES AND EVERY TIME I'VE TRIED TO EXPLAIN STUFF IT'S RESULTED IN A LONG WINDED MATHS EQUATION. ...sigh. Ok, try again.

• Image's must fit within bn1 by bn2 pixel rectangles.
• Similarly, file dimensions have to equal bn3 by bn4 pixels.
• bn1 must be less than or equal to bn3.
• bn2 must be less than or equal to bn4.

Does this make sense?

Anyway, here are some templates I made for you:

https://www.dropbox.com/home/Public/Templates

"size.psd" is the above image and has a load of stuff that is the exact size's I'm talking about when I refer to "bn". Unless we have bullets we probably won't have any 2 x 1 pixel image files, but note that the bn sequence can go in any direction. Easiest way to figure it out is just to think of the binary equivalent. (0, 1, 10, 100, 1000, 10000, 100000 etc). 

The ones called "environment template [something].psd" are for environment artwork.

Basically the light blue boxes are the size of the screen. The character will always appear on top of the "background" layer, and behind the "foreground".

Save "environment template multilayer" as png-24 and "environment template standard" as png-8 as described in the last asset creation post.

I'm going to implement a camera panning system so feel free to make the environment larger than the screen size in any direction. 

Hopefully I've done a better job explaining stuff this time round, but as usual ask questions and call me out on it if I start assuming you know something you don't or don't know something you do.

Asset Creation 2

Some amendments to the previous "Asset Creation" Post:

File Format and Transparency:

You know how I said I "might" implement a png reader? Well I just did implement a png reader, and consequently we not only have transparency working properly, but also we have gradient transparency. Gone are the days in which we were limited to pixel dissipation techniques. So forget everything I said about bmps, forget picking a default transparency colour, those things take up too much memory and we can do better than that now.

(New category!) Optimisation:

Now since we're on the subject of memory efficiency, I'll take this opportunity to mention that when saving files in Photoshop, instead of using "Save As" press Alt + Shift + Ctrl + S (windows) or Opt+ Shift + Cmd + S (mac) to bring up the "Save for Web & Devices" window.

If you're not familiar with this already, it's basically an image optimisation tool that enables us to cut out all the crap from the image files (like meta data, unnecessary transparency etc.)

So basically, once that window's opened up click on the "optimized" tab (top right corner), then look at the bottom of the right hand column on the right, (second line down), to check out the file size. As a general rule, our goal is to try to get the file size as small as possible without sacrificing image quality. We can use png-8 for non-gradient transparency. Have a play around with the settings in the left column, see how few colours we can get away with. Some files may need to use png-24 which is perfectly fine.

By the way "Percent" lets you zoom in and "Preview" mimics different systems, so if you're using a mac you can see what it might look like on a windows machine, (apparently).

*

Everything I said before that wasn't contradicted by this post still applies.

Asset Creation

Now that I have animation working, here (as promised) is the asset creation post. 

Firstly, THIS IS IMPORTANT:

For technical reason we’re going to work using these numbers as much as possible:

0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024... Etc.

From now on I shall refer to these numbers as “bn”, so when I ask for “bn-1” I mean “one less than a number in the above sequence (of your choice)”.

When there’s more than one “bn” value I’ll number them, so “width = bn: height = bn” would mean “I want a square”, whereas “width: = bn1: height = bn2” would mean “I want either a rectangle or a square”.

When I say “n” I mean literally any decimal integer.

Hopefully this isn't too tedious to remember because I guarantee that it will seriously cut down our collective workload in the long run, but for the love of God if this starts to suck the fun out of the project for anyone let me know and I’ll just make a bunch of templates or something.

File Format:

For now the game only reads bmp files. (Although, I might write a png reader later in the unlikely event that it becomes necessary.)

Image file dimensions must always conform to bn1 x bn2 pixels (although the images themselves can be any size you like). More on that later, (see sprites).

Transparency:

For anything you want to appear transparent, change that pixel colour to rbg(255, 0, 255). 

Actually technically any colour can represent transparency so if you want to vote on another colour I'll change it. I picked this colour because I doubted we'd ever need it for the artwork, also it's easy to remember, but I understand that it's kind of headache-inducing so I appreciate that there might be protests. All I ask is that you pick a colour that's rgb(bn1-1, bn2-1, bn3-1) and that once decided this stays consistent throughout the entire game.

Sprites

SOME OF THIS MIGHT CHANGE! Be emotionally prepared for that. What is absolutely definite though, is that we will use sprite animation a lot, and it's quite possible that every graphic in the game will end up becoming a sprite.

This bit is only 90% definite: When making sprite files the area in which the graphic is drawn needs to be bn1 x bn2 pixels. This dimension needs to remain consistent for every graphic in that file. The file also has to be bn1 x bn2 pixels. (Even when this means an annoying amount of white space.) I will re-evaluate this decision after further testing and research.

Whenever there's animation, that animation needs to align vertically* and all sprites in that animation need to have the same width and height - such as this example.

*Would people prefer horizontal? Let's vote.

Right now animations can loop, oscillate or play through a set number of times. I'm tempted to add some more advanced animation controls (ie memory efficient blinking) but want to get the game to a playable state first.

Naming conventions

Use camel case, always starting with a lower case letter.

Environments start "environment", protagonist animations starts "protagonist", non-moving items start "staticItem", animated items start "animItem" any npc animations start "npc" ... there's a lot of undecided stuff so I guess just call anything else whatever and I'll sort it out sometime.

Audio

I don't know what format we'll use yet (probably wav but see how it goes) however this is something that we all need to think about as we go along. Voice actors and music aside, we'll need sound effects, and unless anyone knows any sound technicians we're probably going to have to take responsibility for this. We should make lists of sound effects we're going to use and post them up here, then collectively gather resources, book out the uni's sound recording studio and make a day of it. We can also rent a sound recorder from OASIS for any awkward stuff we can't take into the sound studio (like water, traffic and nature). Additionally the library has copies of the BBC sound effects libraries which we can chop up and use (legally). Athena building has Pro Tools 8 (decent sound editing software).

I think that's everything for now.

Programming Update 1

My monitor resolution is 1280 x 960, the game is currently 320 by 200. Here is a picture of it in "standard" and "full screen" mode.

I tried capturing it in different bit depths to show you the difference. Above is 32 bit. For some reason 8 bit (bellow, right) came out looking significantly worse than it did on screen, but even so it basically couldn't handle the red corner at all. The 16 bit version (bellow, left) is an accurate representation of what it looked like on screen.

Personally I'd like to stick to 320 by 200 in 16 bit because I like the look of it, but we can play around and see what works better. Ultimately it's Liz's decision since she's in charge of artwork.