Two weeks ago, Jorge (@pctroll) approached and offered me the opportunity to be part of a colloquium held on my university, as part of the Computer Engineering Week. His idea was to speak about videogame development using Unity. If you want to take a look at what we talked about or you a newcomer into the gamedev world, then this is a post for you.
We started working on what would be the structure of the presentation. What should we mention? What should we trim? We are, by any means, neither professionals nor experts on the subject, as we started a couple of years ago working (not very throughly, I have to admit) making games. So we decided to talk about our experience so far, what we have learned, and give a glimpse to the newcomers (as most, if not all, of the attendees were).
The presentation represented a challenge for me, since I had to resync and update my thoughts regarding gamedev, but I must say it ended being a wonderful experience.
I’m writing this post as a summary for everybody who could not attend or who doesn’t speak spanish.
The structure was very simple:
Introduction to gamedev
What are videogames?
We talked about the two sides of the coin. Videogames are not only a real time simulation system or a rule-based system with clear objectives and win/failure conditions, but also an artistic medium that can be used to express an idea or spread a message (I will not get any deeper on whether videogames are art or not, but I’ll love to write about it in the future).
Also, we mentioned the (main) areas of development: Programming, Design, Art, Narrative, Sound and Playtesting. There are many more, but we consider those the main ones. And we made emphasis on three important things:
- Gamer != Game Developer: liking to play videogames doesn’t mean liking developing them.
- Game Programmer != Game Designer: most programmers start creating games without fully acknowledging the importance of a solid ground on game design.
- Playtesting is a good way to start in the industry and a must when developing games (or even general software).
As we live in Venezuela, we also talked about the current situation regarding videogames in our country. What are the laws, the working market, events (specially the Global Game Jam and the Caracas Game Jam) and indie groups.
Also, what are the knowledge and skills needed to develop games?
- For designers: psychology, logic, art (criticism), basic programming skills, etc.
- For programmers: algorithms, scripting (desirable), Object-oriented programming (necessary), C/C++ (invaluable).
- For both: mathematics, physic, communication, prototyping, writing and spelling.
Lastly, we talked about the common misconceptions and fears:
- “I don’t know how to code“: the solution is the learn, there’s plenty of free and accessible material on the Internet, the only requisite is a computer, internet access and the time and will to learn.
- “I’m a programmer, not an artist“: we consider ourselves part of this group. The good news is that there’s many free or creative common assets, as well as people in the Internet willing to work on a game, artists that don’t know how to code.
- “I’m a student (therefore I’ve no money)“: many free and opensource tools available. Also, some paid software can be obtained for free (or with some discount) if you’re a student.
- “I haven’t made a game yet, but I will make the next Super Zelda Bros: White Ops++”: gamedev is no trivial work and more than often it’ll be a pretty hard job. The trick is to start simple and begin gaining experience.
- “<Insert random excuse here>“: initiatives and startups, such as One Game A Month, show how it’s more a problem attitude than aptitude. As it’s said in one of my favorite books, Rework: “When you want something bad enough, you make the time—regardless of your other obligations. The truth is most people just don’t want it bad enough. Then they protect their ego with the excuse of time.”
The real world
After such an introduction, the next topic was the so called “Real World”. First off, we presented the two realities in gamedev: the AAA industry and the Indie movement.
Afterwards, we talked about the trade-off between the real world and the academy.
- Things that you won’t learn in the real world:
- The study of basic and advance algorithms.
- The state of the art.
- Perfection: you always aim for the optimal solution. As the motto of LEGO says: “Only the best is good enough.”
- Things that you won’t learn in the academy:
- Problem solving: not the kind of problems you address in the academy, but rather the fact that projects not only have deadlines but budgets as well. You can’t spend your entire time searching for perfection if it will cost you development time and resources. Many times, the simple solutions serve as well as (or even better than) the “right” ones. We must learn to do “smart hardcode“; how so? do any tricks as good as can be done with the current resources and time.
- Collaboration: the academy promotes the individual’s own work. Copy something (even if it has no copyright) and you’ll be called a cheater. In the real world there’s a phrase for that: “don’t reinvent the wheel“. If something was done by someone else, and you can freely use it, then use it. Your most precious resource is time, there’s no need to solve something that has already been solved. There’s plenty of Internet communities and forums willing to help you.
And, of course, what are the gamedev tools and levels?
- Low level (Blood, sweat and tears): if you go this way, you’re gonna have a bad time. Here we use libraries such as SDL and GLUT. We have the power and the duty to make things work. The equivalent of coding in C.
- Mid level (Sweat and tears): the use of frameworks like XNA (and MonoGame), PyGame, Enchant.js and Flixel that greatly save use from getting our hands dirty with filthy code. Like coding with Java or C#.
- High level (Sweat): engines that do most of the work. Popular examples are Unity, UDK and Source. Like coding using an IDE.
- Nyancat level (ice-cream and ponycorns): tools that greatly help the gamedev process, at the cost of power. GameMaker and RPGMaker are great examples. Yes, you can make great games in both of them, but they have their limits. This is like coding using a scripting language, like Ruby. Tools in this level are great for prototyping.
For a list of popular tools and engines, check this.
We also gave a very brief introduction of Unity (as we had limited time), but I’ll not dwell deeper into that. However, I did talk about this post.
Words of Advice
We ended the colloquium with some tips:
- Start a blog: this way you can share your experience and keep record of your work.
- Work on you portfolio: possibly your biggest companion. Your portfolio is a tangible proof of your commitment and skills. A blog is a good way to start your portfolio.
- Collaborate in a community: you’ll learn from others and others from you. This is a place for healthy competition and collaboration.
- Organized: your main enemy is the disorder, a good project has a good management. Tools like Trello are great for this.
- Up-to-date: everything related to computers is constantly evolving. The tools you might use now will most likely be useless a couple of hours later. Learn how to design and craft good software, rather than how to use a tool.
- Curious: a good way to stay awake is to constantly challenge yourself even further.
- Brainstorm: many solutions are always better than single solutions.
- Code: practice makes perfect.
- Rest and Live: probably the most important tip of them all. “All work and no play makes Jack a dull boy.” Ideas and inspiration usually come from the outside world, not inside your coding shelter. Life experiences are invaluable. Quoting Rework again: “Working more doesn’t mean you care more or get more done. It just means you work more. […] Workaholics aren’t heroes. They don’t save the day, they just use it up. The real hero is already home because he/she figured out a faster way to get things done.”
And remember that…
- … you’re not alone, there’s plenty of people who are or were in your same exact situation.
- … videogames are like any other software, a product of an iterative process. No game was done right during the first try.
- … what’s not started today cannot be completed tomorrow.
We are cuccos, we are chocobos, we are legion.
I’ll be working on the translation of the presentation, although I’ve written most of all in this post. For those who would like to check the original presentation (in spanish), check this link.
For those wondering why the title of the post and the colloquium, there’s a word (in Venezuela, at least) for the standard nerd: gallo (rooster).