Critical Designer #1: Using Scale to Promote Strategy in Pikmin

Hello again and welcome (finally) to the first entry of Critical Designer! In case you didn’t read the title, I’ll be writing this first entry on one of my favorite Nintendo series: Pikmin!

At its core, Pikmin is an RTS game about an astronaut, Olimar, who crashes on an unknown planet (presumably Earth) and must collect different resources and parts to repair his damaged rocket ship. Seems like a good old Nintendo narrative, but as soon as Olimar exits his ship, it’s plain to see that everything is a little bit different than we might have expected.

Screenshot (55)

That is literally a cardboard box, I swear. It makes Olimar and the pikmin look like ants.

That’s right, everything’s huge, dammit. Every part of the environment, and this includes the enemies, dwarfs Olimar and his um…..pride of pikmin? What do you call a group of pikmin, anyways? A gang? A gaggle? A murder? I’m not really sure but the point is that Olimar and every one of his pikmin are tiny compared to the environment and the enemies themselves.



While this definitely makes a lot of the enemies seem more epic and more dangerous to the player, it also means a couple of other things:

  • Olimar cannot fight enemies alone. There are very few enemies in the game that are of similar size to the miniscule astronaut and even fewer (next to none) that he can damage on his own. This means that the pikmin are a necessity when it comes to combat.
  • Players must strategize when taking on different enemies due to their size. Pikmin themselves are able to damage all of the enemies in the game but they are still easily killed. They must be controlled effectively and efficiently to avoid extinction events.

That second point is extremely imperative when it comes to progressing in the game. Due to the large size of all the enemies, the player must use their pikmin strategically to take said enemies down. This includes managing the size of attacks, which colors to use and so on. Sure, players could just throw a murder of pikmin at enemies all at once since more of them means more damage but this is not always a good idea. The issue with this “strategy” comes to light in Pikmin’s boss battles, specifically against one of the optional bosses, the Smoky Progg.

Screenshot (56)

The Smoky Progg kills pikmin and my hopes and dreams, too.

The Smoky Progg is easily one of the hardest enemies in the Pikmin series to kill. It constantly emits toxic gas from its tail that not only damages Olimar but instantly kills any pikmin that come into contact with it. It can also uproot pikmin sprouts as it marches through the landing site. The player cannot simply throw a million pikmin at it and hope to win. They must use strategy by attacking and retreating enough times to take the big jerk down. This enemy along with basically all of the others in the game promote the use of strategy over brute force, which also helps the player to get used to using the different types of pikmin instead of just favoring one.

Now, I know it was awhile ago that this series was supposed to have started but from now on, you can all look forward to one of these a week. I hope you’ve enjoyed this first entry from me despite the simple concept and points. Thanks for reading and stay tuned!

Adventures in Voxel #1: The Shrine in the Sky

I know it’s been a long time coming since I announced both this “series” and The Critical Designer, but I’m finally getting around to them, I promise. For this, my first project was a Japanese-style shrine on a floating island! Honestly, the idea just started out as a regular Japanese shrine but after I finished the actual shrine, I figured it would look cool if it was floating.

Now, I obviously took inspiration from real Japanese-style shrines, as they’re buildings that I’ve always thought looked exceedingly cool. For the floating island part, there were actually a couple of inspirations that went into it. First off, I’m a lover of RPGs with magic or floating cities and the like. Not only that, but the Shinto shrines in Japan always seem to have a mystical aura about them that makes me feel as though I wouldn’t be surprised if I actually came across a floating one.

Before I go on, take a look at some of the pictures I used as inspiration below:

This slideshow requires JavaScript.

The entire process itself took about 4 hours. Now for people that use MagicaVoxel all the time, maybe this seems like an eternity for what the finished product actually is. However, this was my first ever time using the program, so I was learning as I went and though it was a little frustrating at points, I still found it to be a lot of fun and a great learning experience. As a designer, I can easily see the potential of this program as an asset creation tool for games using the voxel art style, something that I’ve had an interest in for a bit of time as well.

Without further ado, here’s the finished product below:

