What went right

Strong tools and tool support

We had a pretty convoluted way of getting map data from our editor (Tiled) to the game engine, but if it wasn’t for Karl’s strong Python and tool-development skills, we might have been left out in the cold. Karl wrote up a script that would let us convert Tiled maps into the particular flavour of XML that the XNA content pipeline prefers, since we weren’t using XTiled (due to the fact that at least at the time, it didn’t support the staggered isometric maps we were using). Tiled’s ability to set custom properties on practically everything was very useful for working with the game entity system we developed, too, and whenever I needed something from the map in the engine, Karl was able to update his script very quickly. We had great turnaround time on map editing to in-engine play.

Great environment for ideas or mental refreshment

With over 450 game developers present, getting ideas for when we were faced with problems, or just getting away to chat with other developers was wonderful. One of the worst things about working in a distributed environment is the lack of social activity that can help deal with issues such as when you’ve hit a brick wall in your development (or just have coder’s block and can’t think straight).

What went wrong

Starting from clumsy code

Unlike a lot of other programmers, I’m not afraid of building off of others people’s code. In fact, I prefer it when there are existing frameworks, libraries, etc. that I can use in order to focus on developing my actual project. Unfortunately, that caused quite a bit of problems for Karl and I this time around. What’s worse is knowing after the fact that adding what I needed to XTiled would have had us further ahead than the “complete” isometric engine we started from.

On top of that, the distraction of getting the isometric tile engine working the way we wanted meant I didn’t think about using some nice and pre-built XNA systems but instead wrote my own off the top of my head (one of which I’ve already pulled out and replaced with something better).

Planning for more than we could chew

Three days isn’t a lot of time, especially if you intend on taking time to sleep and eat. The original concept for what became Happy Island was developed over a couple of weeks before TOJam, which gave me the luxury of time to think up and toss in whatever I thought would be good. At the event, however, we had to pare down things and make the game really simple — and even if we hadn’t had the other problems, it still would have been necessary to cut things down to size.

Lack of “floaters”

TOJam offers developers without them the ability to borrow artists and musicians as “floaters” — in other words, people who come pretty much to provide content to other developers. While there were a good number of floaters signed up, unfortunately not many of them actually came out to the event, and so we had to make do with what graphics we could scrounge up online, and a 31-second audio clip for background music.

Conclusion and download

In the end, we just made it. Karl and I finished our v1.0 of Happy Island right as time was up, and while it wasn’t what we were expecting or hoping for, it was complete enough to play. Getting to see people enjoy it afterwards was great, too!

Since TOJam, Karl and I have done some additional work on the game. I’ve also taken the opportunity to work on a few things that’ll be useful for further Happy Island development, or other XNA/MonoGame projects. For starters, I’ve updated a Paint.NET image content importer to work with XNA 4.0, which can be found on Github. As well, I’ve made my own fork of the XTiled engine and map importer which adds support for Tiled 0.9 features (image layers and staggered isometric maps), so that future projects can make use of that instead of the frustrating code we used for this project.

You can download Happy Island from the Cold Acid Entertainment site; as of this blog post, a polished v1.1 is available.

Related articles

• Developers dream of making it big at TOJam
• A Game Where The Princess Doesn’t WANT To Be Rescued
• Browser Pick: truth is grey in TOJam entry Notes, from Starseed Pilgrim dev Droqen
• Haters Gonna Eight

This weekend just past was the annual spring conference for District 60 Toastmasters. I was on the conference committee with the responsibility of organizing the workshops part of the conference programme, and on top of that ran a workshop myself on the subject of creative Table Topics. As someone who had responsibility for how the conference turned out, I feel that I should write up a post-mortem of my part of the work, in order to better evaluate how well I did and where I have room for improvement.

What worked well

Processing received proposals. Despite a few difficulties, extracting the data from proposal submissions and putting it into the tracking documents was fairly simple. While the system for tracking and managing workshops fell apart later on, at least at the beginning it was easy to get stuff in.

