Things are really coming together. Through iterations using our revolutionary methodology for game development, we finally have a product we’re ready to test.
Is it done? Not even close. It has a few bits and pieces of a game, but we have bigger plans which will take much longer to iron out.
What is is ready for is a stress test. It’s sort of like taking a car you just built to the grocery store first before embarking on an 8-hour trip to Canada. You just want to make sure things are working right before you start adding layer upon layer of features and enhancements to your game.
So, last week we did one! How did it go? Well, let’s talk about that.
What we did well
We tested the crap out of it prior to releasing it to the testers
At first, we thought we were ready planned to test a week in advance; however, due to schedule conflicts, it wasn’t going to happen. We ended up setting it three weeks ahead to maximize the amount of people who would join and thanked ourselves later for doing it.
Every day we found a new bug. Some small, some big, and some very big. In one instance, our game was crashing every 15 minutes due to a memory leak that would create 20+ materials on the client and server every second. This was found two days before we were set to test and would have made our two-hour testing session a nightmare otherwise.
Set a goal for the testing session
We knew networking was going be a challenge from the beginning. Game networking is hard. It can easily creates three times more code (and problems) than creating a single player game.
Our game is meant to played over the network and it’s a huge part of what will make this game successful. It’s a core piece of the puzzle that you just can’t test by yourself. This was our goal for the testing session. Does this game crawl when people play it online? Does our lag compensation algorithm work? Do people jerk around constantly?
Set your goal, gather what you need, and move on. It’s a bit too early to label this game as “fun”, so don’t get too discouraged into what players are feeling at this point.
This game has spent that last year as a part-time adventure between two brothers. While, that does seem like a long time, when it comes to game development, it’s pretty short. The level of understanding to take on this project is ambitious.
What does it take to make a game like this? You’ll need to know: Unity, modelling, animating, programming, game design, networking, level design, sound, among many other smaller tasks to come together. It’s been a long road and this is the first time others will get to see and use your creation.
Don’t expect magic and don’t let your testers think there will be magic. As I said at the beginning of the post, I fully expected to have to quit 5 minutes into the session because people we’re unable to connect to our server.
The funny thing about programming bugs is sometimes they are very difficult to reproduce. You’ll get hints of the problem as they show up, but it’s not always inherently clear what’s the issue. It’s sort of like a treasure hunt. Having a visual record of what occurred during the game is a great way to figuring out the problem. Do it.
Marketing. Seriously. Marketing. Truth be told, I hate marketing, but it’s a piece of game development that is often under emphasized, mainly due to most (myself included) indie developers are just that, indie developers. Objective A is we program, we art, we create. Showing off creations is usually a secondary thought as it typically sucks away time from accomplishing Objective A.
But at the end of the day, people need to know what you’re doing. When creating games are so easy and the market is saturated with content, it’s very difficult to show people your dream game.
On that note, it’s time to continue onto Objective A for the day. Part 2 continues next week, have a wonderful weekend Colonites!
How would you like to consume this information? I’m curious if this information would be faster to produce and more enjoyable to consume if I used video. Let me know in the comments!