In the News

As we have been nearing the end of 2016, and knowing that I’d like to start creating a small amount of (local) buzz about my game, I thought it was a good time to consider doing some promotional work so that people can look forward to its (eventual) release. Since this project is very much rooted in my research as an academic artist and designer, I thought it would be best to work from within on the initial information release. Working with Jerry Poling, the Assistant Director of University of Wisconsin-Stout’s Communications, we crafted a press release that would be directed at local media outlets. Jerry’s UW-Stout release write-up was fantastic, capturing the research aspect of the game in a way that I could have never done.

That release ended up catching the attention of a few different outlets. I thought I’d take this post to do a round-up of those, so as to create a one-stop archive post of Fall 2015 press for Tombeaux.

2015-11-09 08.52.55

Tombeaux receiving front-page coverage in St. Paul’s Pioneer Press

St. Paul’s daily newspaper, the Pioneer Press, ran a nice piece about Tombeaux on their November 9th Monday edition. I was quite surprised to find it on the front page, as once I saw that I really wished some of the visuals from the game could have been represented there as well (but who am I to complain about front page press?!?). Their online version of the article did the game more visual justice, through a handful of in-game screenshots. Furthering the life of that article, the Duluth News Tribune re-ran the piece, which might have had more of an appeal in thre great northern, wilderness-focused mini-metropolis. Kelsy Ketchum, the reporter for the story, also interviewed Jennifer Sly of the Minnesota Historical Society about the piece:

“One challenge in video games set within a historical period is that you want to give players agency and choice, but it’s hard to do that without changing the historical timeline… Dave Beck’s work is one way to let users explore history in different times.” – Jennifer Sly, Minnesota Historical Society

Following fast on the heels of the Pioneer Press article, I was contacted by Wisconsin Public Radio’s Central Time hosts to do a short on-air interview. I was expecting to either receive prompts or questions ahead of time, but being a daily news show, they cut straight to the chase in a live, rapid-fire-question format. They actually cut me off halfway through my final answer/statement, but it was still great experience. You can listen to the full WPR piece here, or below.

CVLVk8WWUAAJTmE

WPR’s Central Time Interview from 11/19/15

Ironically, the initial stage of PR reached further than my local hometown area, crossing in to Minnesota and reaching to the far eastern edge of Wisconsin. After a few weeks of being featured around the region, it finally came home to roost, with a really nice feature online and in print by Nikki Lanzer in Volume One. Volume One is a bi-weekly arts and culture paper out of Eau Claire, WI. Her article was short and to the point, complete with a catchy (albeit cheesy) title of: “Tombeaux-lievable

20151202_084956

Color feature in Volume One

“Beck expects Tombeaux to engage players in a completely new way than what they’ve grown accustomed to from other computer games, giving them a refreshing and unique experience that will foster both historical awareness and appreciation for the St. Croix and its surroundings.” – Nikki Lanzer, Volume One

So, with the help of my university’s communications department (and a little overtime on PR myself), I’m happy with how Tombeaux has done in the public sphere up to now. This is especially so, given that there is so much left to do in the game for it to be called finished! Here’s hoping that 2016 shows as much success and attention as in this previous year.

See you in 2016!

 

 

Advertisements

At the Homestead

By now, it is probably somewhat obvious that Tombeaux is not a typical video game.  With me possessing a background in fine art and a career rooted in academia, I’m taking a slightly different approach to my project than many fellow peers in the indie game world. One example of this is how (and where) I’ve spent the last three weeks.  I’ve been the artist in residence at the National Park Service’s Homestead National Monument of America, in Beatrice, Nebraska.

2015-05-26 16.44.32

The Palmer-Epard Cabin, and original homestead cabin (and inspiration for the cabin in Tombeaux)

