I do however understand that mentality of "addressing faults" as a way to get your point across that their game needs work. I recently got done playing someone's alpha build of their game and it needed a lot of work. It just felt like a generic 2D hack-n-slash platformer that was glitchy and I had to be honest about it and say "I probably wouldn't play this game right now even if you fixed the bugs I mentioned. It's way too basic and got boring after half an hour."
People have criticized my crappy game design decisions a lot, and that has made me a better programmer/designer long-term. How?
1. If something was unoptimized/poorly coded, it forced me find a brand new solution with a better practice that made the coding practice easier for myself.
2. After the 1st hurdle it actually helped me realize the design of my game was lackluster. "Anybody can make a game, but can you make it a fun one?" Is the age old question many, including myself, have a hard time answering. And although fun is subjective, in the context of gaming, there are mechanics that objectively make it more fun within the context of your game.
Take for instance a game like Arkanoid/Breakout. What is the "fun" in that game? It's finishing the level by hitting a fast-moving ball with a paddle. The high-octane action is what keeps you going as the ball picks up speed and you rack huge point multipliers for doing sick combos. Now whether or not that was the game was intended to be played is another issue, but people, for the most part, like this fast-paced gameplay loop which rewards execution and reaction time.
Now take out what most people think is objectively "fun" and throw it out the window. Imagine an Arkanoid where the ball moves slow all the time, there was no strategy, and you basically just looped the level ad nauseum with no variation in style. That and maybe the paddle move in the opposite direction instead of the direction you wanted it to.
So I'm making a small guide on this to show what you can do to give good advice to game developers that you playtest their game for.
1. BE HONEST
It could be your friend's/family member's/co-worker's first time making a game, and like all first steps, there's bound to be problems. That said, you should address those problems instead of it ignoring them. It doesn't even have to be anything technical.
Stuff like collision detection, wonky physics and save data not being stored correctly when you save the game is pretty easy to show and explain. But stuff that isn't designed well, probably level design being too large or to small, combat with enemies being boring or tedious, or RPG mechanics - if the game has it - being broken when you level up a certain weapon to maximum in a short amount of power and it just dominates the game. Stuff like that is way more important long-term. Even though that isn't what they envisioned for their game to be played like, the interpretation between dev to player is similar to author and reader; you can't stop someone from seeing things the way they like it.
Of course games and books are different. You can't stop the author from doing what he/she wants with his/her characters, nor what he/she wants to do with the story. That book is still bound to find an audience somewhere. Games are the same way too mechanically wise, but when something is objectively not good for the more interesting parts of the game, a lot of people aren't going to like it.
Which is why I move on to my second point
2. Highlight what's cool about the game and push that design
Say you're playtesting a game. It probably has a few cool mechanics that you like. The problem is that all the mechanics might not fit together.
Remember 3v3 Pokemon battles in some of the later generations? Dual battles were already a huge load in terms of strategy enough, but 3v3 just made it overkill. Which is why Gamefreak brought it down to 2v2 in later iterations. Instead of trying to polish 2v2, they just added a meaningless extra layer people didn't have a problem with.
A game with very few yet polished mechanics is more remembered than a game that is bloated with features that are way too complex which only the most dedicated of fanbases will stick with.
So if you play a game with a good design, elaborate on how it could be better.
Say you like the gun switch combos in an FPS. Don't say nothing, say that you want faster gun switching between the sniper rifle and rocket launcher.
If there are too many redundant weapon variations like a chaingun and a mini-chaingun which does less damage, then that should be taken out.
And that's all I have to say on the matter for now. I hope this helps fellow playtesters and indie devs out.
---
Hey if you like this blog and want to support my game dev projects or are feeling generous, you can do so here through my Paypal Donation Link, Anything helps, even a $1.
If you'd also like to support but want to get something out of it, I recommend you getting this amazing book by A.T. Chamillard through my Amazon Affiliates link!
You can learn how to make games in MonoGame, the best 2D/3D open source framework that has made many popular games like Celeste and Streets of Rage 4. You can get it by clicking here.
In the meantime, stay safe as always and have a good one everybody!
No comments:
Post a Comment