As part of the celebration of our one-year anniversary, we thought we'd take a look at the kinds of articles we plan to commission in the next 12 months. Internally, we've been debating the merits of one kind of article over another, who our readers are and who we should most often target, and what exactly is it about Gamedevtuts+ that we love so much.
Our Mission Statement:
To publish future-proof articles that help beginner-to-intermediate game developers hone their craft. Every past tutorial you can read on Gamedevtuts+ should be something we'd be happy to publish today.
Gamedevtuts+ Content: What We Publish
These are the attitudes we've been using to run Gamedevtuts+ since we launched it (although we have tweaked them continually in the meantime).
What Is "Gamedev"?
The crucial role - not necessarily most important, but crucial - in game development is implementation. Great art and sound without interactivity is not a game, but a game can be made without any art or sound.
So we defining "gamedev", for our purposes, as (a) coming up with rules, theme, mechanics, aesthetics, etc. and (b) implementing them, adding interactivity.
It does not involve actually creating the art and sound, so we won't do tutorials about drawing characters in Illustrator or making music in Logic Pro - our sister Tuts+ sites already cover that nicely, anyway.
At the same time, it does not involve getting into deep detail on programming or on using specific languages; that's not our focus.
It can cover business (PR, marketing, legal, etc.) and finding people that can create art and sound.
This is a great article that gives an introductory overview of pretty much everything: How to Be an Indie Game Developer, by Mode 7 Games.
This above all helps to define our audience, too - for instance we're not aimed at those who create sprites in Illustrator or music in Logic Pro.
Tuts+ and Envato generally target freelancers, contractors, small business workers, and the like; we do the same at Gamedevtuts+. Our posts are aimed at freelance game developers, indies, contractors, and small studios. We don't write specifically for AAA console game developers - though of course they may enjoy our content too, and they're welcome to write for us!
Beginner, Intermediate, Advanced
We split our audience into three broad groups, based on their experience:
Beginners have never made a game. However, we can't assume anything else about them - for instance, some might be brilliant programmers that have worked in software for ten years, while others might have no programming experience at all.
Intermediates have made a full game before, or maybe worked on several. It's safe to assume that they have a basic competency in one or more programming tools or languages - could be advanced Game Maker scripting, could be Unity, could be XNA... anything beyond just dragging and dropping - and so don't need to have their hands held when discussing code. They know where to find information about their tool of choice: the docs, forums, Stack Overflow, reference books, and so on.
Advanced readers have made or worked on a range of games, at least some of which were successful, and therefore have a lot of experience. When a beginner or intermediate game developer asks, "How do I make an MMORPG?" the answer is, "You don't." - but that's not the case for advanced readers.
Recently, we've noticed that there's a distinct gap between Beginner and Intermediate, and this might be large enough to let some gamedevs slip through the cracks - those who have gaps in their skills, and represent the largest demographic of gamedevs, but wouldn't consider themselves beginners. Since we don't tend to publish many Advanced tutorials, perhaps it's time we redefined these groups: Intermediate tutorials will be recategorized as Advanced, giving us room to fit new Intermediate tutorials in that gap.
How We Make Our Articles Future-Proof
We've taken a controversial approach to the site: our articles are platform-agnostic. At times this has caused readers to question why we've neglected their tool, engine, or language of choice.
Personally, I too have occasionally pushed towards more old fashioned (quickly obsoleted) platform- or language-specific articles, but I wholeheartedly agree that they are a poor choice when thinking of long term benefits.
A Thought Experiment
It's handy to do a thought experiment: if we'd launched Gamedevtuts+ a decade ago, without a platform-agnostic approach, what situation would we be in now?
- We'd have Flash-specific tutorials, some of which would be in AS2 and now obsolete, and although most of them would still be relevant (AS3 was around back then, after all) many would be starting to show their age (no Stage3D, for example).
- We'd have a few Unity-specific tutorials, some of which would be out of date (for example, Unity 2 and 3 techniques don't all apply to Unity 4).
- We'd have HTML4 and HTML5 tutorials, many of which would teach old methods (using DOM sprites instead of canvas) or use old libraries, and therefore not be as useful as they could be.
...and so on. We'd also have many articles on topics like business and aesthetics which would stay in date, but we'd find that many of our platform-specific tutorials would either be less relevant to readers, or would even be teaching outdated practices.
Other Problems Include...
There's the danger that we'd become too closely associated with a few particular platforms, potentially alienating our readers if we tried to branch out.
If all our tutorials were platform-specific, we'd risk cutting out readers unnecessarily. There's no reason that a Java developer can't understand an A* pathfinding tutorial written in AS3, unless it's too AS3-specific.
Platform-specific tutorials can often be very "paint-by-numbers", if the writer and editor are not careful; this can skew the audience of the site towards the less skilled (or less dedicated).
How Can We Teach Specifics, Then?
We can, roughly, split our implementation tutorials into these broad categories:
"How to Build a Game With a Particular Platform"
These are a huge investment: for a really impressive demo, they need good artwork, good sound, and solid code all-round. And once the tutorial's written, it can be a huge pain to update it - imagine trying to update a blit-based AS3 tutorial to use Stage3D.
And yet... these are probably what readers expect from a gamedev tutorial, and have huge benefits for learning (as there are so many subtleties when putting a whole game together that are lost when merely learning about the individual components).
We've done this with our beginner "From Scratch" tutorials - which all use point-and-click, code-free gamedev platforms - but never with an intermediate gamedev platform that requires coding, like Unity or HTML5.
That's about to change. We're going to start publishing cross-platform tutorials, starting with Michael Hoffman's Geometry Wars-based game. We'll publish an XNA-specific version of the tutorial, and then a Flash-specific version, and then a DirectX-specific version, and so on. Each will be designed to be modular, so that they can be updated as the underlying platforms change in the future.
We're going to keep these platform-agnostic - but they can still be written in a specific language, with demos and source code compiled for a specific platform, as long as they are platform-agnostic enough that devs familiar with other platforms can understand them. For example: a tutorial about A* pathfinding should not tell you to "Open FlashDevelop and click File > New to create a new project".
However, we'd like to start publishing tutorials explaining how to implement some of these concepts with a particular platform. For instance, maybe we'll commission a post based on Jamie Fristrom's excellent swinging physics tutorial, explaining exactly how to code it in Unity, or UDK, or some other appropriate platform.
Tutorials About Using a Particular Platform
Sometimes, the incredibly powerful tools and software we use to make games can be a little complicated. Who'd have guessed?
We want to help gamedevs out by providing tutorials that explain how to fix particular pain points in these tools, or how to use dialogs that perhaps aren't yet as user-friendly as they might be. Thing is, these aspects tend to get fixed pretty quickly, which means the associated tutorials will become out of date, and we don't want outdated information on this site.
We're going to experiment with these kinds of tutorials, but only for problems that are true pain points and that have not been explained elsewhere already. We'll have to figure out how to keep the content separate from everything else once it becomes obsolete!
The future looks bright for Gamedevtuts+. Though I expect that we'll constantly shift our priorities to match those of our readers as well as the constant innovation in the industry, my hope is that over the long term our mission statement will help us stay relevant and immediately useful for your current and future game projects.
By focusing on the higher level needs of gamedevs, the concepts that hold true across genres and platforms, and the emerging trends of game software development, business and production, we plan to create tutorials and articles that stand the test of time.
There will be times we need to take on the tech of the day - to look into the cutting edge trends and tools of this year. However, in general we hope to deliver content that is future-proof to one degree or another.
After all, an in-depth analysis of the level design pacing or movement physics behind Super Mario Bros. is still applicable today and is of immediate use to many gamedevs right now. Conversely, a tutorial on memory management in assembly language on the 6502 CPU used to power the NES version of the game would today be of interest only for historical purposes.
In summary: future-proof, beginner-to-intermediate level tutorials and articles covering the design, implementation, and business of games.
What do you think of these policies? How do you feel about our current direction? I'd love to hear your thoughts on the matter. After all, there are no right or wrong answers here. I'd place great value on your opinions, even if we disagree. Please feel warmly welcomed to leave a comment.