An artist’s residency is what I like to call a “work-cation” (I know, that phrase doesn’t make sense, unless you’re a workaholic…), in which I’m away from my family, home and university job, and focusing on nothing but making the game for literally 14 hours a day, 7 days a week (but I don’t recommend being away from your family for this long, as it is very difficult (on me, but especially on my wife Emily, who is a saint and superhuman/mom!)). Residencies are quite common for artists to pursue in the contemporary art world, as it provides the solace one might need to dive deep in to the “creative zone”. The idea is that an organization, institution, or foundation will award an artist (who has been selected through an application process) with the time and space to support their creative practice. Some residencies actually even provide outfitted studios, full-time chefs, and living stipends. Some have dozens of artists living and working at the residency at once (think “grown-up art camp”), while others have a single artist visiting with them (I prefer this – the hermit-like, no-frills approach).

2000px-US-NationalParkService-ShadedLogo.svg

The National Park Service has supported artist residency programs for some time, and it has always been a goal of mine to take part in one of these programs. I was fortunate enough to be selected by the Homestead National Monument of America as one of their 2015 Artist’s in Residence. I’ve spent the last three weeks researching, making, photographing, and talking in an environment that is the perfect fit for making a historically based game like Tombeaux.

The Homestead Monument of America site is dedicated to both preserving and teaching visitors about the Homestead Act of 1862, which granted 160 acres of free land to nearly any man or woman who applied. This act, signed in to law by Abraham Lincoln, was a major reason for the rapid westward expansion in the 19th century. Since part of Tombeaux takes place in the 1800’s and incorporates themes of homesteading history, working here has probably been the closest I’ll get to finding a “field laboratory” for conducting my game research.

20150526_153616

The restored prairie and Heritage Center at Homestead National Monument of America

As one can probably gather by now, my time here has been wonderful.  While I have hunkered down in my living quarters and art studio making the game for the majority of the three weeks, it’s given me the escape that I needed after such a busy and stressful year of working in higher education (in a state that has seen better days, in that regard). I’ve been able to consult archives and exhibits, photograph authentic objects, documents, and structures, and interact with visitors to talk with and receive feedback about my game.

At work in the studio, making Tombeaux (image courtesy of Beatrice Daily Sun)

Today is my last day at the Homestead Monument of America, and while it will be wonderful to return to my family who I’ve missed so much, I know I will look back and remember this place for the time, space, and resources it provided me. Frankly, without the National Park Service’s help, Tombeaux would not be nearly as far along as it is today (in the ballpark of 300 hours less developed, to be exact!).

Saving, SVN’s, and Schedules

Yesterday was not a very good day.  I spent about 12 hours trying to fix my project, due to a myriad of issues surrounding file versioning and back-ups.  Because of this situation, I thought the timing was perfect to talk about something that every indie game developer cringes at the mention of – PROJECT MANAGEMENT! So, on top of actually making the game, you also need to remember and find time to: back up all of your work, work with versioning/repository software, put together schedules and to-do lists, back-up all of your work, and constantly and relentlessly promote your game (and then back-up all of your work). For this blog post, I’m going to talk about all of this except for PR (it definitely deserves its own post, due to the amount of time it takes to do it correctly).

20150603_203203

Okay, maybe I’m a *little* paranoid…

So, back to yesterday. I woke up yesterday morning to find roughly 3/4’s of my entire game project corrupted (ie: files wouldn’t open, some assets missing, Unity spitting out errors, etc. – pick your poison, as they all happened at some point).  I honestly can’t say how it happened, as things were fine the night before.  Luckily, just as I tell my students to do, I had backed the project up in a couple different places the night before last (as I do every night), and was able to get most of it back. But it did cost me about 90 minutes of searching, finding, merging, and testing to do so (and even worse, I had to go back to a version from two days before to find a project that didn’t have any errors, so I lost a lot of work!). I’m a big proponent of cloud backup services (I use a combination of Crashplan, Dropbox, and Google Drive, all for different purposes), but due to me currently being somewhere with slower internet speeds, I had to rely on my collection of external hard drives (you can never have enough, as you can see in the picture above). It definitely pays to back-up in multiple places, as when one of them failed, another ended up working.