To end this first entry, I’ll say that I’m quite proud of the work I did. There’s definitely a learning curve for this program, but I’m excited to keep making things and improving as I go. I’m sure my blog posts about each project will improve over time as well….hopefully. Even if they don’t, you should read them anyways to avoid horribly hurting my feelings.

As a final note, expect to finally see my first entry in The Critical Designer series very soon, like today or tomorrow. Once this and that are up, I’m gonna try my best to do one of each a week, I swear! Thanks for reading!

The Return and New Projects!

Hello once again! It’s been quite awhile, I know, and I’m sure any remaining readers have been a bit curious as to where exactly I’ve been. Well, I graduated from Champlain College with my Bachelor’s Degree in Video Game Design & Development back in May and I’ve had several things happen since then.

For awhile, I took a bit of a hiatus from working and applying to jobs to just sort of decompress from the stress and pressures that came from working my ass off at school. I had a few family issues occur in that time, such as the death of my oldest brother, which affected me greatly and made it that much harder to try and get back into the swing of things. This also affected the development of Sword of the Sorcerer, which has still (at this point) still not been published to Steam. While this is unfortunate given the amount of work that went into the game, it doesn’t mean that the game will never be published. Even if the project lies dormant for years, I’m confident that sometime in the future, it will eventually be released and playable.

If you can’t already tell from the title of this post or this post’s presence in general, I’m back and ready to get back to work! I’m back on the grind of applying for jobs and working on personal projects to help improve my portfolio and skills as a Game Designer. Speaking of which, I’ll be posting about new projects as often as I can here on my blog, just like old times back at school, and I’ll be trying to keep you all up to speed with life updates as well and progress on my job hunt. I’ll also be starting a couple of new “series” of blogs/projects.

The first of these will be called Adventures in Voxel, in which I will be creating a project (or more) a week using the MagicaVoxel tool, something that I think will help me learn a bit about art and architecture and that I hope will be as fun for you all as it will be for me. I’ll be posting to my blog each time I work on a new voxel creation, so keep an eye out for those here!

The second of these new “series” is something that I’ve taken to calling The Critical Designer, where I play games and post my thoughts about different aspects of their design and whether I think they’ve been executed well or not. This could be about any aspect of design and I hope to be able to do these at least once a week with a blog update for each one, but no promises on this one!

Regardless, be sure to stay tuned and keep your eyes peeled for more updates from your favorite red-headed Game Designer! Thanks for reading and make sure to like and comment on my posts!

Down to the Wire

It’s already April and to be quite honest, I’m not sure how to deal with that. It seems as though my final semester of college is going by so fast that I’m barely able to make time for anything anymore. Enough about my life, though. Let’s do a little talking about Sword of the Sorcerer.

Three cheers for being ahead of schedule! Believe it or not we actually seem to be on the fast track to finishing up everything that needs to be done! I know, it’s exciting, but that doesn’t mean that we haven’t also had some hiccups along the way. If you read my last blog post, you’ll know that there was talk at one point of cutting the Anti-Paladin enemy from the game. To remedy this, we had George (the art lead) cheese some of the final animations so that they worked but still looked good. Luckily, this worked out incredibly well and it looks like the Anti-Paladin will definitely be getting to make his debut within the game in the coming days. Yes, I said days. We no longer have weeks to work on the game as we are required to meet specific deadlines for the Senior Show. In fact, next Wednesday is one of those major deadlines: Beta. That’s right, folks, Beta is due next Wednesday, giving us only five days to complete a list of objectives that are required for this milestone. In fact, let’s take a look at what’s required of us for Beta:

  • Second version of Team Poster due on Repo.
  • All project-specific goals are complete (as negotiated with Executive Producers).
  • Demonstration of revisions (as negotiated with Executive Producers).
  • Fully playable and well-tested game build.
  • All game features and options are implemented. The game is “feature complete.”
  • All design is locked.
  • The game can be navigated on all paths. Any bugs that may have closed off portions of the game are eliminated.
  • The game is compatible with all specified hardware and software configurations.
  • The game logic and AI is final. Programming is complete on the “gameplay” of the game. The game knows its own rules. All AI profiles are complete.
  • All controllers work.
  • 75% of final artwork is implemented. There should be no placeholder artwork left.
  • 75% of final audio is implemented.
  • All online modes are complete and testable. This includes game networking and companion websites.

