Presentation time

This is it, Tuesday is the real deal.  Some will survive, others will have their dreams crushed.  My team is trying the best we can to make sure we make it forward.  We learned a lot from Thursday's first attempt at the pitch.

Positives:
+We had great length on our presentation.
+The live demo was with commentary, was at least in my opinion, leaps and bounds better than watching a video because we can control the pacing (I am biased though cause I present that portion).


Negatives:
-We didn't have our names on our power point or one page.
-We didn't have enough personality in the presentation, we are selling a humorous game, so we need to show that we have a good sense of humor.
-We need to have our razer and actually talk about it.
-Plug in the controller earlier, so we don't have to wait for drivers to install.
-Come up with the keywords we want to use when describing the art and gameplay.
-End with gameplay, don't go back to slides.


Most of these negatives are easy corrections, a couple lines of typing here, some reordering there and they are complete.  We are going to solve the other few problems tomorrow.  By Tuesday we should be a well oiled pitching machine.

If we do things right we should be able to make it.  I feel that we have one of the most complete demos (we have a simple concept so it was easy to polish), but at the same time we have one of the harder games to sell (point and click is a niche genre).  We have a great idea of what we want to do, but only 2 (maybe 3) games get to move forward, so wish me luck.

That gameplay video I promised

Well here it is, I will be doing a better capture next time I go in to school because I hate the watermark.  At the same time though I don't want to spend 35 dollars for a program that I will only use once (pirating is bad).

We still have to do a couple of minor things such as changing the controls (I am picky and would rather press a face button than a shoulder button), but other than that we are done.  Now onto the pitch!!

A lame excuse for a blog post

Well, after convincing Google that this isn't a spam blog I am back up and running.  Unfortunately I don't have anything all to interesting to talk about for this week.  We are finishing up the last couple of touches on our prototype.  This means that I am just placing in the placeholder graphics as I receive them and bug testing, which is not all that interesting of a topic.

I will update this blog again once I have recorded a video of our prototype (Saturday or Sunday).

See you then.

A new control scheme, a new issue

Since we are creating a point and click game for consoles, the controls will clearly be different because there is no mouse with which the player can point and click.  This leaves us will a couple of different control scheme options.  Most of the existing point and click games on the XBLA marketplace replace the mouse controls with the thumbstick.  That is the thumbstick controls a cursor on screen that you use to interact with the game.  The control schemes work, but it feels sluggish and unintuitive, so instead of using the standard control scheme we decided to create our own.  In our game the player moves with the left stick and can cycle between the interactable objects in the room by using the right stick.  This not only feels better, but also gets rid of one of the major flaws in Point and Clicks, pixel hunting (having to click every pixel on the screen hunting for the area you need to click to complete the puzzle). 

However, we also have added a problem to our game, how to represent which object is selected.  When using a cursor this isn’t necessary, as whatever object your cursor is over is the object you will interact with, but in our game there is no cursor.  We will display the name of the currently selected object, but it would be bad game design if we forced the player to match the name with the graphic.  We then have 2 obvious solutions; either we change the graphic on screen to represent which graphic is selected, or we place an indication next to the graphic (such as an arrow, or actually drawing the name of the object above the graphic).  I think that the best option would be to draw the interaction text directly over the object, but the issue is that it becomes difficult to distinguish when objects are extremely close.  Therefore, from a game play standpoint the best solution is to have a graphical change to represent the selected object (we could also combine this with displaying the text over the object).

When dealing with graphics you have to take both prettiness and user friendliness into account.  Artists work hard on their assets so we don’t simply want to apply an ugly effect that covers their work, but at the same time we need to make a noticeable enough change that the user’s attention will be drawn to the desired object.  I eventually decided on applying an outline to the graphic to represent the selected object.  So if I take an object that looks like this (sorry I am a bad artist):

It would look like this when selected:

We are using XNA for our project, and unfortunately there is no easy (read built in) way to add a border to the image.  After some thinking I came up with a solution where we use the shader to calculate the edges of the texture we want to outline, and draw an outline in post processing.  This is the solution I decided to go with (although I admit that I didn’t do purely the outline to save a little bit of work, it is just the prototype anyway).  This can be done in a few simple steps.  First we render the scene drawing on the selected object with the rest of the scene being transparent.  We then save this rendering as a texture and pass it to our shader.  The shader post process is called for each pixel.  Given our pixel we know that if our alpha is none zero that we are part of the texture and hence not part of edge.  Otherwise, we could be part of the edge.  If we check all of our neighbor pixels and one of them is part of the texture (has an alpha value greater than 0) we have be part of the edge (either the outer or an inner edge).  If we change our color to be the desired edge color we get a result that looks like this:

Ideally I would like to eliminate the inner edge, but the result is acceptable, especially for a prototype.  Overall, I am happy with the implementation because it works for any image, and I can change the color and the thickness of the outline at any point.

A new adventure: the point and click

Well, the bad news is that my game idea didn't get picked, but the good news is that I get work on a prototype for another genre of games that I love, the Adventure Game (Point and Click) genre. However, it is not all sunshine and rainbows, in my personal opinion there are some deep problems with the adventure games of today.

The adventure game genre has been around for a long time. It was once a very popular genre (in the 90's), but has since fell by the wayside and has become a niche genre. While Double Fine was able to raise some 3.4 million dollars via Kickstarter to make a new adventure game, that does not mean the genre is in anyway mainstream. Rather, it had more to do with the fact that Ron Gilbert and Tim Schafer, two of the fathers of the genre, were going to be creating the new game. While I do love adventure games, I have not been playing them for long, so that gives me more of a fresh view on what the genre does well and what it does poorly.

Most of the people who play adventure games today are the same people who were playing them in the 90's. While the number of gamers has grown at a rapid pace since the 90's, the point and click genre hasn't attracted a large percentage of these new gamers. I have been gaming since 1998 (at the end of the adventure games), but I never really got into them because I was a console only gamer until 3 years ago. Only then did I get into adventure games, in fact, only because Sam and Max: The Devil's Playhouse offered a promotional hat that I could wear in Team Fortress 2. I immediately enjoyed the game, being a huge comedy nerd, the humor stood out and sold the genre for me. Coming from being a mostly FPS gamer, the characters, plot, and dialog were so much more fun and compelling than anything I had experienced before. But I quickly noticed some problems.

Not to be an ego maniac, but I would list myself as an intelligent human being. Never before in a game had I found myself completely stumped, but in a point and click game this happened almost immediately. I don't mind having a hard problem to solve, I know what I need to do, and if I play for long enough I know I can figure it out. But, in adventure games, I frequently find that this happens, but it is usually because I have no idea what I am supposed to be doing. For example, in Secret of Monkey Island, why would I ever think to step on a board 3 times to scare off a bird so that I can pick up a herring to give to a troll. I never would, and without a walk through I would have never figured it out. I know how good it feels to figure out a difficult problem, but it adventure games it is all to often a feeling of relief, rather than a rush of joy. While I am trying to figure out this strange ordering of events I spend an hour walking from one side of the town to the other, because my character only moves at a snail pace and there is no fast travel.

When you compact these two elements together it can become obvious why many players trying adventure games for the first time find them either frustrating or boring. It is easy to identify a problem, but the difficulty is coming up with a solution. The second problem, long travel times, is easy to solve; either add a fast travel, or allow players to run rather than just walk. This seems simple, but it makes the game much less grating when you realize that you missed an item and you will have to walk to the other side of town. Action games can keep the tempo up by throwing enemies at you on your backtracking path, but once you run out of dialog in an adventure game there is nothing to do but watch your character walk slowly across the screen.

Unfortunately, the other problem is a little more difficult to solve. We want to allow beginners to be able to progress at a reasonable pace, but the same time though we want experienced adventure gamers to be able to play the game without hints. Drawing from the limited number of adventure games that I have played, in only one game have I had a general idea of what I needed to be doing at all times. In Sam and Max: The Devil's Playhouse there was a mechanic that allowed you to see into the future. In the future sequence you would see the last second or two of the solution to the puzzle in the area. For instance, you would see that a monkey teleports off the edge of a roof and falls to the street knocking him out. This mechanic did not tell you how to solve the puzzle, rather it gave you a vague idea of what the outcome needed to be. You still had to solve all of the puzzles by using your own intuition, but at least you would have a general idea of what you needed to be doing (which is much better than wandering aimlessly).

My solution, is a little more scalable. We have decided that our main character will have a small pet companion (like a hamster or something). My thoughts are that we could use the hamster to indicate hints based on the hint level. If user wants to play with no hints, the hamster will not do anything. However, if they want to play at the highest hint level, then the hamster will direct the user by standing next to the door they should enter, or making motions to signify the use of a certain object. This could easily be scaled to any value in between as the user desires. Furthermore, the hamster hint level could be scaled dynamically based on the amount of time that has passed without the user making progress towards solving the next level. Meaning, the experienced point and click players could go through the game without ever seeing a hint, but those who are new to the genre will receive more hints. Then everyone would be able to complete the game without the use of a guide, and without wandering aimlessly for the better part of an hour.

In conclusion, point and click adventure games are amazing experiences that I wish more people played and enjoyed. However, I believe that for this to happen some innovation needs to be done to ease players into the experience. Recently, more gamers have expressed the desire to play games that have more depth in terms of story and characters. The best adventure games of times pasts contain plots, characters, and locations that are leaps and bounds ahead of any shooter that I have ever played. These games have the atmosphere to impress gamers, but the mechanics need to improve enough to not scare the new gamers off.

Venturing into shaders

This post retells my venture into creating a simple shader, it is not a step by step tutorial on how to write a shader (maybe another time).

Shaders allow you to make beautiful games, allowing special effects such as depth of field and bloom.  I like making pretty games, but I have always used other people's shaders rather than writing my own.  The internet it a great code base to get familiarized with the concepts of the code and find some simple code that people have already written.  However, at some point you either have a bigger problem than someone has written code for on Stack Exchange, or you just want to learn how to write the code yourself.

Today I fit into category B, and so I waded out into the new world of shaders.  For the game I pitched last week it is essential that the game can filter out colors (make certain colors white) until a certain point in the game.  Last week I modified a stock shader to make sure I could get the RGB value of a pixel and selectively show it.  However, the shader was in no way robust and only worked for very specific values of red, green, and blue.  I determined, that the minimum requirement for my shader would be the ability to filter out 10 distinct colors (red, green, blue, yellow, orange, pink, purple, brown, black, and gray) whenever I so desired.  It is a much simpler problem than say depth of field shader, but it was a starting point nonetheless.

As is common when one starts coding I brainstormed to come up with a couple of different implementation methods.  However, not knowing what a shader would allow me to do in terms of data structures, I decided that to start I would use a simple color range to calculate which color I had.  Because my elementary school had art projects I am able to visually distinguish between the desired colors*.  However, I can't tell you off the top of my head what RGB value equates to a dark shade of cyan.  So doing what most would do in this situation, rather than blindly guessing I opened up photoshop to get some reference values to start with.

I quickly realized that using the RGB value was a horrible idea, but it seemed to me that the HSB (Hue, Saturation, Brilliance) value was much more consistently grouped.  I don't really use HSB values often so I went logged onto the Internet to see how a HSB value relates to a RGB value.  To my rejoice I found that a color's hue defines it location color wheel that contains red, yellow, green, cyan, blue, and purple.  The color wheel already defined values for 5 of my desired colors, so I decided that this would be an easy first implementation.  XNA color structs don't provide hue values, so all it took was one more quick search and I was off.

Once I got the equations coded up, I was excited because I thought all I had to tweak the ranges to yield orange and pink (black and grey are easy because they are the lack of brilliance and saturation).  Unfortunately I was wrong, I ran into the first road block of the day, the color brown.  By that, I don't mean that it was a roadblock that caused some tricky coding, rather it was a roadblock in that it took a long time to define what brown is.  It ranges between so many values that you can't do a simple if statement as a catch all.  However, I come to you as a proud man, in a spite of genius I was able to defined the mysterious brown and define its muddy qualities exposing it to the world**.  At this point I stumbled upon a much, much bigger problem.

When you write a shader in XNA you are allotted a maximum number of arithmetic instructions that you are allowed to apply to every pixel.  The keyword being instructions (not operators), meaning however many instructions you have after the compiler runs threw your program reorganizing your code as it pleases.  In other words, it becomes extremely difficult to make a few simple changes in your code base to cut down on the instruction count (removing some operations does nothing, adding one operation adds 10 instructions, etc.)  While I could just specify that it should compile under a system that allowed me to use more instructions, what is the fun in that (Read: it didn't work on my GPU without me writing a vertex shader).

After much toiling, I was able to get all of my code to work with one expection, I haven't been able to sneak in the cutoff for brown.  This means I am able to draw just brown, but I can't draw yellow without the brownish yellow values.  While I don't like leaving incomplete code I had to throw in the towel for today and work on some other items.  I will leave the preliminary results (minus some threshold tweaking and fixing the aforementioned issue) below, but don't worry, I will be back with better results in the future (sooner if my game idea gets picked).

Results:
Full Picture:

Picture showing only certain colors (clockwise from top left: red, purple, blue, brown):

*Elementary school isn't my highest education level, I was making a joke.
**It wasn't that hard, I am being melodramatic.