Untitled-1

File Versioning (like Perforce SVN, above)  is important for any game development process that involves teamwork and collaboration

But that wasn’t the end of it. The main issue that took of most of my day was due to me trying to make my project available online for collaboration with other people. Being somewhat new to this approach for my own projects (and wanting to experiment for what to use next year in the classroom with my students), I did some research into both GIT and SVN. A simple search of “GIT vs SVN” brings up over 400,000 hits, making it very hard to make up one’s mind on a clear winner for the best tool in game dev.  While they are definitely two different entities, both accomplish the same goal. They allow people to collaborate on projects simultaneously (if done right) and then allow changes that the developers have made to merge back into the master project, safe and sound (again, if done right).  I won’t go into much more detail about how GIT or SVN works (I’m not sure if I even know!) or which is the better option, because frankly, many others have already explained it better than I ever could.

I feel like the guy on the left.

I decided to go with Github, which proved to be easy enough at first (and worked for a few days), but something must have gone wrong. After crawling back from the dead with my earlier back-up issue yesterday morning, I decided to uploaded it to Github, so as to not lose even more progress.  Upon uploading, Github opened my files in the background, made conflict comments throughout the text version of the file, and put me in the point that I was earlier that morning – the Github-modified files would not open and everything was missing!  After wrestling with that for a few hours, I decided to try using Perforce instead, a SVN client that requires a server. While Github is praised by a louder, more passionate crowd, it seems like SVN (of which Perforce, a for-profit company, is only one of many who use SVN) seems to be a better fit for game development, especially within Unity. But, since I had to upload my entire project to the server before doing anything else, it continued to fail the upload, probably due to the slower internet speed.  After spending nearly all day wrestling with this, I decided to go back to what was working – sticking to my own personal local machine (the old-fashioned way!), and waiting until I get back to a faster internet to try out SVN and GIT options more thoroughly.

Screenshot 2015-06-03 19.43.48

Screenshot of Trello, the online project management app I’m using

Finally, I wanted to talk a bit about project management from the other side of the fence – keeping track of schedules, to-do lists, and milestones.  Software to support this abounds on the internet, due to teams collaborating across the country and globe. Because of this, the presence of some sort of online forum helps to make sure everyone is on the same page. I had a bit of experience with this in the last year, when I served as co-instructor and co-executive producer on a class project that brought together over 40 students to develop a game.  We decided to try using a product called Basecamp to manage our tasks, schedules, and conversations. While it probably works for many projects, it really ended up being a waste of time for us. Instead, we decided to fall back on a combination of Facebook and Google Drive, two platforms that are a bit better at handling communication and large files, respectively (yet there was still a big hole in project management that neither Google or Facebook could fill).  Because of that bad experience, I wanted to find something that would be a better fit for game development, especially since I’ll be instructing and leading a couple large student teams (around 12 per team) next year in my senior game development class.  After a bit of research, I came across Trello, which – so far – has been extremely helpful.  It is essentially set-up like a massive bulletin board – you can create to-do lists, cards, upload files, and manage schedules, all of which reside on the same screen (which is important).  While I haven’t experimented with it on a larger team yet, I’m hopeful that it could be an answer as the alternative to “Facecamp” (which is what we started calling the mess that was our project management situation last year on the Harvey game project!).

Screenshot 2015-06-03 19.44.18

Pulled back view of my entire Trello board for Tombeaux

So, hopefully this post shows that not all game development consists of fun forays into modeling, coding, and design. Some of it is the stuff that not many people like to do (and if you do enjoy it, there are certainly jobs out there for you!).  While the jury is still out about how I’m going to get my project online for collaboration, I hope that this one bad day will be it for a while, and I can get back to the steady and rewarding process of making my game!

P.S. please comment below or contact me if you have some suggestions about SVN or GIT, or (even better) are open to helping a GitNoob figure all of this out!


