Thinking about how to deal with interiors -- looking at The Dig and Gemini Rue, a lot (not all) of interiors are done with this kind of extreme high one point perspective. And I think other areas are based on pretty much the same with just some libertys taken with perspective and such.

If you guys have any ideas of how to do interiors, though, post em up!

Drawing a genuine smile in the eyes is really difficult so I guess Frank is just a big lying jerk (or maybe there is something wrong with his brain).

Here's Frank -- I haven't got an interface in mind for the question/expression system and the actual npc face art will probably have to be a bit smaller to fit into that. But yeah I can do a bunch of expressions (hopefully) fairly easily in this style:

If one of you wants to mock up an interface with him, I can send you the PSD.

background practice

I don't know what style we're going for so I'm swinging for generic run down future city with this. Does the scale of the person look right?

Lighting will be added on a seperate layer - maybe a few (night / day / non static lights)

Let's talk androids 2

Just an extension from the last android post - as I felt these guys were worth taking a look at too.

Couldn't find a picture of this so here's the trailer - Moon robot! Seriously watch this film if you haven't already.

Wall-e and Eve

Mega Robot - (best bit's the facial expressions)

Hank

Jules

Helper

No idea who this is...

Another nameless one

And another

There was another really cool bit of cg art but I seem to have lost it. I'll ask Rhys next time I see him.

i think it gets cut off too much :(

LETS TALK ANDROIDS

Oh my god this new blogger interface is terrifying. I will try to make a coherent post but if all my photos are upside down, it's not my FAULT.

Look I am just going to add some photos of androids. And robots. And maybe cyborgs. Look, the terminology isn't important JUST LOOK AT THE PHOTOS

I, Robot (I have never seen this film):

Bicentennial Man: (This film fills me with sorrow, god, I can't even remember if this is what he actually looked like ever):

Kryten:

I mean-

Data:

"Actroid"(this would be really boring for us; it's just a person, especially when tiny and pixellated. I guess the same goes for Data but he is wearing a cowboy hat and I can't bring him down.):

Asimo:

C3PO and R2 (something non humanoid would be pretty cool, actually):

For example, my favourite Star Wars robot:

ROBOCOP

Terminator (also just a human with skin, albeit a hulking Arnie)

and the jerk terminator (DOGGET NO)

I don't know whether we want to define a world and then figure out what robots they would love and nurture or come up with a rad design and fit the world to it or WHAT

ROBOTS

Whether for character design inspiration or just pure entertainment, check this out. Awesome robots!

http://www.youtube.com/user/BostonDynamics

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?

Walking Dead game.

http://www.telltalegames.com/walkingdead

I have high hopes for this, looks like an interesting game mechanic. Nice artwork too. It's getting released tomorrow, you can get 10% off if you order it today so just wanted to give you guys a heads up in case you're interested.

I'm going to get it. For research of course.

"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.

Was thinking about the animation system and decided to rummage through some sprite sheets for testing purposes. In my searches I came across this art by Agnes Sato. I really like the proportions of the people, also think dissipating pixels like this is a brilliant approach to translucency.

This was also quite a cool way of animating I thought, using blurred images to smooth the transitions. I don't know who the artist is for this.

Anyway, just thought I'd share.

Combat System

Are we having a combat system?

Whether we are or not I'd like to throw some ideas in and get a discussion going. Obviously the story and puzzles take priority, but there's no harm in thinking about this sort of thing.

A turn based battle arena style systems would be fun to program. Very old school, and very enjoyable when strategy is involved.

That said, this worked well in games that were combat heavy, no idea how well it'd work in a game that's combat light.

Sword and Sworcery's combat system is pretty cool, it's time based, you click on the sword or shield depending what the thing you're fighting's doing. Also unlike normal games, stuff you fight doesn't get tougher, you lose hp as the endless battles take their toll on your health.

We could also do a text based combat system through a computer interface. I'll give that idea some more thought...

Any ideas on this matter? What are your favourite combat systems and why?

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.

More on image quality

Top: 16 bit.
Bottom: 32 bit.

I've come to accept that it's impossible to demonstrate image quality when converting a bmp to whatever's stored when you press "Alt + Print Screen", to a png, to another png, HOWEVER, this will give you more of an idea than my previous demonstration.

Next task as far as programming's concerned: Animation. After that I'll do a post on asset creation so we can get making this thing for proper.

Pixel art is awesome.

I got all excited looking at pixel art and decided to have a go myself. Behold, apartments of the future.

(Yeah, that's a dude from Gemini Rue, I added him to show the scale of things.)

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.

Plot Idea

How about this for a plot idea?

Z is a standard model android, political activist for the Android Rights Movement and police detective. He investigates the series of brutal "android harvesting" crimes, and strives to identify and bring down the organisation responsible.

z

oh my god i have no idea what I am doing with pixel art

I'm gonna keep sketching and seeing how stuff translates into this kind of style. I wish I could find some tutorials or info that aren't just "how to draw a pixel tree in mspaint"

Useful Links

 Interview with Gemini Rue's creator:
http://www.gamecareerguide.com/features/946/postmortem_joshua_nuernbergers_.php

Before Gemini Rue, I had worked on a five-year-long failed epic before giving that up and completing my first game, La Croix Pan in 2007. From those previous projects, I experienced the weight that over-ambition can have on a game and the importance of constraining your scope to reasonable limits. Because of that, I was determined not to let over-ambition prevent Gemini Rue from ever seeing the light of day like so many other independent projects. It's so easy, especially when you are starting out as a game designer, to get seduced by delusions of grandeur, endless feature additions, and revisions to make a game "better" (when all you're really doing is modifying, not improving content), and so I made the incentive to safeguard myself from that while creating Gemini Rue.

I did this by trying to get the entire game done as fast as possible, regardless of how the game looked, played, or felt -- I opted to finish it first, and then go back and revise it; otherwise, there was a good chance that I would never complete the game. By building the entire game from the ground up in skeletal form, I had a fully playable build within eight months

Pixel art tutorial:
http://shatten.sonores.de/2010/01/12/how-we-make-our-graphics/ 

Eye Upgrades

Annoyingly you can't add pictures in the comments... (You hear that google? "ANNOYINGLY" I said!) ...so I'm starting a new post in response to the first two comments of this thread: http://thepointandclickgameproject.blogspot.co.uk/2012/04/inventory-concept-sketch.html

I agree, body upgrades should progress the story in a linear way. I was thinking about the eye system and wondered whether to have the upgrades just focus on more of the spectrum. The upgrades could all be used to help investigate crime scenes or spy on people.

Here's an idea for how the upgrades might work for the eyes. I wasn't sure what order the character obtains the upgades in. Obviously x-ray would have to come after UV but infrared could come in at any time.

I like the idea of a little side plot. You need an eye upgrade but you don't have the money (or something) so the shop assistant (or whoever) makes you go find items for him.

We need to nail a style. I've had a poke around and found screens of some cool 2d games:

Machinarium

 Gabriel Knight: Sins of Fathers

Space Quest 6

More Space Quest stuff here: http://hardcoregaming101.net/spacequest/spacequest.htm

 Sam and Max Hit the Road

The Dig

 Broken Sword (these games are gorgeous)

Beneath a Steel Sky (this game is free and SO GOOD, PLAY IT)

 Monkey Island