(Untitled)

by Tim
Sun, November 6, 2011 -- 0:29 UTC

Remember, remember, the 10th of November…

Gunpowder, Treason and Plot

http://jamestowngame.com/treason

TAGS: ,

Jamestown Comes Out on June 8th!

by Tim
Sun, June 5, 2011 -- 17:19 UTC

Jamestown is coming out on June 8th

It’s official!

On June 8th, Jamestown is coming to Steam, Direct2Drive, and GamersGate.

See ya there!

-Tim, Mike, and Hal


Jamestown Gameplay Footage!

by Tim
Fri, March 18, 2011 -- 23:29 UTC

Jamestown Logo

Because the people demanded it, we have wrought a Jamestown trailer for your amusement and delight. At last you shall have your precious gameplay footage!


Sound Judgement (A PUN!)

by Tim
Wed, January 5, 2011 -- 22:18 UTC

IGF LogoThis Monday, the Independent Games Festival annouced their Finalists and, to our great surprise we noticed our little Jamestown listed under Honorable Mention for Excellence in Audio!

As those who follow @finalformgames on Twitter will already know, we submitted Jamestown to the Independent Games Festival this Fall. Like most IGF entrants, we held secret hopes of recognition deep in our hearts, but saw it more realistically as a good opportunity for some exposure and a deadline to push hard for.

Needless to say, we are delighted about this unexpected honor! Many thanks to the IGF and judges for their kind acknowledgement.

Given the circumstances, we think it fitting to introduce you to the gentlemen who so carefully crafted our audio experience, and to share with you a little about how we approached the audio for our game.

First of all, we’re pleased to introduce our composer, Francisco Cerda, who works with us remotely from Santiago, Chile.

Here is one of his 4 compositions that went out with the IGF build, entitled “War Upon the East Frontier”.

As an added bonus, we’re pleased to share a brand new track, entitled “Into the Dark Sector”.

I had the pleasure of meeting Francisco while he was visiting Berkeley in 2008. A friend of my former housemate, Francisco stayed with us for a few days, on a few occasions sitting down at the piano for an hour or two of improvisational play. What I heard was expertly performed, dynamic, and emotionally powerful.

We exchanged contact info before he returned home, and have stayed in touch since. When the time came to select a composer, we worked with a few (truly amazing) candidates, but ultimately could not refuse Francisco’s passion, versatility, speed, and sheer compositional might.

Francisco Cerda

The man behind the music.

We decided to eschew the traditional shooter chiptune soundtrack, inspired instead by games such as Ikaruga, Gigawing 2 and Under Defeat. Our milieu and story suggest a more conventional orchestral instrumentation, so we tried to marry that style to the intensity of a wailing Joe Satriani guitar solo. What we ended up with is something that we feel is greater than the sum of its parts.

For sound effects, we turned to our old friend Justin Mullens, with whom I worked on several past titles. While we can’t as easily represent his work here as Francisco’s, suffice it to say that his steampunk-inspired wood/brass/cloth approach to the UI sounds offers something new to the shoot-em-up landscape. He scratch-built all the sounds in the game, employing every trick in the book to find some coherence in the crowded sound space of a 4-player shoot-em-up.

JustinRecordingFireHose

Here is Justin recording a fire hose, that most elusive of sounds.

We are all honored to have our hard work acknowledged, and to be able to bring this honor to the oft-overlooked shmup genre in general. We are working hard to continue to improve the audio experience for our game, so that by the time it ships to you it will provide an even richer experience than what the judges saw in October. After all, the most important external validation can only come in time, when the game ships to the world at large.


Something Very Special

by Tim
Mon, September 28, 2009 -- 17:34 UTC

The following is a fairly technical post about something that came up during our programming efforts. It assumes a certain amount of experience with the intricacies of C++, so if that’s not your cup of tea, don’t pay this post any mind.

I spent some time yesterday integrating my C++ math library with Lua. I have a pretty robust Lua integration library at this point, but it heavily leverages template partial specialization to achieve the ease-of-extensibility that I want. While I have become rather adept in the past few months at dissecting and making use of template error messages, I ran into a confounding error that I simply had to share*.