I was also able to leverage SkyDrive so that other committee members could review the proposals as well, and make suggestions as to which ones to approve or otherwise discuss.

Equipment and room setup management. This was fairly simple. From the get-go, we made sure to note that while the conference could supply certain equipment, presenters would have to bring their own projectors if they needed them. Still, we made sure to have a couple backups just in case. Things worked out well for this.

Mail merge. Never underestimate the value of form communication. With the proposal tracking documents, it wasn’t too difficult to handle one-way communication. Both the Excel spreadsheet and Access database loaned themselves well to producing emails I could batch send to presenters.

Workshop packages. Other than an envelope-related hiccup, I was able to manage the process of putting together workshop packages fairly easily. Each package simply contained timing cards and a gift for the presenter. On each envelope I affixed a sheet of paper with relevant information, so that workshop sergeants-at-arms would pick up the correct packages.

What needs improvement

Communication, communication, communication! That old nemesis of mine, email communication, caused quite a bit of trouble during the planning stages, as well as making things very uncomfortable for me in the week leading up to the conference. Not only were a number of workshop proposals lost in the mail (at least two that I was informed of after it was too late to add them in), but the response time for replies – both for emails sent to and from me – made miscommunications more frequent and troubling than I would prefer.

For the next time I am in charge of an event’s programme (or part of it) I need to ensure that I communicate regularly and more frequently with presenters, fellow committee members, and other stakeholders, and to do so by phone more often than by email.

Submission Process. Between the MIA proposals and hand-written, scanned in ones, the submission process was plagued with problems. Hopefully for future conferences we can move away from the current proposal form as the primary method and onto a web-based submission system instead. At the very least, it would be good to use PDF forms technology, which would allow for easier processing of proposal submission data.

I’ll just note there’s nothing wrong with the form itself, but relying on email submissions of it is simply asking for trouble.

Workflow. At the start of planning for the conference, I adopted the workflow used by past workshop chairs. Unfortunately, the workflow was too ridden with cracks that things could slip through, due to the fact that it was nothing more than a simple Excel spreadsheet. I kept modifying the spreadsheet as I needed to track more and more, but each change was nothing more than a kludge, which in the end only increased my manual workload.

Eventually, I replaced the spreadsheet with an Access database which allowed me to track workshops, presenters, and other team members easily, as well as create reports that allowed me and others to see the status of workshop programming at any time. Hopefully the person handling workshops for the fall conference will have Access and be able to use this workflow.

Sidebar: Creative Table Topics (my workshop)

On Saturday morning, I was able to conduct an hour-long workshop on Table Topics. More specifically, a workshop on how to run a fun Table Topics session by reviewing sources of ideas for crafting unique and creative topics for each meeting. Because of all the work I was putting into organizing things with Ad Astra and the workshop programme for the conference, I wasn’t able to organize my workshop as well as I would have liked. However, my observation was that the workshop attendees thoroughly enjoyed themselves and the activities I presented.

This workshop needed no notes for me, no hand-outs, no visuals. Rather, I guided the attendees through various activities to help them identify and build on ideas for producing Table Topics “decks”, as well as ran them through various different ways to actually run the game. While it wasn’t that well attended (actually, for a 9:15am workshop I probably got a decent number of people in the room) nobody left part-way through, and everyone left satisfied and ready for their next time as Table Topics Master.

Summary

Despite the crossed communiqués, the stress of the final week before the conference, and the feeling that I didn’t give enough attention to the conference in the last couple weeks (due to all my preparation work for Ad Astra just the weekend before), I think things went very well for the district conference. We had a lot of happy Toastmasters attending, and with workshop presenters coming from as far away as Quebec or North Carolina, a lot more could have gone wrong than actually did.

I am proud to have helped out District 60 with the 2013 spring conference, and I look forward to helping out with organizing the fall conference as well.

Ah, I promised on Twitter I’d have this up last week, didn’t I? Well, finalizing things for the District 60 spring conference got in the way, sorry. Anyway, here we go with my postmortem on the games department for this year’s Ad Astra convention.