I know, it’s a hell of a lot of stuff. Overall, I can say that I’m not entirely worried about us. However, there are still a few things on the chopping block that need to be worked out, like setting up the wave system to incorporate the two new enemies while still maintaining an effective yet fair difficulty curve. When it comes down to it, we’ve still got a decent amount of work ahead of us but I’m confident that we’ll meet the challenge head on and conquer it, just like we always have.

Thanks for reading and be sure to check back every week for updates on the game’s progress!

Crunch and Cheese Time, Baby

For the past week and a half, we’ve been in some major crunch time, which is actually not really something that we’re used to. Magically, we were able to avoid a lot of major crunch last semester through two different weekly work sessions. However, with the feature lock fast approaching on the 12th of April, we’re now rushing to get everything listed on our feature list implemented in time.

That said, we’re not really feeling like we’re under all that much pressure, surprisingly. We’re still managing to get our work done. On this topic, a little while ago we had spoken about possibly cutting features since we really needed to get working on another trailer for our game as well as a team reel to present at the Senior Show. I say features but the only real feature we were discussing cutting was the Anti-Paladin, the third and final enemy type in our game, and the one that acts a a sort of “legendary enemy” so to speak. Needless to say, this thought was a little bit alarming, especially given just how much time the art team has spent on that single enemy alone. With it so close to the point where it could be added to the game, I came up with an idea that would save the work the artists had done. Cheese it, baby. By that, I simply mean that rather than have our Art Lead and Animator, George Sutherland-Howard, bust his ass to make a brand new walk animation for the Anti-Paladin, I told him to just take a “shortcut” instead. Luckily, the cheesy walk animation actually came out looking incredible and it only took about 30 seconds as compared to several hours filled with fine tuning and tweaking. Just as well, we decided that the Anti-Paladin would only have one attack animation in order to save George time and work so we had an even higher chance of getting the enemy in.

Cheese seems to be the word of the day….or week, I guess. We’ve also had a couple of our programmers (and I don’t recommend this, usually) cheese some of the easier-to-implement elements so that they could be implemented and tested faster. This would include a fix to a long-standing armor bug that has only served to make our game so easy to beat that it almost isn’t fun anymore. All of this could work as good advice though and hell, I’ve actually received the same advice I could give you all here. Just make it work. That’s all that really needs to be done. It doesn’t need to be pretty right off the bat, especially not in VR. Just cheese it, get it in and test it thoroughly. It can be made nice and shiny and squeaky-clean later on during the polish phase. In fact, it seems as though this has become (for some aspects, not all) our new motto now. It took longer than it should have for us to realize that we just need to be getting new stuff in as fast as possible and testing it before polishing it, but now that we know that, it’s full speed ahead. Watch out for more weekly updates as well as updates about any possible side projects I’m working on! Thanks for reading!

Incorporating for Steam and Work Changes

Ah, Steam. I do love you but you certainly are a cruel mistress. Lately, we’ve been trying to get our game up on Steam, for free mind you, in order to garner more widespread feedback. Trying is the key word here as after we finally managed to get the whole project upload hierarchy for Steam set up, we found out that we need to submit a company form from our team in order to upload the game, something that we don’t have. Basically, it means that in order for us to get our game up on the Steam marketplace, whether it’s free or not, we have to incorporate and become an actual company or at least an LLC. It certainly wasn’t something that we were aware of and it put a bit of a wrench in that whole Steam plan. Well, sort of, anyways. Our Producer and I went and spoke to the college’s BYOBiz creator, a professor here, and he ran us through the process that it would take to become an LLC which, while not complicated, would also cost between $600 and $700. This was the biggest problem for us, being a group of poor college students and all.


Here’s a nice picture of the Steam logo that I found 😀