Here is a C++ program that represents the kind of task I was attempting to implement. The original code was implementing C++-side templated generation of Lua userdata metatables for my templated mathematical primitive classes. The following code snippet, while contrived, should serve as a more digestible demonstrative example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include <iostream>
using namespace std;
 
// A few generic templates
template <int N>
struct Foo
{
};
template <>
struct Foo<1>
{
};
template <int N>
struct Printer
{
  static void Print()
  {
    cout<< "You have " << N << " " << Texter<Foo<N> >::GetText() <<endl;
  }
};
template <typename T>
struct Texter
{
  static const char* GetText() { return "apples"; }
};
 
// Let's call this next specialization "A"
template <>
struct Printer<1>
{
  static void Print()
  {
    cout<< "You have just one " << Texter<Foo<1> >::GetText() <<endl;
  }
};
 
// And let's call this next specialization "B"
template <int N>
struct Texter<Foo<N> >
{
  static void Test() { Printer<N>::Print(); }
  static const char* GetText() { return "apple"; }
};
 
int main(int argc, char** argv)
{
  Texter<Foo<1> >::Test();
}

So, what would you expect to happen when you run this program? I would have expected it to print out, “You have just one apple” and terminate. What I would NOT have expected is for it to spit out this error:

1
2
3
4
5
6
7
8
9
10
11
12
1>------ Build started: Project: TrickyTemplates, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>c:\finalformgames\trickytemplates\trickytemplates\main.cpp(40) : error C2039: 'Test' : is not a member of 'Texter<T>'
1>        with
1>        [
1>            T=Foo<1>
1>        ]
1>c:\finalformgames\trickytemplates\trickytemplates\main.cpp(40) : error C3861: 'Test': identifier not found
1>Build log was saved at "file://c:\FinalFormGames\TrickyTemplates\TrickyTemplates\Debug\BuildLog.htm"
1>TrickyTemplates - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

It was telling me that Texter<Foo<1>> does not have a method named Test in it. But there Test is, right above the call to it! All my efforts to statically analyze the program for the problem were fruitless (in part because the actual code was vastly more complex than this example). So, I did what anyone would do in my shoes, and started poking at it with a stick.

One surprising result: if I changed Printer to take in an additional template parameter, typename T, the error went away.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
...
template <typename T, int N>
struct Printer
{
  static void Print()
  {
    cout<< "You have " << N << " " << Texter<Foo<N> >::GetText() <<endl;
  }
};
...
template <typename T>
struct Printer<T, 1>
{
  static void Print()
  {
    cout<< "You have just one " << Texter<Foo<1> >::GetText() <<endl;
  }
};
...

Well, that’s pretty strange. Needless to say, this did little to allay my worry.

So, I rolled it back and broke out an old tried-and-true technique I picked up while working with the Metrowerks Codewarrior debugger: try moving blocks of code around. Sometimes this is illuminating, and, in fact, I found that by swapping the order of specializations “A” and “B” (see above code snippets), the error went away. Again, not too reassuring, but it gave me a lead by suggesting that something about this bug must relate to the order in which things are defined.

I searched online for all manner of permutations of keywords relating to the situation, and finally found this post on a site about the programming language D (which has many similarities to C++):

“If two template specialization refer to each other, there is the possibility that one of them will try to instance the other before the specialization for the other is created. The result would be either a compile error or an attempt to instance the wrong template. On the other hand, if I’m not missing something, a compiler would also be correct to lazy evaluate specializations, in which case this problem may well not occur. Some way to ensure the desired behavior here would be needed.”

So, my current understanding as to what was going on is as follows: The Printer<1> specialization is instantiating the Texter<Foo<1>> specialization before the Texter<Foo<N>> specialization is defined. This is because the correct order cannot be determined due to two specializations cyclically referring to each other. As a result, it is masking out the later definition of the Texter<Foo<N>> specialization. When we call Texter<Foo<1>>::Test() in main(), it uses the incorrect specialization, which does not define the a member named Test. This may be inaccurate, but it seems to line up best with the symptoms from what I have figured out. That being said, if you are familiar with this bug, or have a contrasting theory, please share with us below in the comments.