What went well

The video games room! Video games have returned to Ad Astra’s programme this year! The last two years saw a lack of video gaming due to various issues, and years before then only saw a short two-hour gaming session in the anime room. However, we were finally able to get a proper video games room up and running, with a number of consoles, both new and old, available to attendees.

Available to play were: Xbox 360 and Nintendo 64 on the big screen, Sega Master System and Super Nintendo on the first little screen, and Sega Genesis and Turbografx-16 on the second little screen.

Snakes & Lattes. Like last year, Snakes & Lattes hosted the table top games lounge. Their sponsorship and staffing of the room for open gaming hours is incredibly helpful, and gives me the chance to focus on the big picture of games and game-related programming at the convention. A great big thanks to Steve and his S&L crew!

Expanding beyond the game rooms. While minimal this year (see what needs improvement below) we’re starting to see games-related programming expand beyond just the games lounge and VG room. We had two games panels this year, although they weren’t that well attended. Still, it’s a start, and I’m looking forward to establishing more panels on games and gamer culture for future years – not to mention at least one panel related to video game narrative and writing. We could even bring in a gaming guest of honour for next year.

What needs improvement

A late start. Originally I had planned to have things moving back in July. Then it got pushed to September. And even then, I didn’t have a real, written plan that I could share with department staff, the other members of the convention committee, or the board of directors. A written plan for the department would have been able to provide us with guidance for some of the problems we faced leading up to the convention, as well as offer a rationale for expanded programming and departmental budget.

Fortunately, I already have something worked out for 2014, based on the results of this year’s convention. You’re not going to see it (unless you’re on the convention team), but you’ll certainly see the effects of it next April!

Communication. Getting a late start on things was bad enough, but not keeping in frequent, regular contact with the rest of my team also hurt matters, and made it more difficult to make up for a number of scheduling and personnel problems we faced this year. We had a few people who were unable to come out for the whole weekend, one of whom I didn’t even hear from for months until the Saturday of the convention. (He had a damn good reason, though.)

For next year’s convention, I plan to have weekly communication with my team, via email, phone, and/or Skype. This way we should be able to avoid some communication problems, and know about potential roadblocks well enough in advance to be able to work around them.

Batteries (or lack thereof). Oops. Rack this one up to me simply forgetting to stick my huge bunch of batteries into my luggage. The reason this was a problem was because without those batteries, we weren’t able to make use of the Wii in the video games room. We also needed some batteries for the TV remotes, and so had to swap batteries back and forth in order to set up two of the sets we were using. D’oh!

Fun and interesting experiences

This year was the first time I actually sat on some of the panels at Ad Astra, and it was great. I had a panel a day, starting with Friday’s “The Contemporary Troll”, Saturday’s “Hardcore Gamers’ Forum” (which unfortunately nobody came to, I think they were all in the video gaming room), and Sunday’s Game of Thrones panel, “Beyond Winterfell”. I was hoping that we could have a panel on visual novels and interactive fiction as well, but unfortunately nobody else was interested.

I also had an interesting conversation Saturday night in the GOH/panellist green room, that lead to an interesting concept and story idea relating to death and the afterlife. If I ever get around to non-game fiction writing again, I think I could come up with a decent short story off of that conversation!

Summary

Ad Astra 2013 was made of ups and downs for the games department – but mostly ups. Building on this year’s energy, I’m sure that Ad Astra 2014 will be even more awesome!

Related articles

• Ad Astra 2013
• Ad Astra 2013
• Philosophical story idea
• Interview with Jim Butcher

I was at the first two events, back in 2006 and 2007. That first amazing year saw me complete a game called Alien Abduction! (now renamed UFO Panic), a game where you flew around another planet abducting aliens. Unfortunately, the second year saw my computer blow up on me, which resulted in much sad, and so I didn’t get anything completed. However, this year I don’t have to transport an entire desktop system from Pickering to downtown Toronto; all I need is my trusty laptop, and if I’m crazy enough I might also bring along my CRT monitor so I can rely on my usual two-monitor setup.