We spoke to the rest of the team about this development and we all agreed that we would attempt to speak to some of the deans here at the college in order to see if they would assist us. Right now, we’re looking to talk to the dean of the CCM department in order to see if the college or even The Champlain College Game Studio could cover the legal costs. So far, that’s as far as this development has gone but be sure to keep checking back for updates on this matter. There’ll definitely be a post dedicated to this specifically if we manage to get the game on Steam.

We’re not done here yet, though. There’s still one more thing that I’d like to talk about, specifically my role as a developer for Sword of the Sorcerer. Now, this isn’t me saying that I don’t want to work on this anymore or anything like that but it is a bit of an explanation for people (and maybe a little bit for myself). I am the Lead Designer for Sword of the Sorcerer, that much is obvious. However, I was also taking on a Level Designer role this semester to add to my workload since some of the stuff that I worked on (like particles, for instance) would be given over to new artists. At first, this was fine but at some point a few weeks ago we decided as a team that, given the timeline that we have for the game’s development, we would be focusing on the one main level that we have instead of creating any additional levels. This meant that a lot of the work I had planned was in a sense cut from the schedule which was a bit worrying at the time. It was for the best, though, as working on a VR game means less time should be spent adding and more should be spent polishing. However, that also means that a lot of my work this semester has been outside of the game with systems design and more-so gameplay design. I’ve been helping to make sure that we can make the second-to-second gameplay as playable and fun as it can be in order to attract more players. That means a lot of drafting up ideas on paper and not in-engine, which also means barely any repository commits by me will exist during this semester.

At first, I was slightly upset about this since I (at the beginning) felt like I wasn’t doing as much as I could/should have been. However, I now know that I still fill quite an important role on the team (as the Lead Designer, obviously) as a Gameplay Designer. As someone who hasn’t concentrated entirely on Gameplay Design in this way before, I find that, although a lot of my work is not in-engine, I’m learning quite a lot about this aspect of design. One thing I’ve learned is that I also enjoy this aspect of Gameplay Design almost as much as I do generic Gameplay Design that takes place in-engine, which bodes well for future job opportunities. I’m still getting pretty decent hours every week and I’ll also be helping out with particle systems and sounds in the near future, so there certainly isn’t any need to worry.

Hope you guys enjoyed reading this post and do be sure to stay tuned for more weekly updates on the game’s progress! Thanks for reading!



Some people might say that the title of this blog post seems rather unprofessional and to be honest, I’d be inclined to agree with them. However, I feel as though this is a decent outlet for venting when it comes to capstone and senior game stuff. So buckle up, fair readers, cause it’s gonna be a wild ride…..or maybe not, I don’t know. Please don’t leave.

Anyways, let’s take a quick look back. For those that have read my older posts regarding capstone game development, you’ll know that last semester was very strictly structured. There were set phases that needed to be challenged to get through and specific checklists showing what was needed to challenge each phase. Hell, teams could only even present at the Winter Showcase in November if they made it through at least the Deep Dive phase. While the structure was rigorous and the threat of being cut was rather daunting, that structure helped us as teams, giving us a goal to work towards right from the start. Enough with the flashbacks, though, let’s talk about the current semester.

As I am on one of the two VR teams to make it through cuts, my team and I were placed in the same production section as the other VR team and assigned a new teacher, one Benjamin Throop. He created a game for the PlayStation VR called Headmaster, which made him the perfect candidate for teaching the two VR teams. However, this semester, the class didn’t have the same kind of set structure as the previous class. Instead, we were more or less just set loose with our new teams and expected to work, which we did. Now don’t get me wrong, this wasn’t that bad. At first, we were a little skeptical of it but after a few weeks, we had settled into creating our own goals and our own sprints. We got into our groove. Things were great for 7 weeks until, in the middle of week 7, we were suddenly given deadlines that we were now required to meet, some of which were quite close already. If you don’t see why this is a problem, then perhaps you should apply to be one of the higher ups here at Champlain. I love the Game Studio and most of the professors that are a part of it; I’ve learned nearly all I know from them. However, it still doesn’t change the fact that waiting until WEEK 7 of the semester, which is basically right before midterms, to slap us with deadlines which should have been assigned on DAY 1 OF THE SEMESTER.

