Category: development

Game project

development, games, programming
Comments

So I’m working on my first serious attempt at a GameMaker project.

The thing with working personal projects is balancing how much you talk about your project with how much you work on your project. You can’t be all talk and no action, obviously, and you probably shouldn’t simply spring a new project on an unsuspecting world, either.

I’m not yet sure how to do this right. I don’t want to spend a bunch of time describing something that doesn’t exist yet, especially if I may change my mind about particulars a bunch of times before I decide to release it. On the other hand, not talking about it just drives me crazy. I’m into my project, and it’s interesting and exciting to me, and I just have to talk about it.

The other thing that’s hard about talking about working on personal projects is talking about it with a proper level of authority and confidence. I’m doing things that are new to me, for the first time in many cases. But most of what I’m doing is technically not all that difficult or sophisticated. As much as I want to be excited about figuring out something, I don’t want to make myself look dumb by blogging things that are the equivalent of what “Hey, guess what I just figured out? When you have a plus sign between two quantities, that means they’re added together!” would be to a math blog.

What I do like about this project so far:

  1. The fact that I’m doing something that I’ve wanted to do my whole life.
  2. The fact that I can do it.
  3. The fact that I am doing it.
  4. That the progress thus far has been fairly steady.
  5. My process: planning, building experimentally, testing, documenting. I feel like I’m going about this in just the right way.

In fact, I really like my process. Here’s what I do:

  1. Sit down and think about what I want to do. Brainstorming. Create a list, prioritize it. This becomes my backlog.
  2. Work an item on the list until it’s done to where I’m satisfied with it for now. This involves building and running it to test it, over and over. I try to conceive of my solution first, then build it, starting small and simple, and building off of what I just did. I’m more tentative with things I haven’t mastered yet, but that’s the natural way of things.
  3. Write up what I did in my version history. Update the backlog, to either remove the item from the list, or more likely, update it to reflect the next level of refinement that I want to get to with that item.

So far, so good. I have a ways to go yet before I have something that’s worthy of an alpha release. I might have it out in a few weeks, we’ll see. What I have right now is playable, but not interesting as I’ve yet to implement any enemy behavior. I expect that the enemy behavior will be very interesting to work on, and probably one of the trickier aspects of the game and thus may take me longer than what I’ve done so far.

Success!

design, development, games, programming
Comments

It’s time for a catch-up for my neglected blog…

What I’ve been up to lately: The Computer Game and Simulation Design class wrapped up this week, and I both did extremely well in it and enjoyed the class very much. I ended up carrying a 101.5% average in the course.

I pwnd CGSD120!

My grade for CGSD 120

Since I now have some spare time with the class out of the way, I’ve started my first independent project. I’m not really ready to talk about it in depth just yet, but in the next few weeks or so I hope to get it to a playable alpha state, and then it will be made available over on the releases page.

On the death of Google Wave

development, reviews
Comments

I read today that Google pulled the plug on Wave. This shouldn’t matter, since Wave was always supposed to be open source from the beginning. I don’t know if Google actually kept that promise or not, but if they did, then Wave should live on.

Even if it doesn’t, I believe that the future will look more and more Wave-like.

Perhaps Wave needed to happen to give us a clear picture of what the future ought to look like. I have little doubt that the concepts of cross-app integration and direct collaboration are definitely going to stick around.

Wave was ahead of its time. I remember when it was first announced, my first reaction was “WTF is Wave?” After I watched the video and understood the concept, I thought, “Wow, what a great idea.”

That’s about as far as I, and many other people, it seems, got with it.

The problem I had with it was I never had a reason to work in Wave for any document I was authoring solo, which, it turns out, is better than 90% of the documents that I author. The few times I had occasion to suggest to a group that we look into trying out Wave, we never got off the ground with it. Either there was a question of did everyone have an invite, or if that wasn’t the problem, then no one really knew how to get things started in Wave in order to kick off a project.

There seems to be something about working collaboratively on mentally-intensive (particularly creative) endeavors that makes it a struggle for most people, especially people who don’t already know each other well and have fallen into roles that are familiar to them, where everyone knows what they’re doing and what’s expected of them. Wave might have been a great tool for us, but in order to have had a chance it needed a Wave Evangelist, someone familiar with the tool and who had leadership qualities and would be effective at delegating tasks to team members. I’ve always found that working in a group is not much fun without strong leadership. By which, I mean, someone who knows what the group needs, and has a clear vision for how to accomplish that goal, and who can communicate effectively with everyone else.

Human teaming factors aside, I think that Wave didn’t stand much of a chance because it didn’t offer people a “gateway drug” kind of experience. If you’ll pardon the metaphor, Wave needed some way to get users’ toes wet, and encourage them to wade into it until they developed the skills necessary to swim. It never managed to do this.

Despite this, I think that Google was on to something when they announced Wave. Like many great ideas, it came ahead of its time. In 10 years or so, we’ll look back and see that it paved the way for a new cloud-centered, collaborative way of working with documents, with information, with other people. Eventually, Wave will happen. But it will not happen as a big announcement with an hour long introductory video to explain it. Instead, it will seep in gradually and immerse us all until we suddenly realize that the tide has come in. (Again with apologies for the extended aquatic metaphor.)