Ideate. Playtest. Repeat.

I’ll be honest, when people ask me what it is I do for a living, I take a small amount of pleasure in seeing their response when I say: “I make video games and teach game design”. Even though it is 2015, I still – more often than not – get the look from someone like my career is akin to what the people in the below video do.  This is most likely due to their lack of understanding behind the process behind game dev, and not necessarily the lack of respect for the medium (although the two can be connected, of course).

Game development is very similar to any other field of design or development – there is a problem or challenge put in front of the designer, and it is their job to solve that issue in the most efficient and interesting (and in my case, aesthetically pleasing) way.  People do it everyday. Product Designers make objects. Architects make spaces. Graphic Designers make images. Engineers make bridges. Game Designers make experiences. Some of those experiences can be profound and life-changing, while others are as shallow as the money it earns is deep.

I frankly don’t know where my game stands on that spectrum I outlined above, but I’d like to think it leans closer to the profound than the profitable. The challenge I gave myself was fairly straightforward: I wanted to design an experience that incorporated my interests in history and the environment into a digital 3D world that could be experienced by nearly anyone (including the 6-year old digital native that is my daughter, the 20-year old twitch-gamer that is my student, and the 70 year old tech-challenged person that is my mother). While it might be straightforward, it isn’t necessarily an easy “I can design that sucker in a day” sort of project.  This was going to take time, and I discovered that it was going to take more and more time the further I dove into the research, ideation, and game engine.

With this in mind, I wanted to outline a few key stages I went through in the beginning (and still am returning to), as a way to explain my process a bit better.  None of these are inventions by myself or new elements to the game dev world – in fact, one would probably be hard pressed to find a single successful game without these elements embedded into its process, so for any experienced game designers out there reading this, I hope you’ll be patient during this primer.

gdd_overall

Select Slides from Tombeaux’s Game Design Document

The Game Design Document

Simply put, every game needs some sort of game design document (GDD or design doc for short).  Some take the form of wikis, others a google doc, others a pile of papers, while others are through a slideshow/PDF.  This doc is essentially the “manual” for the developer(s) to reference and use throughout the process. Due to a game being so freakin’ huge and bridging across so many disciplines, this document is literally the 10 (plus a few hundred more) commandments brought down from the mountain (and heaven help the person who decides to stray from those commandments!).  This doc includes objectives, mechanics, narratives, level layout, game flow, playtesting, sound info, and dozens of other things pertinent to the game’s functionality and playability.  To use one more analogy – this document literally is the blueprint for the entire game.  The more you can solidify this document in the beginning, the less likely there will be issues like crunch, communication breakdown, or feature creep, later on.

tumblr_myjjeliP4j1sum3xmo1_500

Trim the fat on that design doc

I decided to go with a powerpoint/google slideshow for my design doc, so that I could rearrange the doc easily, integrate a large amount of media, and have it easily transfer into a pitch doc when speaking with others about my game.  In what started out as a relatively thin manual, my design doc grew into quite a large digital tome.  Perhaps this was due to my academic background of insisting on references and footnotes, or my artistic side wanting to see big, beautiful images throughout the doc.  Regardless, I’ve been able to cull it down to about 70 slides now, which feels like a good number.  While the initial work went into putting it together last summer during my Pine Needles residency, I’ve spent time over this past year refining it, largely based on the research and playtesting I’ve been conducting.

cabin_map

Map from sketchbook of cabin interior level

Map Making & Level Design

If one’s goal is to create an environment for a player to explore, a birds-eye view map to visualize that overall experience is probably a good way to start.  I have two environments to explore in Tombeaux (and the player continually returns to both of them): an outdoor river level and an interior cabin level. While I went through a bunch of different iterations, I decided to move in to 3D with two sketches I had made early in the process.