As a team, we had already decided to cut more than a few of the originally planned elements, including all planned additional levels. This, though…….this threw a wrench in our plans and put us in a place where we were forced to cut even more than was originally necessary. Sure, you could say that this kind of thing is bound to happen in real studios where we’re being paid and I’d agree with you. However, while the workload is intended to mimic real-world game development (something that the school succeeds at), it’s also meant to be more structured. If our team dynamic wasn’t so great and we hadn’t already been a bit ahead of schedule, I’d say that this curveball would have put us behind schedule instead of just a bit backset and forcing the cutting of additional features. Plus, we are now required to have an idle state for the senior show, where a video automatically plays when the game is inactive for a certain amount of time. This is another point of frustration seeing that as a VR game we CANNOT DO THAT. We’ve explained that to the professors in a few different ways and while I understand their offered suggestions are attempts to help, they just need to get it through their heads that an idle state cannot happen (at least, not in any way that we’re aware of) in VR. Hell, we’ve already decided as a team that we’re not even going to attempt to do an idle state at all. We honestly don’t actually need one to entice players and there’s no reason why the school wouldn’t let us present our game just because we were INCAPABLE (not unwilling) to implement an idle state.

Phew………I have to take a breath here. That was a lot, I know. It isn’t the overall longest blog post that I have ever written, but I felt like any readers that I may have should know what’s going on and I just wanted to rant about how inexplicably stupid this whole situation is. Anyways, if you stuck around till the end of this one, then thanks for reading! Please stay tuned for even more updates on our game, Sword of the Sorcerer! I’ve also got a bit of a blog-series planned that doesn’t have to do with school but that I think will be enjoyable. Keep an eye out for it!

1…2…3…Woo Ladders!

GDC and More Progress

So I went to GDC this past week for the first time ever and let me just say that it was awesome. Sure, it cost a ton of money, but I made so many connections and learned so much awesome stuff from all the different sessions and talks that I attended and all the great developers I met, indie or otherwise. In the future, hopefully even next year, I’ll definitely be back here. The connections and information that can be gained are invaluable and I’d say that coming here has helped me to become a better designer overall.

Actually, let’s talk a bit about some of the connections that we made at GDC this past week. For one, we met a man named Robin Alter, the VP of Strategic Partnerships of a company called Ultrahaptics, at the Champlain College reception. Ultrahaptics makes tech that uses sound waves to simulate touch and feel within VR spaces, allowing you to actually “feel” a shape within VR by shaping sound waves to that specific shape. It’s absolutely amazing tech but what’s even more amazing is the fact that both Robin and another member of Ultrahaptics, the VP of Products & Marketing, Anders Hakfelt, are interested in our game! That’s right, we showed them some footage of our game during the school’s reception and they loved it! So much, in fact, that Robin asked us if we could send him a playable build of the game to try out on his personal VIVE. This could potentially mean procuring this kind of tech for our game or at least the college itself, which would be a huge benefit to future VR developers here. It may take awhile to send them an acceptable build, but know that we absolutely plan to do it as soon as we’re able to.

We also stumbled across a company called Nordic Trolls here at GDC. They were showing off their VR game which is fairly similar to ours in that one of the two players is given a sword and a shield. We actually went as a team and checked out their game to see if they had solved any of the problems that we’ve run into so far such as actually getting people to use the shield. Unfortunately, while they solved stuff with the shield for themselves, the only solution that might be of some use to us for the shield would be to make it look cooler than it currently does. Still, even if we didn’t find a lot that we could implement into our game (at the moment, anyways), it was cool to see how a game similar to ours was produced and it was cool to see how ours compared to theirs thus far.

I gave out a hell of a lot of business cards too, so that was pretty awesome, and I also got to meet a bunch of awesome big names in the industry and chat with them for a bit. Basically, I’ll just end this blog by saying, if you make games or even if you just like them (and you have the money and time), go to GDC. You won’t regret it. San Francisco is a beautiful city (especially if you’ve never been before) and the amount of connections knowledge of game development and the industry itself to gain is priceless. Thanks for reading and stay tuned for the more regularly-scheduled updates that have a bit more to do with our game.


