Podcast: Play in new window | Download
Subscribe: Google Podcasts | Spotify | Stitcher | Email | TuneIn | RSS | More
This time on GameDev Breakdown, as promised, Todd runs through his prototyping process, start to finish.
This episode makes heavy mention of this post. Todd’s game design document template is available at Itch.
Podcast: Play in new window | Download
Subscribe: Google Podcasts | Spotify | Stitcher | Email | TuneIn | RSS | More
Game development and its specialties have a ton of potential for remote work, which is awesome, but has a unique set of challenges only you can solve for yourself. Do you have to agree to sit on calls with clients? How do you navigate project changes? How can you avoid conflicts? In this episode of GameDev Breakdown we’ll drill down deep based on real world trial and error.
I’m scheduling with new awesome guests all the time, be ready for more guest reveals very soon!
So You’ve Asked Someone to Work on Your Game for Exposure/Profit Sharing also links here.
Hi, aspiring designer! If you’ve been sent to this page, there’s a good chance you asked someone–or maybe many people–to work on your game for free.
“What’s wrong with that?” you may be asking yourself. “Why is everyone so angry?” This article aims to catch you up on a trend in digital creation that isn’t your fault, but may require you to adjust your approach. You probably have great intentions, and this article aims to provide you with sound strategies to move forward with your enthusiasm for game development and create a positive relationship with the game dev community.
Despite the game industry’s incredible growth and success, game development careers are notoriously difficult to get started–like, professional athlete difficult. Without finding just the right opportunity, people routinely invest years of skill development and preparation and still never land a job in the industry at all. Others get the opportunity and turn their whole lives upside down to make it work, only to fall victim to layoffs and other unfortunate realities of the pro development scene. Because of these difficulties, the indie scene and the larger learning scene have become one massive community of aspiring creators–let’s call it the “not-industry”–who have accepted the vulnerability of learning in a public setting in hopes of following their dreams.
There are different schools of thought on how to cope with a lack of sufficient funding in the not-industry. Many folks simply hold down day jobs. The lucky ones have jobs related to what they do in game creation, like commercial software jobs, graphic design for web and marketing purposes, or freelance writing for just about anyone. If these weekend warriors finish a worthy product, it may earn a nice little monetary reward; very few of them will get to quit their day jobs over it. Others seek to leverage crowdfunding or attract a publisher to keep the lights on and the hard drive spinning. Some are still in school and have their needs met for a time, and they hope to create something that shows their capabilities, pays for itself, or leads to a professional career in games. The struggle is very real for all of these people.
Unfortunately, the concept of working for low or no pay in the not-industry tends to hang over people’s heads. Those looking to outsource a certain component like art or code within the community sometimes have little to offer, and may rely on finding someone in a position to help for not much in return. Sometimes several community members will team up and work for no pay together, with an agreement about any future profits, if any profits ever materialize. Over time this has turned into self-appointed “designers” coming to the community to have their ideas brought to life.
Make no mistake: design is integral to game creation and not everyone can do it. The right idea for a game and the right strategy for implementation can soundly determine success or failure for a game. But it’s not safe to assume individuals with other specialties aren’t capable of their own design, or in fact, that they didn’t learn to code, write, or draw in the first place because of ideas they decided to pursue. For this reason, community members may become defensive if they get the sense that you’re presenting an idea as if they need it to succeed. They’ll be quick to tell you that it is you who needs them, and they are likely right.
If you’re resistant to this idea, consider if someone had pitched Queen on the idea of writing a certain song just before they went off and came up with Bohemian Rhapsody. Perhaps someone did. Would it have mattered? What if Bohemian Rhapsody itself had been the suggestion of someone outside the group. Would the concept have been worth anything without its brilliant implementation? How might the following Upwork job have panned out?
“Hi. Looking to recruit 4-5 performers to develop a song idea I have about a man discussing something with his mother. Volunteer only; 3+ years experience preferred. Message for details.”
Success in art is too personal for this. It can be personal among the members of a group, but that group has to have relatively equal footing and trust established. The community you’re approaching is hands-on. Everyone needs to bring a skill to the table, or at very least, a desire to learn and no apprehension about good hard work. Your idea is not equal to someone else’s sweat.
If you’ve been unpleasantly surprised by all of this, don’t abandon ship. If you’re willing to dig in and work toward your goals, you may yet find adventurers for your party. You simply need a more suitable strategy.
On the topic of “working for the exposure,” this philosophy is over. The only thing free labor exposes is that someone was convinced to work for free, and that usually only earns more requests for free work.
Some folks consider it sufficient to offer “profit sharing” after their idea is brought to life and run a team of volunteers like they’re running a major studio. I’ll start by saying I’ve never once heard of this working out (maybe someone has), but I’ll add that it would be extraordinarily difficult to do this in a way that is actually and precisely fair. Are you willing to give away the majority of the profit of your idea? Because you would almost certainly need to. How would you divide equity between two contributors who started at different times? What about one who started late versus one who left before the project was finished? With little doubt, you’d finish with some or all of your team feeling cheated and underpaid. What do you think would come next? It hardly matters; people who work free do not do so happily and they do not do it for long. Projects that get off the ground at all this way generally do not stay there.
If this profit-sharing scheme is going to work, I would strongly suggest you throw your current idea out, find like-minded creators who want to work together with you, divide up roles, and come up with something together as a group. Look at it as a partnership and an opportunity to learn. Work hard with this team and you will be doing something that has worked in the past with decent success.
My primary suggestion, however, is that you follow the path of the most successful individuals who came before you and start this project alone. You will be stunned at your own ability to identify and implement solutions as you go, and this is something countless game developers will confirm and swear by. Pay your dues, learn as you go, and limitless possibilities await.
I was challenged on this perspective just this evening by someone who said “You cannot do everything by yourself, that’s not how you grow as a developer or as a person.” I come before you as someone who taught himself the entire game development process, start to finish, and the idea that I learned less somehow by working alone is frankly absurd. That doesn’t mean I don’t believe in the power of community. My suggestion to anyone developing a game outside the pro industry is to develop in parallel with other creators. This can be done a number of ways including taking part in local or regional game development co-ops, user groups, or any other group that has a Slack or Discord server. Networking and talking shop with other developers is invaluable, and may very well lead to future collaborations, but you have to come from a place of sincerity and you yourself have to be willing to learn and put in the work.
Try not to take community sentiments about this issue personally. If you came in meaning well and you’re not simply looking for free labor, there is a place for you within our ranks. If you’re willing to personally do what it takes to bring your dream to life, you’ll fit in just fine.
If you didn’t know, we run a podcast that’s great for new creators called #GameDev Breakdown. Glad to have you aboard!
Photo Credit: “Ideas” by Sean Davis is licensed under CC BY-NC-ND 2.0
This post is a recap of my experiences running this year’s Itch.io Jam for Kids, including a few things you may want to keep in mind if you’re ever in charge of a jam yourself.
On or around June 18th, my four-year-old asked me to make him a video game about trains. This was actually a continuation of a discussion we’d had earlier when I declared I was deleting Budge Studios’ Go Go Thomas from my phone, as I find their microtransaction model for the game to be red-hot garbage. I said I’d be thrilled to make him his own game rather than have an app for children advertise about $20 USD worth of in-app purchases twice for each activity. This was not an idle threat; I’ve done it before. So as promised, I brought the Surface Pro to the kitchen table, fired up Blender, and set about modeling a toy train to see if I could do anything interesting with it in Unity. When I had a reasonable starter model in place, I tweeted it out, because that’s what one does.
My devfam was enthusiastic and supportive as always, but one reply caught my attention more than the rest.
I half assumed @TrashGameArtist was kidding, but for fun I replied with some things he’s interested in and didn’t think much else of it. But the conversation about theoretical kid game designs developed until the suggestion to start an official Itch.io event was made. I thought this was a fantastic idea. Kids need useful play experiences more than anyone, as it directly stimulates brain development, yet they put up with some of the worst, most exploitative designs imaginable. If my admin time could help produce even a few positive playable experiences—not to mention place a sensible time limit on this activity for myself—bring it on. I logged into Itch, cobbled together the most basic of guidelines, and the Itch.io Jam for Kids was born.
What followed was two weeks of incredible learning, great community discussion, and sure enough, a prototype for To the Station! A toy train simulator developed to spec for a preschooler. I didn’t plan on taking away any worthwhile lessons from hosting the jam itself, but I couldn’t help it. Here are some notes in case you ever try this yourself.
I first got to know Itch as a journalist covering indie games. I was super impressed by the features implemented simply to make my job easier, and in turn, put more eyes on the platform’s game developers. When I came back to try out jam hosting, I was just as pleased. The proof is always on display in the always-loaded jam calendar. I’ve been an enthusiastic Ludum Dare participant for a good decade, but it’s getting difficult to imagine not using ltch for any jam at this point.
I’ve probably participated in my last 48-hour jam. I knew my own time for this jam was going to be under assault by everyday life. I also chose to start the jam with no lead-up time, so I decided to blow out the traditional weekend format and give everyone two weeks.
What a win this turned out to be! I think the best strategy is to pursue a design no grander than you’d dream up for a 48-hour jam, but to find a groove completing and perfecting it around the rest of your everyday life instead of replacing your life with frenzied crunch development. After all, this is how release-worthy games are completed.
Anything longer than a couple of weeks, I suspect time management issues and scope creep would rear their ugly heads. Less than two weeks, I don’t imagine putting myself through the stress again. It’s the two-week life for me.
This is a no-brainer going in but remembering it for two weeks is harder. Not many folks will likely want to run small-to-medium jams without working on an entry themselves (rules permitting) so a host simply has to find the right balance for their time. Two different days I had to hang up intricate development tasks to deal with situations I felt might put participants or others at risk in one case or make us all look kind of ridiculous in the other (more on this later).
I also felt pressure to set an example in the attached forum, participating in discussions where I could, running a progress thread about my game, and of course responding to any questions that came up during the event. By the end of submission day, I’d given up several features on a fairly modest list to fulfill the host role successfully.
Of course the reverse of the previous point is true, but it’s worth discussing what that looked like.
On only the second or third day of the jam, a participant posted a dual entry he was working on for an earlier jam focused on education that overlapped with ours, explaining that it contained not only a prototype, but also a lecture he’d put together about designing for kids. In my mind, the timeline was an issue that would prevent his project from being an official entry, but he joined hoping to participate and posted hoping to help. I wanted to at least check out the project and presentation and provide some encouragement. Unfortunately for my Surface Pro, his was a fairly large project and was downloading too slowly over Wifi. I determined I’d check it out first thing when I next sat down in my office and provide feedback.
The only trouble is I never made it back to my desktop PC. I actually still haven’t. I had to continue work on my game and provide official support for the event. That’s simply all there was time for. I should have stayed laser-focused, even at the risk of appearing rude or uninterested in anything else.
In order of sheer audacity:
A participant posted pretty early on that they hoped to make a basic racing game in Unity but realized the scope was going to be out of control (which is very correct), so they found a Candy Crush-like tutorial series they wanted to follow to wow us all with a puzzle game. It sounded great to me. I wished them luck and said we were all looking forward to seeing it.
I got a notification a day or two later saying they’d submitted an entry.
I suspect not everyone knows this, but a jam host can see the exact date a game was submitted to Itch, and this one was something over a year old. Perhaps I’d still try it and offer feedback before officially disqualifying the entry. That’s when I noticed the following paragraph on the entry’s Itch page:
NOTE: If your virus detection software is acting up when you load up this game, please ignore it because it’s just the software being suspicious because the app is not recognized by it. So if it says anything please just ignore it.
Right. I followed up in the forum, asking why his submission was showing up as being more than a year old, also having a YouTube trailer a year old. I didn’t dive into the antivirus topic. He claimed the second game attempt overwhelmed him and he simply wanted to have something to submit. He hoped I’d understand. You couldn’t craft any better test for a jam host, because it was either a perfectly sincere story that must have been hard to admit for a vulnerable participant, or he was trying to destroy all our machines from the inside out. I’m no King Solomon, so I used the easy pre-existing project excuse and disqualified the entry which removed it from the submissions page. It was probably legit; I wish the developer the best.
As the jam was drawing to a close, I was eager to try out other submissions. I saw a notification pop up on one of the final days saying an interactive fiction novel had been submitted. Interesting choice for a game for kids, I’d better have a look. When I got to the submissions page, I couldn’t help but laugh.
The game was $7.99 to play.
For good measure, this game turned out to be long pre-existing as well, but I couldn’t help but laugh at the boldness required to join a game jam and try to sell the entry to the other participants. It’s hard out here for us indie devs. I get it.
In the end, we had a couple of awesome entries to keep mine company. A user called Sipsop created the Surprise Eggs Machine which was a cute little proof-of-concept which could easily be tied into a real brand. Minemaster552 who said he’s only 13 years of age submitted Lego City Builder, an unauthorized FLASH Lego game that was off to a great start at the end of the event.
My four-year-old got his train game and even provided the name. To the Station! in prototype form convinced me a toy train simulator could be viable and fun. I’m in the middle of my book project—alright, not the middle yet—but I’m excited at the possibilities of the prototype and have concrete ideas in mind about how to carry it forward.
I think the Jam for Kids will come back around this time next year. The biggest change will be even longer, even clearer rules upfront. Everyone seemed to have a great time, I know we all learned a lot, and we just might have started some projects that could go the distance. Hosting was a deeply rewarding experience and I’d suggest it to anyone. The better our events, the stronger the community.
Comment with your best theme idea for a jam!
We’re in the last four days of our Itch.io Jam for Kids! I’m working hard on the train game for my son that started it all, and since I just unlocked our Patreon post on planning and prototyping a new game project, I wanted to provide more information about one of my productivity recommendations.
As you can read in the post, I set up a recent project in Microsoft’s Azure developer site which provides a dashboard with a lot of cool features including support for multiple repos in one project, an attached wiki, and the tools needed to run multiple Kanban-style task boards for team collaboration (or organizing your solo efforts). I strongly recommend teams and soloists work from a task board which I elaborate on in the prototyping post, so I was very impressed when I also found the Trello support currently in Beta at BitBucket, my go-to Git provider for private repositories outside the Azure sandbox.
If you go to the Boards tab in your BitBucket repository dashboard, you’ll be asked to log in to your Trello account and be given the opportunity to access or create a new board for your project which appears embedded there in the dashboard.
While this alone is nice, Trello will allow you to connect to your BitBucket account in return (yes, this apparently has to be done both directions), and allow you to “attach” a Git commit to a task on your Trello board, which results in the ultimate tidy new way to organize your development workflow.
I was already describing task cards in my Git commits like so:
So now when I move a task card to the completed column, I open it up and hit the BitBucket power-up:
This pulls up the following BitBucket options to attach a recent commit:
The recent commits option pulls up my recent pushes:
And finally, attaches the commit to the completed card.
If I return to a completed card and click on the attached commit, I will go straight to the BitBucket commit summary so I can look over the changes.
As I mentioned, these features are apparently still in Beta and may change, and they haven’t been perfectly performant–I find that I sometimes need to pull up the Trello board in its own tab before attaching a commit to a card–but the connection between these two tools is welcome, and I strongly recommend considering it if you have need for private repos and prefer not to work in the Azure site option we discussed in my recent post.
If you’ve been using this a while, let me know how you like it in the comments!
This post is based on a suggestion from our Patreon Writers’ Room by patron Charlie Cox.
In this post I aim to run readers through the process of planning out and beginning work on a game intended for commercial release. I aim to keep “fluff” to a minimum here, but I will provide context where I think it will be beneficial, particularly while explaining my game project. This process looks different for each developer, and because experience leads to change, developers often alter their own process from one game to the next.
To help illustrate my process, I’ll be showing the steps I’ve recently taken with my own recent game project, a game I’m currently calling Cart King ’92.
When I was a young kid first discovering the world of gaming, I think the physical act of playing games was a lot more interesting. Certainly, games have always been hanging around retail stores, but we also had the triumph and heartbreak of searching for hard-to-get titles at rental stores, the unique experience of going to other people’s homes and buying their games (okay, you can probably still find games at garage sales), and there was even a thriving underground economy of backpack-to-backpack buying and trading at schools that had largely outlawed gaming paraphernalia thanks to fear-mongering news outlets. Back then, our parents largely believed it.
For years I’ve wanted to find a way to capture this era in a game for other folks who recall those days and later so my son can get just a little hint of what life was like before the internet took us mostly digital. Recently I thought of turning this into a playable experience by blending the gameplay and style of a retro RPG with the inventory management and NPC interactions of a space sim game like Elite: Dangerous or, well, any of the others. The story that came to me was a kid from humble beginnings who set out to build the ultimate video game collection. They’ll compete with other notable kids in sort of an ongoing Civilization-style leader competition where multiple endings would be possible depending on what they accomplish. I eventually determined that, though the idea is unusual, it’s worth finally taking a run at it.
Let’s talk about game design documents.
In the pro game industry, a detailed game design document acts as a unified answer book to keep medium-to-large development teams on track once a game leaves the planning stage. But there’s another benefit, and a reason any indie developer, even as a soloist, should fill one out for any serious project: it will force you to answer questions that go beyond the idea in your head to get you thinking practically about your potential game as a viable product, what you would have to achieve to bring the idea to life, and what you would be able to do with it once you did. I think at best you can expect several major hurdles or drastic changes of direction in a project if you get an idea and just start coding without a design document. At worst, you realize the idea was much more complicated than you realize or find out there’s a good reason the idea doesn’t work in the real world at all.
To account for the differences in how professional teams and indies benefit from game design documents, I’ve been tweaking one to my liking for a little while now. To help with this post and my own upcoming project, I’ve cleaned up the document, added some template notes, and uploaded it to Itch.io where you can use it freely. It’s been very popular there!
My game design document template at Itch
I believe a game design document should be the first thing you will do after deciding for certain that you want to pursue a project. That’s because the document will require you to answer questions about what you want to achieve in your prototype, what you want the game to look and sound like, and how you want to put assets together with code or a game engine. In addition, it will take you through the roles you play as a marketing expert, a designer, a developer, and all the other responsibilities of an independent creator. Finally, it will have you look to the future to determine what will mean the project was successful, and what your priorities will be for the game after release.
If you get through the game design document and feel you’ve provided good answers that will set you up for success, you are ready to set up your project.
Setting up a new development project is not a new experience to any developer, published or not. Most of us have set up countless projects, turning some portion of our hard drives into graveyards for wasted potential. But if you have a good design document under your belt, you should be eager to dig in at this point.
Needless to say, this part will look different for everyone, but I’m going to explain how I got started with my latest project, a couple of things I firmly believe everyone should do, and then a couple of things I’m trying that are giving me stellar results this time around.
I decided I wanted to have my hands on as much code as possible for Cart King ’92 because I don’t want to spend another project trying to figure out what Unity wants me to do when I would have known how to do the thing in code. That said, platform flexibility was important to me. If this game turns some heads on PC, I may very well try my luck on one or more consoles. So, I needed a toolset that would let me code the game the way I wanted, but was also mature and full-featured enough to give me some options at release time. Surprisingly enough, the leading way to achieve this is likely some version of Microsoft’s discontinued XNA framework. XNA’s demise led to the development community’s XNA extension project, Monogame, and a framework called FNA, which is a different extension focused on being the closest translation of XNA possible. FNA is often preferred for PC releases, where many folks like to use Monogame for console projects. If that sounds like a mess, then I’ve probably done a good job of explaining the situation. Basically I started this project in Monogame, went to our old podcast guest friend, Path of Motus creator Michael Hicks with some questions, and he happily answered them but warned me that FNA was probably going to give a more positive development experience, and he even had, not just A video series about FNA, THE video series about FNA that is advertised on the FNA homepage. God bless you, Michael Hicks.
Starting a new project should be done according to your engine/framework’s creator recommendations. Playing it by the book when you’re starting out will get you in the right frame of mind and will help get you the most out of your tools. I recommend following the directions to get a new clean project started, then immediately committing that starting point to the version control system of your choice. As I’ve mentioned before, I’m a Git man.
A quick aside on version control: I was a holdout for a very long time on using version control as a solo developer. To be completely honest, I made it through my first commercial release without it. I was using Lua at the time and the files and tools stayed simple throughout. I worked out of a Dropbox directory and even managed to use it to restore incomplete files or get rid of unwanted changes. There were also a couple of small issues I did not recover from that way. Nonetheless it allowed me to mostly protect my files and work smoothly between multiple machines right up through game launch.
Unfortunately, there are several reasons you should not depend on a service like Dropbox for a software project. First off, the services are not designed for this purpose, so using them this way becomes inconvenient in a hurry. The various snapshots Dropbox takes of a file, for example, are not perfect. There were a couple of times I tried to restore a file at a certain save point and it simply existed nowhere. You’re not really in control of how a service like this manages your files, it simply works on its own schedule which will eventually be at odds with what you need from it. Real version control, on the other hand, allows you to determine when to commit changes and create a project-wide snapshot of the entire project directory exactly as you want it to look. No matter what you do to the project in the future, you will be able to return to this precise state as long as the repository exists. Second, big game engines like Unity and Unreal hate when you work out of a directory being managed by a service like Dropbox. I don’t know what the experience looks like now, but there was a point in time when I tried this and I literally got non-stop notices from Dropbox about files being saved, synced, resynced, and occasionally, complaints that they were locked or in use. It becomes a nightmare fast. Unity loves Git and includes a variety of tools you can use to manage your repository right there in the editor. Finally, using Git or Subversion gives you an opportunity to sharpen a valuable skillset that stays in demand on professional teams of all shapes and sizes. Maybe you will never work on a software team in your life, but you may collaborate with someone who would love nothing more than to “go pro,” and this will set them up for success as well. Finally, learning and using Git is weirdly fun to me. I prefer the command line. It’s dead simple to learn and I just enjoy it.
Before we move on, I also recommend a solution like Git’s Large File Storage system. If you’re not familiar with the “large file problem” in version control, we covered it pretty well in my #GameDev Breakdown chat with Edward Thomson and Kayla Ngan of Microsoft Visual Studio Team Services at GDC ’18. Basically, using version control for game design often causes you to commit copies of large asset files like images and sound files repeatedly as you save changes to the repository. If you’re not careful, this will cause the size of your repository to explode. Some people, as Edward Thomson explains, will configure Git to simply ignore these asset files, creating a situation where they commit code to their version control repository and leave asset files in a Dropbox directory or on Google Drive. This seems like a nightmare scenario to me as well. Fortunately, Git Large File Storage will allow you to commit asset files to your repository once, then your repository will simply maintain links to those files unless direct changes require them to be committed again. I’ve been using this for a short time now, and for game development, this causes Git to behave exactly the way you want it to.
So what about hosting for your version control repositories? GitHub is an awesome site and I think just about every developer should have an account there for fun, collaboration, and portfolio purposes. Unfortunately, any repository you maintain there for free will be public, meaning anyone can go to your profile and see what you’re up to. You may determine that that’s totally fine with you, and then your problem is solved. Bitbucket is a get-started-free option that gives you a certain amount of room, particularly if you’re using Git LFS there, where you can maintain private repositories up to that point. I’ve had a Bitbucket account forever and have not run into any limitations.
There’s another option that I discovered in conversation with Microsoft cloud advocate, Jessica Deen, also at GDC: If you set up a workspace at Microsoft’s Azure DevOps site, they offer unlimited private repos just to have you in their sandbox. I wanted to try this, because eventually leveraging some cloud services for my games is well within the realm of possibility and I like what I’ve heard about Azure for this purpose. I found loads of benefits to doing this. I don’t know what the future holds for this offer, and maybe one day I’ll have to migrate out, but I love using the Azure site. Starting a new project gives you a project dashboard with several nice features. I was able to start a task board for work items which I consider another absolute must for a new project. Trello is a great alternative, but this turned out to be a great way to have everything integrated. You can also start a Wiki for your project, so if I were to bring anyone on to work on Cart King with me, I would absolutely go into my design document and turn the sections of the doc into Wiki entries, capture concepts about the game, and would maintain that all the way through the project. I also recently learned I can have multiple repositories in the same project. Why would you ever want that, right? Sadly, I got a decent amount of work done before I thought to go talk to Michael Hicks about my current project. When he showed me FNA, I decided to start a new project his way, follow through his video series, and then bring over as much of my work from the original project as I could, so in my Cart King project I have a repo called CartKing92 and now a second called CartKingFNA. It’s nice that this didn’t have to go in a completely new project. The DevOps site certainly goes even further, but these are the features I’m happy about right now. However you decide to start, at minimum, I strongly advise a version control system and a task board like you can use at Trello.
With our game design document safely tucked away, our project started and established in a repository, the scope of the prototype should already be established, only leaving you to decide what to work on first. I often find myself working in a new engine or coding with a new framework, and when this is your situation, I’m known to take things very slow. A lot of developers like to invest a ton of time up front, deciding what helper functions they need on day one, mapping out object-oriented class hierarchies in detail, and even making plans for custom editors before they’ve done too much of anything on a new project. Michael’s FNA video series on YouTube does this, because he’s a very bright programmer and has intimate knowledge of the framework he’s using. If you are already reasonably comfortable with your tools, I’d encourage this. Who wants to rework something later for no reason, right? Work smart, come up with a great plan of attack, and use the hell out of that task board we talked about. Not committing everything to memory means your brain gets to stay nice and relaxed throughout your project. If you’re more like me and usually learning something new while you’re working, I’m a huge advocate for baby steps. My initial task list literally contained work items like “Get project to build without errors. Draw one frame of a sprite on screen. Get character to respond to keyboard events. Get spritesheet animations to work. Get character animated correctly based on direction.” As I worked on these and tested them, invariably I’d find two new things I needed to do for each time I test the game. Which is good! On to the task board they go. I strongly believe in establishing positive momentum when you’re not confident. In this scenario, I think it’s okay to go back and clean things up and refactor code later when you feel very good about what you’ve already achieved. Worrying too much about whether the player character extends the animated character class template or the projectile character class template while you’re still not sure how spritebatch drawing works is a great recipe for feeling overwhelmed and possibly quitting before you really do anything.
Once my task list is established on the board, one task usually stands out as being the most important thing I can do next, so I move it to the “doing” column, finish it and test it, commit my changes to the version control repository, move the item to the “complete” column, and move on to the next one. This loop can be repeated until your prototype is completely done.
Other things I strongly believe in: Use as much dirty programmer art as you want so you can get things moving. You have the project’s whole development cycle ahead of you to source art or perfect your own. Use asset packs from absolutely anyone who will give you permission. There is zero shame in this. I ran across an online tirade from an artist one time declaring “any developer who uses Fiverr to get cheap art is not a true creator!” He seemed to believe he could rant a magical budget into people’s pockets which they’d, for some reason, spend on him. That is not real life. Who wouldn’t want to do work with a great artist? In reality, most of us have to work our way up to that, and it does not make a lot of sense to me that an artist would be trying to stop the train that’s eventually going to reach their station. I look at resources like OpenGameArt, Kenney.nl, and any others I can find without a care in the world for what someone else might be doing with them. I give credit, I thank people, I use the material in accordance with the license, but I know that what I do with it will be uniquely mine. I try to make each decision feed into momentum and productivity. If one choice lets me work, that’s the choice I make. Everything else is secondary. This is how muscles are grown and milestones are achieved.
The prototype point looks different for each project. Initially I wanted to be done with a prototype before putting together this post. For Cart King, however, I realized a lot of intricate subsystems actually need to be functional before I can give players a sense of what the proper game is going to feel like to play, including a fairly mature inventory system, dialogue, a system that maintains loads of data about the in-game video game market, all in addition to the standard retro RPG controls of walking around, colliding with doors, pressing A to talk, etc. For this reason, what you’ll do with feedback to continue work on the final game will be unique to your project also, but you will largely continue the same work item -> code -> test -> commit -> Update tasks loop until the last problem is solved and you are ready to get a great Early Access campaign going, look for funding, Beta test, straight up launch the game, whatever you want to do next.
Whatever your strategy, make sure you’re taking plenty of time to update players and friends on what you’re doing with the project so you can build an excited community of true believers ready to dive in head first and help you tell the world about what you’ve done. Precious months and years of your life are invested into these projects—take it seriously, do it well, and understand that even if you work solo, you do not live through the experience alone.
Cover photo: “GDC Online 2011_Tuesday_Show Environment” by Official GDC is licensed under CC BY 2.0
Podcast: Play in new window | Download
Subscribe: Google Podcasts | Spotify | Stitcher | Email | TuneIn | RSS | More
If you don’t think you’ve read or at least seen any of David L. Craddock’s phenomenal books on the game industry and game development, check again, you probably have. Some of the greatest stories of the development space have been captured in David’s phenomenal pages, including Blizzard’s early history with Diablo, tales from the days of NetHack and other early Roguelikes, and more recently, Yacht Club Games’ action-packed development of Shovel Knight for Boss Fight Books. He kindly agreed to Skype in as Humble Bundle closes out its Boss Fight book bundle promotion (you still have about two days!) and his insight was every bit as interesting as I expected.
This is a must-listen for writers of any kind, and I’d also put it on the required show list for anyone running or connected with an indie studio. David has explored and documented not only the development of many games we know and love, but the culture, the energy, and the trials of the people creating them–and his knack for framing captivating tales from their accounts is second to none.
David’s links:
Podcast subscription links:
Audio show:
Podcast: Play in new window | Download
Subscribe: Google Podcasts | Spotify | Stitcher | Email | TuneIn | RSS | More
I’d have to do some detective work to figure out how long I’ve been Twitter pals with Say and Michael, but I’m sure it’s been a couple of years now. One of the greatest benefits of doing this podcast is having the opportunity to go beyond tweets and capture the stories behind the work and the art that we enjoy seeing around the web, and this week’s show with the Silverware Games team did not disappoint.
Silverware (and Say and Michael make up the whole team, most of the time) is behind the Matchyverse games, including MatchyGotchy and MatchyGotchy Z, both technically tie-in games for the upcoming Matchy Star. That may sound like a lot to take in, but it’s as clever a strategy as it is ambitious. The team is spread thin with the parallel projects, but they have substantial momentum and they’ve achieved solid reach on Steam and social media.
In this episode, we discuss Silverware’s games, their interesting casual design philosophy, life on Steam, the Epic store, the great difficulty debate, and more. Thanks to Say and Michael for their time!
Silverware’s Links:
Podcast Subscription Links:
Our new intro voice-over is by none other than Tim Kitzrow, the voice of NBA Jam! Tim does custom recordings on demand at WhoSaidWhatNow.com. Check him out!
Our new theme, 8-Bit Memories (ft. Xiu Xiu / prod. Giuseppe) by Time is available to stream at SoundCloud along with a whole bunch of his great tracks. He reached out to recommend the track and it’s incredible, thanks again. Show him some love!
Audio show:
In this post, we’ll discuss the retro virtual console, Pico-8, why you might be interested in it, and tips on how to get started.
Patrons saw this post first! Check out what we’re doing at Patreon to provide exclusive opportunities to our supporters!
Don’t feel bad if you don’t yet know about Pico-8, even if you’ve seen some of the cool Pico-8 projects floating around Twitter or the web. Although there’s a deeply devoted user base, the application is fairly new, it has a price tag on it (currently $15 USD) so you can’t just freely download it, and it doesn’t quite let you create a viable product you’d want to sell, based on its limitations.
That said, Pico-8 is an all-in-one console with a built-in developer kit, which makes it a fantastic way to learn or improve your game development skills. This is why the Pico-8 scene, particularly in social media, is booming.
Apart from any form of development, it’s plenty of fun simply to use Pico-8 to play games you can download from creators directly inside the application, and this is a great way to find your way around. The handy game browser lets you download and play unlimited games and demos from a community curated collection, rated by popularity, all for no additional charge. You can play your favorites, poke around in their source code, and even modify them to your heart’s content. If you’re beyond a certain age, it may remind you of the very oldest days of distributed PC games, and the way many legendary programmers got their start.
Once you’re ready to start a project of your own, you simply enter a command to save a new “cartridge” with a name of your choosing, and off you go. The built-in game editing tools include a code editor, sprite editing tools, and capabilities to design your own sound effects and music. It’s up to you to design and implement a game using the system’s harsh limitations: games for Pico-8 are played on a 128×128 display (which can go full-screen) in 16 colors, with the whole game not exceeding 32 kilobytes. For reference, that’s actually much larger than an Atari game, but only about a quarter of the size of many of the more modest games on the Nintendo Entertainment System. Coincidentally, supported USB controller configurations very closely match the NES d-pad/2-button layout.
Upon completion, you can export your game to a nice-looking virtual cartridge complete with a screenshot from your game, you can export gameplay gifs directly from the system, and you can upload the game to the community forum where it will be displayed for users to play and discuss, or download directly within the Pico-8 game browser.
It’s fair to ask yourself why you should spend time worried about a retro game system that sort of doesn’t exist, for which your games must remain short, simple, and generally have no hope to earn you money or mainstream notoriety (don’t tell that to our friend Paul Nicholas, who’s managing both). To answer the question, it’s worth examining the strengths of Pico-8 development.
First, Pico-8 has a great community in a discipline where there aren’t that many functional areas to go off and specialize. For the most part, Pico-8 developers are doing similar activities all the time, and it’s rarely difficult to find any issue your having being discussed on forums or Twitter. Everywhere you look, other users are eagerly discussing the craft, and if you’re new, this will bring you a long way in a very short time.
Next, Pico-8 uses Lua, a pretty friendly scripting language that can be picked up in a relative hurry, but also has applications beyond Pico development. Many employers value proficiency in Lua, and there are even other game engines and frameworks that will allow you to port your code to a heavier duty environment, and perhaps even turn your small project into something releasable later.
This one will seem counterintuitive, but Pico-8’s technical limitations will make you a better designer. You will do more with less, you will not get sucked into an endless cycle of never-ending asset improvement, or worse, blank page paralysis. The tools are all right in front of you and require fairly simple assets throughout. You will spend the most time focused on limiting your project’s scope and sticking to it. You’ll do creative problem-solving, optimizations, and probably reach for new levels of elegance in your design, and these skills are all directly transferrable elsewhere.
Finally, Pico-8 is a great way to develop simple prototypes and small, shareable experiences. I’ve had a great time sharing my Pico projects on the web with friends and family, and have had positive experiences developing learning games for my son in situations where I didn’t think development of a full product was viable.
So how do you get off to the best start possible? I strongly recommend you start by playing some games and seeing just how much this miniature virtual console is capable of. Find projects you like, open them in the editing tools, and poke around to see how they did what they did.
You may initially be inclined to code the whole project in the built-in editor. Spend as much time you like this way, but know that you can–and should–move to an external editor to work with Pico-8 carts. I like opening my whole Pico directory as a project in Atom, which has a built-in package for Lua/Pico-8. This allows me to quickly check out code I’ve written in other carts, and Pico-8 seamlessly loads my external changes when I save in Atom and reload the game in Pico.
Get to know Neko250’s illustrated API reference at GitHub. Great stuff.
Make use of the keyboard shortcuts to export screenshots and gifs. They come out great and the community on Twitter loves to see them. Tag them on #screenshotSaturday with #pico8 for great results and to connect with folks doing awesome Pico-8 work of their own.
If you’re working in iterations or run into issues, don’t hesitate to upload a simple or early version of what you’re doing to the official forum. You can update and version as desired, and in the meantime, you can gather feedback, find community answers, and get the fresh eyes you sometimes need to move forward. Sometimes changes to the API go undocumented or outright hidden, and community users will be invaluable to you when they know to warn you about a certain bug or fill you in on a certain undocumented setting that makes a fix possible for the first time.
Finally, check in on some of the cool activities in the community. Tweet carts are an exceptionally interesting trend, in which a creator uploads the entire code for an animation or even a small game within the length constraints of one tweet, then they’ll include a gif of the code running. You will not BELIEVE what these developers achieve. We could do a whole series of posts where I simply go through incredible tweet carts and make the code readable, explaining what was done and some of the unique optimizations that had to be implemented to meet the requirements. “Demakes” are another great trend, in which a developer picks an existing game and “ports” it to Pico-8. I’m currently working on a port of Rampage, tentatively called “Rampage-8,” and it will almost certainly be central to a number of future posts!
So, what do you think? Are you doing any Pico-8 development? Are you convinced you should try it? Let me know what you think and maybe we’ll discuss it further, or pick an area of Pico-8 game creation and really dig in.
Thanks a ton to those of you who have checked in to see how we’re doing and what’s up with the site and the podcast. We have news!
In an effort to help cover expenses for hosting here and for the podcast, we’ve opened a Patreon account for the community! I want to state right up front, this will not take anything away, nor put any expectation on podcast listeners or site readers. The site will see more regular content and the podcast will approach a more regular schedule as costs get covered. This is simply an opportunity to support what we do, get earlier access to special content, and even get a chance to help us determine what topics to discuss!
If you decide you’re interested in participating in the patron community, there will be a variety of ways to do it. Here are the tiers we’re starting with, we’re bound to add to these and modify as we get acclimated.
And finally, let’s look at the goals we’ve set:
So again, no pressure on anyone, this initiative is just intended to provide a way forward and potentially allow us to tackle some things we’ve wanted to do for a long time. We’ll get there when the time is right. Feel free to check out the Patreon page any time to see changes and updates, or to see how we’re stacking up against our goals. We’ll provide updates from time to time. New content, new opportunities, everyone wins!
Let us know if there are other tiers or benefits you’d like to see, or what goals you’d like to see added. This is your community too!