What I mean by that is this: Wave was all about integration of existing technologies that we’re already familiar with: word processing, calendaring, instant messaging, email, web browsing. Google’s mistake with Wave was thinking that they needed to convince everyone that the old tools should be cast aside in favor of the new Web 2.0+ hotness that Wave represented.

When a oceanic wave crosses a point on the surface, there are two ways that it can first reach that point: trough first, or crest first. Google’s approach, essentially, was a crest-first approach: Wow everyone with this new concept and generate a lot of buzz so that people would be excited and want to use this new, cool technology. Apparently this was needed in order to get everyone to ditch their old, pre-Web 2.0 ways of doing things and give Wave a try.

It failed. People are comfortable with their old tools, and didn’t know how to transition to Wave. And until their friends were all on Wave, they would likely never have a reason to.

But consider if Google had taken a “trough-first” approach. Rather than inundating the world with an hour-long video explaining just what Wave is and how you can’t live without it, they start simply by adding Wave-like features into the existing suite of Google applications. The convergence of gTalk and gMail is an excellent example of this. Gradually, Google extends all of their existing web-served apps until users realize they’re waist deep in Wave. Maybe it’ so immersive by then that it hardly even needs its own name. No one would have been asked to throw away their old tools. No one would have had to have been the first to dive into learning some new, strange tool, and try to get their friends or colleagues interested in trying it out. It would have just grown up around us, rolling in like a rising tide. That approach would have worked.

And indeed, I believe that it will happen, eventually. And it will happen just as I’ve outlined in the above paragraph. A combination of cloud storage going mainstream, plus open standards for data formats, plus extensible feature sets in applications is all that is needed. Given these three things, add time, and it will happen.

Deepwater Horizon: “Failure Modes” vs. “Fail-safe”

development
Comments

The Deepwater Horizon oil spill has been in the news a lot lately. Congressman Bart Stupak (D-MI) has famously asked the question about the blow-out preventer, “How can a device that has 260 failure modes be considered failsafe?”

I’ve heard the soundbite enough times that I feel like I need to blog about it.

I believe Stupak misunderstands the terms he’s using, and is thus confused. Or quite possibly, the sound bite lacks enough context. Either way…

“Fail Safe” does not mean “has zero failure modes” or “cannot fail.” “Fail safe” means, simply, that when a failure occurs, the design ensures that the failure happens in a safe manner.

Obviously, in the case of the blow out preventer on Deepwater Horizon, not all of its failure modes result in a safe failure. However, the number of failure modes has nothing to do with whether it is safe or not. Obviously, the fewer failure modes a thing has, the better, because it means that there are fewer things that can go wrong with it. But just because something has a high failure mode count does not necessarily make it a bad thing. Indeed, quite likely it means that it has been analyzed and tested extensively, and is well-understood. Identifying as many failure modes as there are to discover is a good thing. You don’t want there to be a failure mode that you don’t know about, or didn’t anticipate.

I don’t know anything at all about drilling for oil, but to anyone with an engineering background who understands what the terms “failure mode” and “fail safe” mean, Stupak’s question sounds idiotic.

This sort of situation is something that people who work in technical fields encounter all the time. So naturally, the soundbite irritates me every time I hear it.

Customers and upper management usually seem to think that it’s the engineer’s job to design a solution that handles any conceivable problem, and does so gracefully. Moreover, they want solutions that are delivered on time and under budget. They want to never have to think about the tools they use, especially if that means having to understand how the tool works. They want their solutions to “just work”. Well, don’t we all.

This desire for solutions that just work and don’t have problems is indeed rational. Unfortunately, it is unrealistic. We can only do our best to make solutions which handle as many foreseeable problems as we can envision, as gracefully as we are able. This does not mean that there will never be problems. This does not mean that it won’t be more useful to have operators who have some level of understanding of what’s going on inside the tools they rely on than an operator who has no clue.

I try to deliver products which are as forgiving to the clueless as possible, but it will always be the case that a clueless operator will be at a disadvantage. The idea should not be that the purpose of human enterprise is to create a world that enables people to be clueless, and takes care of the clueless as though they are helpless. The idea should be that the tools we use should remove burdens for the user so that they can be empowered to do more. A great tool removes those burdens for the user, but also allows the user to understand the work being done by the tool if they need to.

It is my fervent belief that the world is improved by people who seek to understand it. Absent understanding, one can only be at the mercy of what they fail to understand. The modern world is a very complicated place indeed, and so the less one needs to actively deal with in order to get by, the better. But that is not to say that ignorance is desirable, a virtue, or bliss.

I’m not saying that Deepwater Horizon couldn’t have been prevented. Very likely it could have. Not all of the possible preventative measures were implemented.

But misunderstandings such as conflating failure mode count with fail safe certainly do not help to bring about a culture of safety. If an executive or legislative level person, who shapes policies that govern these systems that we must design to be safe cannot understand the terms they use, and the implications of what they are being told by technical people, then only badness can result from it.

Too often engineers who are doing nothing more than speaking plainly are not understood when they speak up about potential problems, only to be scapegoated when a worst-case scenario comes to pass. But ultimately, responsibility should be owned by the people in control who set policy on what is considered an acceptable level of risk. If these people cannot understand the language that is used to communicate about risk, then they do not deserve to hold the power to make the decision to accept risks.