So, a few weeks ago I was lucky enough to get a review code of Riverhill Trials directly from the creator, personally. I had no idea what kind of game I was getting myself into, I just knew that it was their first ever game.
I’ll be real with you guys, it shows. It really shows- there’s a distinct lack of polish, the triggers don’t work half the time, the voice acting is amateurish to the point of urksome, and the game just plain became unplayable about 30 minutes in when some obstacles didn’t load properly.
So, I was left with a choice: do I review this game like I would any other, just like I would review a studio-made game? Certainly not, it’d just get an F grade. No use.
Instead, I opted to appreciate it for what it is: somewhere, somebody has taken their first steps into the creative medium of games. That’s fantastic, and even though I as a critic would shit all over the game, I as a game maker know how hard it is to get to this point, and am instead filled with pride. So, let’s explore what it means to make your first game.
Little background on my perspective here: I’m a student of a bachelor’s degree which isn’t strictly about games, but does bring together a lot of that crowd. There’s a lot of big end-of-year projects, and during said projects, a lot of us choose to make games. I also (If the fact that I have a series of articles called “Will’s armchair designer” didn’t tip you off) Study the medium of games from a design perspective, and writing these articles are half the fun of the medium for me.
So, making your first game. The best piece of advice I was ever given is “Fail faster”. When you make your first attempt at learning a new skill, your job is never to make a masterpiece. You’d never pick up a paintbrush for the first time and immediately try and paint like Michelangelo, would you? No, your first painting, put against the work of professionals, will look awful- but that’s why you try a second, a third, and over and over until one day you realise you’re doing great. Games are much the same- you should never sit down at the desk and try and make ‘Super Mario Bros’. It won’t happen. You should expect to fail, and get into the habit of doing it- fail faster each time, and you’ll learn more and more.
Your first time is a learning exercise. Your focus isn’t on making, but on cultivating knowledge. Learn basic code, get familiar with your proprietary engines, etc. Your job is not to ship a product, but instead to make something that works. That is exactly what ‘Riverhill Trials’ is. It’s a simple game with some basic platforming and collectables, with some pleasant background music. Nothing more, nothing less. They failed to make a game like ‘God of War’ or ‘Breath of the Wild’, not even a ‘Stardew Valley’ or a ‘Gone home’. but they made something. They did it. Next time, they can build on that knowledge.
My lecturers put a lot of effort into helping is build portfolios. With good reason, in this industry, it’s very important to get a foot in the door. Meet the right people, shake the right hands, you get the deal. A portfolio isn’t a giant list of all the things you’ve done in your life, it’s a few choice pieces that sell you as an interviewee. Games like ‘Riverhill Trials’ aren’t viable commercial products, but what they are exceptionally good at being are portfolio pieces.
Remember when we talked about failing faster? Well, each failure you make can lead to learning something new. You could consider ‘Riverhill trials’ to be version 1.0. Next time, you’ll be able to make something more interesting, learn your strengths and train your weaknesses. By version 3 or 4, you should have a few pieces that are worthy of the portfolio.
But these pieces must stay small. It is imperative we remember that, especially as one-person teams. The rule of a minimum viable product is essential- we don’t need to waste time on frivolous tasks that get us nowhere. We may set out to make a basic RPG combat system, but end up getting frustrated because we can’t get the flashy attack animations to work. We must always remember our minimum viable products.
MVPs are something that drives a lot of my own management style on university group projects (where I kinda fit naturally into project management.) a lot. We must, as students of the craft both taught and self-taught, learn to let go of the flashy idea we have in our minds. In learning, we must set ourselves clear objectives to achieve- this makes our tasks manageable, but also makes sure that when we achieve something, we’re as proud of it as we deserve to be.
And lastly, management. I left this until last because I really don’t know how planned this project was. Some of the levels feel a little cobbled, but maybe that’s just a sixth sense I’ve developed from making my own prototypes. But the advice I once recieved is that setting goals gets shit done. Period. Take your best estimate, and try and hit it.
You will not hit it. Even at the AAA level, everything is always 50% slower and 50% pricier than expected. Always. Without fail. But you must do it anyways. Spending three weeks trying to get an animation bug fixed is nowhere near as productive as the rest of the stuff you might want to do instead. Manage your projects, and in the end you’ll come out with something you’re proud of, even if it’s a little rough around the edges.
To conclude, ‘Riverhill trials’ makes me proud of its creator. Not because it is a masterpiece, not because it pushes the medium, but because I know how hard it is to get this far. The takeaway, at every turn, it this: you’ve made the first steps, keep making them. Never give up, and when you’re down in the dumps and feel there’s an obstacle you can’t overcome, reach out for help. Watch tutorials, and if you’re still stuck contact the person who made them. Find alternative ways to solve problems. Use asset store code and models if you need to- if there’s a problem you can’t fix, there’s someone who can teach you.
And, above all. hold your head high at every turn. You the shit.