Hello again, my wonderful readers! It is I, Chris Jeffery, back with some more news about our game and its development. It’s been a bit of a busy week and we’ve added some cool stuff into the game!

First off, we’ve added Sparklebitch, the warhammer that I mentioned in a previous blog post…… least I think I did. We’ve got it in the game, working well and it looks absolutely fantastic! Hats off to our prop artist Andrea Leimer for her awesome work on the new weapon and some more great props to come in the future.

We also just recently got our new combat music from our friend Jackson Roe and it sounds absolutely amazing! With that, we can finally make a new trailer without copyrighted material, which also means that we’re at a point where we can begin the process of placing the game on Steam Early Access.

In fact, that’s one of the biggest things that I’d like to take the time to talk about. We’ve been planning to throw this game up on Steam Early Access for quite awhile now for a few reasons. First off, since we’re making a VR game we don’t have to go through Steam’s Greenlight program, which is actually incredibly helpful to us as it speeds up the process as a whole by skipping the “middle-man.” Second, placing the game on Early Access allows us to reach a much larger audience outside of Champlain’s campus much earlier which in turn allows us to get more valuable feedback from actual VR customers on the market. If we’re being technical, then we could say that having a game available on Steam also gives myself and my team members more credibility as developers and looks fantastic on both a portfolio and a resumé.

A Designer’s Take on a What Makes a Good Producer

In light of my experiences last semester during capstone, I’d actually like to make a bit of a different kind of post, a more personal one. As I first mentioned way back in my very first capstone blog post, I was not only the Lead Designer but I was also the acting Producer for my team as well. Now, I’ve played the Producer role before, but not since my freshman year back in 2013 and that time wasn’t even really that close to the extent of my role for capstone. So, I’d like to take up a bit of your time, loyal readers, and discuss exactly what I think (my opinion) makes a good Producer as well as how I think that I measured up during last semester.

Here’s a little bit of a simple breakdown of my points for you all before I get into more detail:

  • Documentation
  • Time management
  • Promotes communication and cohesion

First and foremost, as can be seen above, a good Producer should be willing and able to create and update their required and any useful business documentation. I know, I know, this sounds like a simple enough point but this is actually overlooked more often than not. Sure, maybe this isn’t as important a tool for Producers as some other things but these documents, which can range from simple project timelines to more complex business/project and budget plans, are more important than most people seem to realize. A big part of these business documents can be helpful when attempting to pitch the game during its development. Something that, in the field, can mean the life or death of the project depending on whether or not it is funded which can hinge largely on things like business/project and budget plans. Here at Champlain College, every team role is graded and critiqued on their documentation and is expected to complete it but seeing as we aren’t actually out in the field yet, it isn’t regarded as highly as it could, should or will be. Plus, writing these documents isn’t exactly what I would call the cleanest of jobs. They’re boring for most people to even think about, let alone write, and they can be a horrible slog for someone who isn’t interested in that aspect of the industry. For me, it was just that kind of slog. I hated and I mean absolutely hated writing Producer documentation but I still did it and I did it to the best of my ability as the acting Producer because I knew that they would only help my team in the long run.

Going off of that first point, it’s absolutely crucial that the Producer be phenomenal when it comes to time management. Don’t get me wrong, time management skills are something that every member of the team and most people outside of our field should have but the Producer, in my opinion, should be the top rung of this ladder. The Producer doesn’t touch the game but that doesn’t mean that they don’t have an effect on it. Instead of meddling in the engine, the Producer is in charge of taking care of documents, setting up team meetings, making sure the game’s budget is in check and getting the game’s name out there (at first) and that’s just barely scratching the surface of their role. Now imagine a Producer with horrible time management skills or a lack thereof trying to juggle all of these rather copious and difficult tasks. It just wouldn’t work. They would procrastinate, they would miss deadlines and the team and the game would most likely be affected quite greatly and the team may even fall apart completely. The best Producers that I have worked with during my time here at Champlain College have kept electronic or even written schedules for themselves that they adhered to every day to manage their time and tasks. I mean, you don’t have to be as thorough as that to be a good Producer in my eyes but at least have some skill when it comes to prioritization. Playing games comes only after we’ve spent some time creating them. Please reread that sentence a few times; I mean it. Many a student has been kicked out of Champlain College’s Game Studio during my time here simply because they spent more time playing games than they did making them.