Almost every TOJam has had a theme, and this year is no different. The theme is “uncooperative”, and I already have a game idea for it. With any luck, I’ll be able to put together a simple tactical socialization game on a deserted island within the three days of the jam, with the help of my friend and fellow Cold Acid Entertainment developer Karl.

I’m really looking forward to it, and so are many others in the city! For the four hundred seats available, over three hundred registrations have already been sent in since the registration form opened up this morning. Goes to show you just how popular this game jam can be. I certainly hope that Karl and I will be among the lucky folks selected to attend!

I have a lot of fun here, even though I’ve had my fair share of troubles managing my department. This year has been no different in that regard, but the problems I’ve faced this time around have been in the planning and preparation stages, rather than execution (so far). It boils down to two issues that should be of concern for any group project: personnel and communication.

I’ll not name names or anything, partially because I am one of the people at fault for this (not just in a “buck stops here” way either). But yeah, it is incredibly important to know who you’ll be working with and what they will be responsible for from the get-go. Even more importantly, it is necessary that team members keep multiple lines of communication open at all times, and that they communicate early and often.

For future years and future projects, I hope that I will be able to maintain this knowledge.

The two docs I’m posting today are for games that were tentatively titled “Valkyrie Dragon” and “Great Kingdoms”. The first was originally written around 2003, and was to be a cross between the mecha combat (a la Starsiege or Evangelion) and dating simulation genres. In short, it was Baldr Force with genetics instead of virtual reality. As for the second, it was written and tweaked over a period of time spanning 2002 through 2004, and was to be a real-time strategy where players would build their own fiefdoms (including vassal relationships to other players). This was the far more interesting (and further developed) treatment, although I determined I had neither the resources nor the inclination to follow through on developing it.

As other projects of mine either get retired or tossed on the heap of unfulfilled ideas, I might release their design documents too. In the meantime feel free to review these ancient treatments – perhaps they’ll inspire you to come up with something interesting.

I’ve been stuck on the same problem for a while now, working on MoodTracker. The problem comes down to SQL Server Compact and LINQ to SQL, and the lack of the former on Windows 8. You see, I’d like to get MoodTracker on Windows 8. However, to do so means reworking how the app does data access since SQL CE isn’t available for use in Windows 8 applications, and unfortunately, there’s absolutely no useful guidance on moving from using SQLCE-decorated model classes to a more portable solution for data access.

So here I am, working on separating my model classes from the concern of data access. And it’s not going too well. Sure, I have a portable library containing new model classes free of the attributes and various association-related classes, and I’ve moved the SQLCE-specific stuff into its own assembly. But that’s as far as things have gone. Trying to connect the dots between the model classes and the data access classes has gotten me nowhere. On a related issue, working out how to inject the DAL into the app had been troubling me, but the realization that it would be done in another platform-specific assembly has given me the clue to work that out (so long as I can work out an interface for data access that works).

I really wish there was some guidance on this, so that phone apps making use of a local database could be more easily ported to Windows 8, with a lot less fuss. If anyone has a good solution for this problem (bonus points if it’s MvvmLight friendly) please let me know!

The perfect is the enemy of the good. – Voltaire

Motivation to perform to perfection is a strong force in western society. The attitude that we have to be better than anyone else at something, to achieve perfection in our activities, has been a strong force throughout modern history, from the world’s nations down to the individuals which form their bases. And it’s seen every day in projects of all scopes and sizes.

But Voltaire left a message that should be listened to, by everyone on every project – one that is unfortunately ignored by many, to their detriment.

It’s a somewhat heretical thought: What if we don’t have to be perfect? What if we just do good enough to pass? What will that offer us instead of striving to be the best? Well, what it offers is the ability to work more efficiently and still do a proper job of it.

What is good enough?

