Resolution #2: Minimal Update

Sunday was spent mostly with architecture.  Most of my game world is going to be grid based, so I'm setting up visibility calculations accordingly.

I hope to have something rendering by end of month.

Resolution #1: Discussion

There are generally two types of New Year's resolutions: those where someone tries to improve themselves by correcting a perceived failing of their own, and those where someone tries to reach a goal that has been eluding them for some period of time.  Both require publicly talking about them because once you talk about a resolution with someone, you are more committed to the path.

I have one resolution this year, and it is one of the latter ones.  Specifically, I want to design, create, and prepare for release one new game this year.  I may not be able to release it (yet) due to a clause in my employment agreement, but I can create it, and talk about my progress as I work through it.

The reason behind this resolution is two-fold.  First, I've been out of game development for six years now, and I've not been able to successfully complete any of my side game projects during this window, either due to time constraints from work or motivation issues.  Second, I've had a fairly significant question since we released "SiN Episodes: Emergence" and since Valve released "Half-Life 2: Episode 2" that I've been struggling to answer.

The real question is: why is it so hard to successfully release an episodic first person shooter?  I think I have an answer for it, and it's that answer I want to explore this year.  Specifically, I think the issue is the toolset we have for developing shooters.

Levels in first person shooters are generally broken out into encounter areas and connecting areas.  An encounter area is a highly polished, highly produced area, and a connecting area is usually a hallway or some simpler area designed solely to get you from encounter area to encounter area.  Combat may occur in both areas, but the encounter areas are what people remember.  Connecting areas are designed to be forgettable.

The issue is that we have the same toolset for both, this toolset is designed to make construction of encounter areas easier, and generally this toolset makes iteration expensive to do.  The really sad part is that due to the standardized rules of video games, we have the proper tools for both, but this toolset isn't properly linked. 

Look at the simple level designer built into "Portal 2" and look at "Hammer" in the Source SDK.  Using the "Portal 2" editor lets people build amazingly complex levels, including ones with almost the exact same puzzles as shipped in the retail game in a fraction of the time, but they all look the same...there is nothing memorable.  However, you can quickly iterate on the puzzles and get them to the point where the gameplay is there.

Trying to build the same levels in "Hammer" takes significantly longer, but you have significantly more flexibility, can make each level visually and thematically distinct, and as a result make them more memorable.  However, iteration takes significantly longer.

I'm thinking of writing a toolkit to try to bridge these two worlds: a level editor that works mostly like the "Portal 2" editor so that you can quickly generate your environments and iterate on the gameplay, and then once you are ready to take an area and turn it into a proper encounter area, you can select that area, export it out as an encounter area in an editable format for something like "3D Studio MAX" or "Hammer" or "3D World Studio," and then edit it using the proper tool for the proper job.  Once that is done, that encounter area acts just like a building block.  You can move it around like a block in the initial editor and have all of the links properly wired up as the connecting areas get additional edits, and the encounter area can also be handed off to other people for concurrent work.

I only have Sunday's blocked out for this work, but I think I can get this done.  I'm going to be using Visual Studio 2012 Professional as my development suite, with Visual C# used for the tools and Visual C++ used for the game code.

Today is all design and project setup.  Next Sunday is code time.

RomTerraria End Of Support

Sorry that this is why I have to come back to the blog for a bit, but I don't have any choice in the matter.

Effective December 1, 2012, I will no longer be supporting RomTerraria in any way, shape or form, and I will have to take down the auto-update version.

The source code will still be available and is released under the BSD license.

There are a lot of things going on behind the scenes, not all of which I'm going to be able to talk about until around this time next year, but there is some exciting stuff coming which requires me to do something I don't want to do first.

Java Must Haves #1: LittleEndianDataInputStream

Since I started working for Amazon, I've still been able to work with C# and JavaScript from time to time, but most of my time has been spent neck deep in Java.

Mind you, Java isn't my favorite language. The more I mess around with it, the more it feels like an iceberg of compromise. So, I'm going to start posting links to things that have helped me make Java suck less.

The first involves DataInputStreams. In the "infinite wisdom" of Sun/Oracle, DataInputStreams must be big-endian. The vast majority of data files produced outside of Java on x86/x64 systems are little-endian, and the lack of a little-endian data stream makes file interop a total pain in the ass.

Fortunately, a little-endian stream was created and the code is public domain. Thanks to Peter Franza for creating the code and releasing it.

http://www.peterfranza.com/2008/09/26/little-endian-input-stream/

HOWTO: POST a file to an .ASHX generic handler

Problem:
You want to be able to POST a file from a generic HTML form to a generic ASP.NET handler (.ashx).

Solution:
First, make sure that your file input control on your HTML form has a name.  If it doesn't have a name, you won't be able to access the file on the server side and it will appear not to have uploaded.

<input name="uploadedFile" id="uploadedFile" type="file" />

Second, make sure that your form action has an enctype parameter set to "multipart/form-data."

<form action="Upload.ashx" method="post" enctype="multipart/form-data" />

Now in your HTTP handler, you can either access that file by the name you provided it on the form:

context.Request.Files["uploadedFile"]

...or you can iterate through the files by key...

foreach (string f in context.Request.Files.AllKeys)
{
  context.Request.Files[f].SaveAs(
    HttpContext.Current.Server.MapPath("~/App_Data/" + ...));
}