A great Producer should not only be great with but should also promote both communication and cohesion within the team. This is a huge one because even as a student, I’ve already seen my fair share of game teams go under due to poor team cohesion and a lack of communication. Basically, the team is like a family and the Producer is like the mother or father. It is their job to make sure that each member of the team is kept in the loop and in constant communication with all of the other members of the team. As a Designer, I constantly need to be talking to both Artists and Programmers about different aspects of my game’s design and implementation but if I have no way to do that then it creates stutters in the game’s development timeline, stutters that we may not be able to afford. Sure, the other members of the team are also responsible for communicating with one another, but it is the Producer that ultimately acts as the glue to keep the team together, which leads me to the second part of this point: team cohesion. I’ll throw another analogy at you for this part, and this actually has to do with both communication and cohesion and even other aspects. I like to think of the game team and the game being developed as the roots and a tree respectively. The roots (the team) are what provide the tree (the game) with its nutrients which allows it to constantly grow. However, the tree can grow out of control and the team can be met with scope issues that may see the game unfinished or released too early to meet a deadline or even scrapped altogether. The Producer comes in as either of two roles, the pruner or the lumberjack (good and bad respectively). The pruner is the one that helps to nurture that communication and cohesion and lightly and politely cuts things from the game or development plan that may venture into scope-heavy territory, keeping the team and game grounded and on track by pruning the “game tree” in just the right way. The lumberjack, on the other hand, is the exact opposite of the pruner. The lumberjack doesn’t wish to see the game grow and flourish or even if they do, they end up cutting the whole tree down in one fell swoop through their lack of all of the above skills that I’ve mentioned and blatant disregard of their duties to the team. If you want to be a good or better yet a great Producer, please, for the love of all that is holy, please don’t be a lumberjack.

So how do I measure up?

Well, if I’m being completely honest, I’d say that I measure up quite well to the standards of a good Producer that I myself have set. That’s not a goo enough response, though, so I’ll go into a bit more detail about a few things.

  • Documentation – With this, I’d say I merited top marks. While, as I mentioned earlier, I hated writing business documents, I still did them and put all of my effort into them in order to do them well. I had them all done and updated when they needed to be in a timely manner and I opted not to draft documents that I didn’t believe the team needed in order to save time. Again, I’m not a Producer by trade, so there are a million examples of these documents that I’m sure I could find that would blow mine out of the water but overall, I’d say I did a damn fine job for a Designer.
  • Time Management – Throughout last semester, I’d say that I did a fairly decent job of managing my time when it came to working on Sword of the Sorcerer. That said, a tiny bit of procrastination with other classes led to a bit of slacking on the Producer side near the end, so I’d knock a few points of my score for this one. Still, I was able to get everything done that needed to be for both roles by the end of the semester.
  • Communication and Cohesion – This is probably where I shined the most. Throwing all modesty out the door, I would consider myself to be somewhat of a natural-born leader and that showed during our work last semester. I was able to assign tasks and cut things I (and the rest of the team) thought were out of scope with ease, but I also didn’t “rule” with an iron fist. In order to promote the cohesion I was looking for, I worked via compromise and consensus, making sure that all of my team members agreed on something or some kind of compromise after testing before anything actually made it into the game. Due to this, our original team never once had an argument or any really major disagreement on anything during the game’s development last semester and we were even considered to be one of the most cohesive teams with the best team dynamic. For this category, I’d give myself top marks.

Looking over all of this, I’d say that I would merit probably somewhere around a 7/10, enough for me to consider myself a good or at least a decent Producer by my own standards. That said, acting as a Producer for a semester taught me a lot about their work and the kind of effort that goes into being a great Producer and it’s a lesson I’ll never forget.

Thanks for sticking around until the end and I hope you liked this retro and introspective post! Stay tuned for more weekly updates on Sword of the Sorcerer and other posts like this one!