It’s actually pretty simple. Being good enough is about meeting the needs of the project, rather than the ideals. Some might think it means lacking quality, but it’s really more about balancing quality against the work that actually needs to be accomplished.

For an example of something good enough, one need only recall the 1980s and early 90s, to VHS. In the late 70s and early 80s, it competed against the Betamax standard for home video. However, it won the competition in the end because it was good enough for the average consumer. It was cheap, had acceptable video and audio quality, and was readily available. In contrast, Sony’s Betamax standard, while better quality than VHS, was more expensive and harder to get a hold of. The focus of having a perfect format paradoxically resulted in a product that couldn’t cut it against VHS.

What’s wrong with perfection?

First of all, perfectionism is procrastination. Say it out loud: perfectionism is procrastination. When you try to be perfect, you get little, if anything, actually accomplished. Planning for perfection leads to a project terminal state known as analysis paralysis – you get so bogged down in the details of what could happen, what could be needed, etc. that you never actually get started at all. And for a project that is in development, perfectionism can lead to endless wanking on a few particular pet tasks of the developers, as they keep trying to make those parts they’re working on better and better. At first it may look like progress, but at some point, those constant attempts at improvement return no value at all.

On the other hand, aiming for Good Enough just gets the job done. In planning, you focus on what the requirements are, no more, no less, and how to meet them simply and efficiently. No worrying about edge cases or making things bulletproof or endlessly customizable – meet the core needs and be done with it. As for development, it should be simple enough to test against the plan to see if a task is met. Once it is, you move on to the next one, and stop worrying about the one you just finished. The work goes by faster, and you accomplish more.

Another issue with perfection is that not everyone agrees on what perfect means, in the context of the project. It’s very easy to end up with a camel, when what you want is a horse, because everyone thinks that the perfect quadruped needs this or that or the other thing. It’s a very subjective concept, as opposed to achieving good enough. Not to say that good enough isn’t subjective itself, but it’s a much easier target to hit and reach consensus on, and if you plan well, it can be objectively determined whether or not something is Good Enough based on project goals, client needs, and metrics collected during the planning and development stages of a project.

Determining what is good enough

There are three simple questions you can ask:

Is it simple? That is to say, is the design simple and can be picked up by the developers without much work? If the design and implementation is simple, it’s easier to make any needed changes later, while still fulfilling the current requirements now.

Does it work acceptably well? If it’s easy for the end user to figure out, and does the job without raising problems the user can’t handle, it’s good.

Does it cover all the bases? It should meet the project requirements, with a minimum of additional features tacked on. Wherever additional things are added, it should either be because of (legitimately) changing requirements, or because those features are required by the features which do meet project requirements.

Conclusion

There are some clear advantages to aiming for good enough rather than for perfection. You’ll be more efficient while still providing a proper job well done. It’s not necessary to provide all the bells and whistles so long as you meet the goals of your project, so don’t try for it! Success comes from getting the job done right, not done perfect. And good enough is doing it right.

The greatest enemy of a good plan is the dream of a perfect plan. – Karl von Clausewitz

Related articles

• Getting Stuff Done means Letting Go of Perfectionism
• Perfectionism – Are You Protecting Yourself from Success?
• Perfectionism Trap: Free Yourself with 2 Timely Tips!

What it all boils down to: The Task-based Asynchronous Pattern, known to most of us mortals as async/await. And, to a slightly lesser degree, parallelization.

You see, in Taptics, when scores are submitted in game, I have to submit the score multiple times due to how leaderboards work on the Scoreloop platform (which is what I’m using for that, as well as the upcoming achievements feature planned for the next big release). As well, players can connect Twitter and Facebook to the game and send out a message of their score. Rather than chain together these operations in serial (one at a time, wait for one to complete before starting the next), I start them all right away, and just wait for them all to finish with the help of Task.WaitAll.