What’s especially surprising about this error is that there is supposed to be an error message you get when it happens! It’s not hard to invoke it, either:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// This compiles just fine:
template <int N> struct X
{
  static void A() { Y<N>::B(); }
  static void C() { }
};
template <int N> struct Y
{
  static void B() { X<N>::C(); }
};
int main(int argc, char** argv)
{
  X<1>::A();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// This, however, throws a C2908!
template <int N> struct X {};
template <int N> struct Y {};
template <>
struct X<1>
{
  static void A() { Y<1>::B(); }
  static void C() { }
};
template <>
struct Y<1>
{
  static void B() { X<1>::C(); }
};
int main(int argc, char** argv)
{
  X<1>::A();
}

I do not mean to fault Microsoft for their failure to throw this error at me. It’s one hell of an edge case, and if you’re in this deep, you really ought not to rely on your compiler to bail you out when you do Bad Things. That being said, it’s nice to be able to trust that your compiler is Always Right, and experiences like this make that trust feel tenuous and uncertain.

In conclusion, do not let your template specializations refer to each other cyclically, or you may find yourself a sad, sad panda.

*Please note that this post refers specifically to behavior I experienced using Visual Studio 2008 9.0.21022.8 RTM on a machine running Windows XP. If you are on a different platform, you may or may not experience the same behavior.


Business Time (Part II)

by Tim
Fri, August 28, 2009 -- 18:16 UTC

This is the second installment of what I suspect will become a weekly series of articles on our adventures in starting our own company. If you haven’t read the last one, you might want to check it out here. Today’s topic is: The Partnership Agreement.

As you most likely know, incorporating is all about creating a collective legal body that represents your business, which can be convenient for a number of reasons. For one, this entity can acquire and own property, and can transfer it to other people. Secondly, it can represent a sort of a firewall against debt and lawsuits; a straw man that will burn in effigy for your mistakes. Lastly, it is immortal, in that it endures even when those that created it have passed on. You may have noticed that some of these qualities are shared by golems, robots, voodoo zombies, and Giant Robo. This is because they, too, are mindless automatons that possess no soul of their own*. They are surrogates that can only be operated by proxy.

You and your corporation!

You and your corporation!

When you incorporate, you are given your very own legal entity that you can use to do business with the world at large. The tricky question is who gets to control it, and under what circumstances. The answer lies in the Partnership Agreement, which is the subject of today’s post. When you found the company, you establish a contractual set of rules that govern the inner-workings of the corporation. These rules must be arrived-upon in advance, to resolve any number of hypothetical future disasters. Some examples of the kinds of questions the partnership agreement should attempt to answer:

  • When making major decisions, how should they be decided? An executive decision-maker? A vote? Consensus?
  • What happens when a new parter joins the company?
  • When the company makes money, who gets it, and how much?
  • Who decides what the company does and doesn’t spend its money on?
  • If someone puts more money in, should they get more money out, or get their money back first?
  • If someone leaves the company, do they get to take their contributions with them?
  • If someone dies or becomes permanently disabled, what happens to their share in the company?
  • What happens if someone stops showing up to work, or gets another job?
  • Involuntary termination: What happens if someone starts stealing from the company, commits a felony, goes insane (like, clinically insane)?
  • If a third party wants to buy someone’s share in the company, is that allowed?
  • If the sale is allowed, does that person become a decision-maker, or just a money-maker?

It took us a while to come to agreement on the answers that best matched our vision of the company. In particular, we opted for decision-by-consensus for all major decisions, such as bringing on a new partner, selling the company, etc… We also decided on an even-split on profits, with equal initial investment. Suffice to say, you will want to find a lawyer with whom you can discuss the best solutions people have found to answering these questions. The implications of these decisions are very serious, and there are some popular answers that do not play nice with consensus-run organizations.

It was interesting, having the three of us and our lawyer in a room, talking about the various common nightmare scenarios that come up when you set out to share decision-making power with other human beings whose vision, needs, and goals can never fully line up with your own. Looking around the room, you must force yourself to imagine how those that you most trust might some day be standing on the other side of a line you drew together in the sand. I imagine that this is similar to what it feels like to draft a pre-nuptial agreement. It was sobering, and it is my hope that I will never come face-to-face with the scenarios we so carefully shielded ourselves against in that document. Still, one cannot help but wonder what a post like this looks like when you return to it years later.

After a few serious meetings, we arrived at answers we were willing to stand by, with our lawyer taking on the task of drafting it into a legal document. It took a while to figure it all out, but there’s clearly a great deal of value in coming to an up-front legal agreement regarding your basic management and ownership assumptions. Going through this process showed us that there are a number of problems that are very hard to resolve if you do not decide on the answers to them in advance. That’s it for this installment, check in next week for Part III!

* = Except for Robo, who posesses a soul and learned long ago how to love.


Business Time (Part I)

by Tim
Wed, August 19, 2009 -- 14:59 UTC

Well, here we are, our webpage is finally live. It’s taken longer than expected getting from “let’s start this party!” to “man, this is a sweet party!”, so I thought it might be interesting to share some of the unexpected hurdles we’ve bumped into along the way. Particularly, those pertaining to Starting A Business. When I inquired with friends who had trod this path before me, they shared their Great Lessons – sage words of wisdom earned at a great cost. Unfortunately, because I did not at the time possess a clear outline of the overall shape of what was to come, these bits of widsom were of little immediate value to me. I hoped that some day they would become useful, like in the movies when a bullet is stopped by a seemingly-worthless trinket the main character keeps on a chain around his neck.

Given our lack of clarity on the issue, and because we happen to work in an office teeming with talented lawyers, the first thing we did when we hit the ground was find a lawyer and start talking about exactly what steps must be taken to start a game development business in Philadelphia. It turns out it is at once easier and more difficult than we had imagined. Let’s start with the easy part: First we needed to decide what kind of corporation we wanted. There were several options on the table, but we quickly whittled it down to either an LLC or S-Corp. The differences between the two are subtle, and we talked for a while about the tax and liability implications. Because it is such a complex optimization space, it’s hard to confidently recommend anything to anyone. That being said, we decided on an LLC for now, with the option for an S-Corp election if and when we establish some cash flow. This seemed right for a situation where all partners are supporting themselves out-of-pocket, startup costs are low, and losses are expected for at least the first year.

The next question was where we should incorporate. Apparently, there is something of a mythos surrounding ‘Delaware Corporations‘, a mark of priviledge and prestige in the business world. Companies sometimes even append it like a title, e.g. “Columbian Chemicals Company (a Delaware Corporation)”. According to our friends in the business world, this made a lot of sense a few decades ago because of Delaware’s tax incentives. However, as time went on, other states figured out why everyone was incorporating in Delaware. Hungry for that tax revenue, they adopted competetive incentives, and the free market corrected itself. So, given that there was no obvious advantage to incorporating out-of-state, and the massive headache of dealing with twice as many state tax bureaus, we decided to go with Pennsylvania after all.

delaware

Delaware. Where the corporations come from.

A quick aside – apparently, Philadelphia is working with a group called the Videogame Growth Initiative to establish incentives for incoming game developers and publishers. Given that Philly recently decided to join California for an old-fashioned budget crisis, it seems unlikely that any such investments are likely to pass in the short-term. Still, it suggests that such incentives are starting to crop up in less-well-known locations, and that video game startups may actually do well to look outside of CA when deciding where to set up shop.

But enough about Philly. Once we finished officially incorporating (there is a form and a fee) and received our tax ID (which is like the SSN of a business), we were able to set up our company bank account. Each of us poured an equal part to cover startup costs (office equipment, software, hardware, etc…), and we all got fancy-looking bank cards. In this process, I learned an amusing fact: when bankers hear that you are starting a business, they get Excited. Coming from a world of personal finance limited to free checking that comes with a free casserole dish, it was jarring to see the curtain pulled back, and realize how much more interested banks are in ‘helping you out’ when you are talking about a business account. And by helping you out, of course, I mean selling you services that make no sense for a tiny three-man company. So, we thanked them for their enthusiasm and promised we would talk more if/when we see a positive number on our balance sheet.

Anyways, That just about wraps up this first installment. I’d love to hear any other indie devs’ experience with this – the comment section awaits you! Next time: The Hard Part.