I was aware that my vision might be larger than what was possible for making this game, so you can see that I immediately sliced off about a quarter of the cabin interior space (above), as I know that virtual spaces always feel larger than they actually are in the engine.  While you can’t necessarily see it in the river map, I also ended up squashing down that entire level too, to make the overall exploration area like that of a square shape, rather than a tall rectangle like it is below.

river_map

Map from sketchbook of river level

Grey Boxing

From this point, it was time to jump into the game engine to get a feel for the virtual space I had envisioned.  Using my maps as blueprints, I dropped down various boxes and other primitive 3D shapes, so that I might begin exploring the pixelated, lo-poly beginnings of the world of Tombeaux. Normally, this is called grey-boxing, and while I basically did that, I went a bit further with some shapes, as well as colors and shaders, so that I could begin to envision sillhouettes and color palettes into the game (which quickly became much more muted and less Minecraft-y, after seeing them in engine!).

greyboxed

Grey …err… Colored Boxing

Playtesting

It’s my opinion that one of the biggest mistakes that game developers make is that they push playtesting back too late in the pipeline.  Picture this: near the end of the game development process, your game is like a giant, 15-ft tall snowball careening down a mountain at 250 MPH.  It is a lot easier to stop that snowball and rebuild it when it is near the top of the mountain, before it has gotten too big or started going too fast. Playtesters – people who aren’t associated with your game who could play it and provide you with some feedback – will help you avoid those last-minute snowball messes.

I’m a firm believer in playtesting your game from day one, which means you must have outside people play your game.  From those first playtest sessions, I learned about how to change the levels, tweak controls, reconfigure narrative, and even slightly change the direction of the game’s objective.  Those first two weeks of playtests were crucial to a smoother development pipeline down the road (and a big thanks to Emily, Josh, Simon, Amy, and Mitch for your help!). I’ll return to speak more about playtesting in a later post, in which I’ll dive into my reasoning, inspiration, and approach to the playtesting process.

kids

My kids, playtesting Tombeaux

Hopefully these short summaries about specific elements in my process have helped you grasp a bit more about the game dev process.  Before one can start actually playing the game as it was meant to be played, there is a great deal of research, design, iteration, and testing involved (not to mention all of the coding and art!). If only it was as easy as those guys said earlier, and I could just “tighten up the graphics a little bit” – but what’s the challenge in that? 😉

and so it begins (albeit a year late)

My name is Dave Beck, and I’m an artist and professor living and working in Wisconsin. I’m writing this blog for you. I hope this peek into my development process will give you a better understanding of my project (which I’ll introduce below), and possibly inspire you to follow and learn along with me on this journey.  I’ve got a lot of lost time to make up for, so before I dive into the “now”, I’ll start with the “then”, much of which happened over this past year.

On that note, I really should have started this devblog a year ago, when I first began the project.  But then again, I had no idea that it would grow to such the monstrous behemoth that it has, filled with so many design doc pages, polygons, pixels, sounds, and lines of code!  The project I’m talking about is Tombeaux. 

tombeaux

Tombeaux Blog Header

Tombeaux is a video game that I am creating.  It is an interactive experience that explores the convergence between cultures and the environment across a few hundred years of midwestern American history, taking place on a small section of the St. Croix River (which serves as part of the natural border between Minnesota and Wisconsin).  Through exploration, the player discovers new objects, environments, and narratives, all of which cause reflection upon our history and our future.

Map of St. Croix River, by Kmusser, based on USGS data, via Wikimedia Commons

As an artist, I see the medium of games as having a fantastic future in contemporary art and new media. It’s a wonderful way to educate, entice, and entertain an audience in ways I’ve always wanted to do with other media, but just couldn’t fully accomplish. I’m making Tombeaux for a variety of reasons, many of which I’ll expand on in future posts. I’ll talk about my inspirations behind the game, the development process, the factual research fueling its content, the collaborations supporting its creation, and other things that provide interesting angles about Tombeaux.

It’s already been a heck of a ride, and it’s only halfway there.  I hope you’ll consider joining me for this last leg of the journey.