So, what happens if an exception is thrown within one of your tasks that you’re waiting on? In the case of await with a single task, it’s more or less the same as an exception being thrown in classic synchronous code. The stack trace is a bit different, though, as the exception has been thrown twice – first in the method or lambda that the task is running asynchronously, and then again in the state machine hidden behind your await call. This was problem number one: the stack traces I was getting from these asynchronous method exceptions let me know where the exception was thrown the second time, but no (or almost no) information from the original throw. That lead to tedious work looking for possible bugs, often with the help of both JustDecompile and ILSpy to peek into the state machine’s inner workings.

What happens when you’re awaiting a group of tasks, though? Here we run into the issue I had with RadDiagnostics. You see, Task.WaitAll doesn’t throw you back any old exception. What would happen if multiple tasks threw? Because of that situation, Microsoft introduced the AggregateException class, which acts as a collection of exceptions. You can enumerate the InnerExceptions property of AggregateException to get the actual exceptions thrown by the tasks. Unfortunately, RadDiagnostics isn’t bright enough on its own to do that, so the reports in that and similar situations where tasks were run side-by-side were practically useless.

Fortunately, that was easier to fix than the earlier case, even though it meant pushing a Taptics update that did nothing but improve bug reporting. RadDiagnostics provides an event that is fired before actually submitting reports, in case a developer wants to transmit them via a method other than email. It can also be used to tack on custom data for error reports, and so I was able to add in some code to handle AggregateException. Now, whenever such an exception percolates up and gets caught by RadDiagnostics, I at least know what’s causing it and where.

By the way, I should note that even if only one exception is thrown by one of the awaited tasks, it’s still wrapped in an AggregateException. I only ever had AggregateExceptions with a single inner exception, but even in that case, you have to go through InnerExceptions (regular InnerException appears to remain null).

In the end, I’ve strengthened my ability to deal with pesky exceptions crawling out of the async woodwork, and hopefully the next update of Telerik’s controls will offer a more AggregateException-friendly RadDiagnostics.

UPDATE March 22: Telerik has listened! Future versions of RadDiagnostics will keep an eye out for AggregateException and give expanded reports when they’re encountered.

External projects:

• District 60 Toastmasters spring 2013 conference. I am the workshops chair, and at the moment I am doing a lot of work regarding scheduling of the workshops and making sure workshop presenters have what they need in time. I am also presenting a workshop, which I need to finish preparing.
• Ad Astra 2013 convention. As the game department supervisor, I’ve been dealing with what will be available to play and who will run individual sessions. Things started a bit late for this year’s conference so I’m playing a lot of catch-up.
• Anime North 2013 panels. I’ll be on some game-related discussion panels, but there’s been a lot of issues getting things laid out with the panels I am on this year.

Internal projects:

• Taptics. There’ve been a lot of bugs reported lately, but unfortunately the bug reports and crash traces aren’t providing me with enough information to fix them. I’m also implementing achievements, but I need help with designing the achievement icons.
• MoodTracker. Currently stuck trying to make MoodTracker somewhat more portable so I don’t have to maintain different branches for Windows Phone 7, Windows Phone 8, and Windows 8. My fault, and would have been entirely avoidable had I taken more time to plan before starting the code for it.
• Business planning for Charabaruk Information Solutions. This is the name I plan to consult under. The business side of projects has never been my strong suit, instead I tend to focus on technical aspects. I’ve been putting a lot of thought onto how to build up business skills lately.

Education:

• Foundations of Business Strategy and Calculus 101 on Coursera. Currently playing catch-up with my courses.

Reading:

• Gamers at Work by Morgan Ramsay. I preordered the book, received it within a week of launch, and still haven’t finished it. Still a few chapters to go.
• Currently awaiting the 1.1 edition of Mindfire by Scott Berkun. It’s already had a soft launch on Amazon, but the ebook editions are going to be given away for free on Wednesday from the author’s website.
• Various light novels and manga when I go to bed each night. It’s been a little while since I read any western fiction.

That’s what’s on top of my head right now, but no doubt there’s more. Hopefully I can clear out a bunch of tasks related to these over the week. Which reminds me, I should probably get back to doing weekly reviews.