Hello Hacker Noon Community!
I’m JP, one of the founders of Insular Games. Welcome to our dev blog, thanks for stopping by!
I’ve seen quite a few dev blogs online throughout the years; most of them with updates about their upcoming games, or discussing some aspects of them (design, programming, art, etc.).
Before deciding to go indie, I did quite a lot of research online. It was not a decision I took lightly. And while I did find a lot of information, it was really scattered.
So I decided to try to compile things I learned so far throughout this “indie adventure” in this dev blog. I will include my past experiences, things I read about while doing research, or discovered the hard way while working on our game, Gravitators.
My main objective with the blog is to pass some of this the knowledge forward, as many things I learned were previously uploaded by someone for free. It’s the least I can do for the next generation of indies.
Sometimes journalists and outsiders tend to focus on the bad aspects of our industry (OT, working conditions, etc.), but something that is never mentioned is the "camaraderie" between devs.
It is probably one of the most positive aspects of our industry: while in reality we are actually competing in quite a harsh and saturated market, we still help each other out a lot. So this blog will be our little contribution to that.
On a side note, I’ve also read that writing a blog can increase traffic to your website or visibility to your game. So I guess we'll test that out too. I actually posted the blog on Reddit the other day but didn't get views. Then I got busy launching our Demo for the Steam Festival, and just yesterday I saw a "Call to Indies" from Limarc Ambalina from Hacker Noon, for us to start writing on this site. I took it as a sign I should be writing the blog here instead, so here we are.
Disclaimer 1: the information I’ll be writing in the blog entries comes from my own personal experience, both past and present, and knowledge I accumulated from books or articles. But what worked for me might not work well for you. So: take what you think it’s useful, and feel free to ignore the rest.
Disclaimer 2: In future blog entries, I will probably mention several things about Gravitators mechanics or story. If you’re interested in the game, I suggest you play it first (currently in development, demo will release soon though). That way you will avoid any potential spoiler I might write here in the blog (I’ll try to avoid it or at least warn about it).
With that clear, for this first blog entry I’ll give the first piece of advice to anyone looking to start working on their own company/game: Read as much as you can!
In 2020, we’re lucky enough to be working in a rather mature field (guys in the 80s were basically experimenting). Today there are tons of resources that can help you develop your video game idea and/or set up your own video game company. On top of that, material can be easily reached online on Youtube, e-learning videos, or other e-formats (amazon, google books, etc.).
Location isn’t important anymore in order to acquire knowledge in our industry. There’s no reason you shouldn’t take advantage of other developers knowledge.
The first thing you (and your potential group) need to do before starting is to do a self and honest evaluation. What are the things that you are good at? And what are the things you have no idea about?
I’ve met some very talented people in the past that could design, do 2D/3D art and code. But even these people (who are more an exception than a norm) might still miss some key knowledge or skills that are required to put a successful game on the market. For example: Project Management, Sound Design (both sound effects and soundtrack composition), Marketing, Budgeting, Legal/Accountancy, etc.
Most indies will notice when working on their first project that positions and task divisions tend to get blurry/fuzzy sometimes. And that's OK. You will most certainly need to get out of your comfort zone, and do and learn a whole bunch of new things that are completely different from your past work experience. If none of you is not comfortable with that, you are going to be needing a much larger team. On the other hand, if your team’s experience is enough to cover all required items, that’s great! You’ll have a lot of work to do but you’ll certainly have it easier than most teams out there.
Our team consisted in:
All of our experience, however, was doing Mobile Games. But we wanted to do the jump towards the PC (because even though I had worked in Mobile Games, I’ve always been more of a PC player).
You can see from the team composition that we didn’t have an experienced Game Designer, a 3D Artist, or a Sound Designer (a couple of us have some experience with music composition, but not at professional level). I decided to take the responsibilities for the Game Designer, as I was the one with the game proposal. As Gravitators was 2D, we didn’t need a 3D Artist for this project. And Sound Design is the easiest job to outsource, so it wasn’t a big deal not to have one on the team.
I've always been comfortable providing feedback on games and deciding when something is well implemented or not. However, starting a game design from scratch is a totally different challenge. I also worked exclusively on the “development” side of games, so my experience in marketing and branding was zero.
That’s why I decided to focus most of my reading on Game Design first, and then on Marketing. We also decided to outsource Sound Design.
You should do the same. Focus on learning skills that you can improve or you think you are very interested in or want to learn, and check about outsourcing the ones that look too hard to do. It's very important to analyze time (to learn) vs cost (to outsource) at the beginning of your project.
I’m sure that most developers and players have imagined their own "dream game". Except some rare occasions, all these games will almost always be a combination of mechanics and art style from various existing games, old or new.
So with your dream game idea in mind, I suggest you read and learn, and use that new knowledge to polish your game design, find the most suitable art style, code it the most efficient way (which includes choosing the game engine too) and find your audience. I’ll be going into more detail on some of this stuff in later blog entries.
For now, I’d like to recommend the following books or courses, which have proven useful to me one way or another:
The Art of Game Design: A Book of Lenses (2nd edition), by Jesse Schell. This is an excellent introductory book for anyone that wants to design a game, but it still provides very useful insights that can help even experienced designers. You will find a lot of information on Game Design, seen from every possible angle you can imagine. If you’ll only get 1 Game Design book, get this one.
GameDev.tv. These guys are amazing. You can basically learn most of the things required to develop a game here: Coding (Unity / C#, Unreal / C++), 3D Art with Blender, 2D Art, VR, etc. I’ve personally taken the Unity course a few years ago (I also got the 3D Art course but haven’t had the time/need to do it yet), and found their coding teaching method fantastic: they explain the topic, and give you a task that’s slightly more complex for you to practice.
You pause the video and do it, and then you continue the video to see the resolution. If you follow this method (instead of continuing the video and just see the solutions), you will learn a lot. BTW I actually found them through www.udemy.com, which every once in a while gives HUGE discounts in all their courses, including theirs. My advice is to wait for their store sales and get as many courses as you need from these guys.
The Indie Game Developer Handbook, by Richard Hill-Whittall. This book goes into extensive detail of everything that a Game Developer might need. Being from 2015, it’s a bit outdated in some info, but most of the book is still useful if you never worked in the industry or even you’ve always worked with huge teams (these teams have all tasks distributed so much that everyone is a specialist of a very small part of the game development).
So you’ll be reading about different game engines, software, stages in game, platforms, presskit, marketing, etc. etc. It’s well organized, and it even includes some interviews to different studios (both successful and not so much, which is equally useful).
100 Principles of Game Design, by Wendy Despain. What I like about this book is that it explains concepts of Game Design but seen more from a theory/academic point of view. Some of the concepts explained here are similar to Jesse Schell’s book, but they are more to-the-point (which can be good or bad, depending on what you’re looking for). It’s still worth a read.
Game Design: Theory and Practice, by Richard Rouse III. This book is a bit old (you’ll notice right away when you see the “new” games it mentions), but I still found a lot of useful ideas. And it also includes some cool interviews to industry legends, which were my favorite parts.
With some exceptions, I don't normally work on the art for the game, but I still found the following books very interesting:
If you are going indie, there's a big chance you don't have someone with marketing experience or 100% dedicated to it. Marketing is an absolute must today, with the indie market being rather saturated. Games today must find their audience or risk failure.
A Practical Guide to Indie Game Marketing, by Joel Dreskin. A book written specifically for indie developers that have zero experience on Marketing. Reading this book won’t guarantee that you’ll be able to market your game properly and efficiently, but you’ll still be better off than if you haven’t read it.
Market Your Indie Game Like A Pro: Techniques Beyond App Store Optimization, by Amol Wagh.
Depending on your game, it can go from non-existent or an afterthought, to a novel-like story, with many main and secondary characters, and layers upon layers of complexity.
While our medium works radically different vs other mediums (as players normally have control of their avatar's actions), it's still very important to know how other media builds stories, so you don't fall short if you need to have one.
Story Engineering, by Larry Brooks. This book explains very well how stories are structured and organized. It has a somewhat slow start, but it’s totally worth it. If your game has a heavy focus on story, you should definitely give it a read.
Story: Substance, Structure, Style and the Principles of Screenwriting, by Robert McKee. This book is aimed at screenwriters, but the content absolutely applies to novels or games. It's one of the most famous books on the subject.
The Lean Startup, by Eric Ries. You might have heard of this one. While more oriented towards innovative products (meaning, products and services that are more on the experimental side), the ideas in the book are very different and counter-intuitive vs “normal” business strategies.
It also gives a lot of insight and examples of companies that started with a fixed idea of a product, but then changed it over time for different reasons. Which sounds exactly as the evolution of many games. Mind however that many ideas of this book are currently contested, so I suggest you probably read some criticisms after you finish with the book.
While I've added links to all book suggestions, there are other online stores where you might get them for a cheaper price. Browse around. I found that archive.org sometimes had books I was looking for (although I’m not entirely sure if they are legally uploaded there).
I’ve also read other books but I thought the list above was a good, varied summary.
There are countless articles, videos and tutorials online too. Whatever topic you think you should learn, do search online and learn as much as you can about it. Even better if you do it before you start working on your game. They will help you structure the game idea better in your head, and save you time.
Speaking of time, it is hard sometimes to actually find the time to read and learn new things, especially if you still have a daily job or other responsibilities (parenting, formal studies, etc.).
Consider it part of the job. Try to schedule yourself time to read, the same way you do to work on tasks for the game. Even 1-2 hours a week is better than nothing.
Replace some leisure activities with learning. This means: reduce some of the time you use to play video games, watch TV shows or movies, read fiction books or newspapers, or whatever other activity that isn't mandatory on your daily life.
The easiest for me was to drop any fiction reading at night (which I used to do). This gave me 30-45 minutes to learn something new (usually I read a game design related book). Also, by reducing the amount of days I watch a TV show or a movie, I get 2 extra hours each time. As long as the learning topic is interesting for you, this shouldn't feel like a chore.
This brings me to the last advice of today: Get an e-book reader. It’s probably the best purchase you’ll do. I was hesitant for years, as I considered myself more of a “traditional reader”, and thought that I’d be missing the feeling of paper in my hands, and that the device would feel weird to hold or read. I stand corrected now.
I was absolutely amazed when I realized I didn’t even have an adjustment period. I loved the feeling immediately after I started reading: you don’t need to turn the lamp on at night (bothering your significant other). It’s very lightweight to hold on your hand for long periods of time.
You can download all your books immediately (no more shipments nor lack of availability if you’re in a foreign country like us), and the greatest feature of all: you can highlight all the important things you read that you might need later, or leave written notes. This means that whenever you need the info, you can easily go back to all your highlights/notes and jump back to the juicy parts right away.
Consider all the time you spend learning and doing research as an investment. It will save you time and money in the end.
That should be all for the first blog entry, hope it wasn’t too long for an intro. Stay tuned for the next one.