Welcome to Underdev’d, where I talk about developing games when you don’t really know how to develop games. As Curtis the Inverted mentioned about a month ago, we’re getting band back together. We’ve been working on projects until now, but we haven’t been sharing anything. That needs to change.
A few months ago, I gave up on Chethmatch, the game idea I was working on for a while. You can see the first version on Itch. It’s striving to be mediocre, and fails badly, but with about 12 downloads to date, it’s probably our most popular title so far.
Chethmatch, as you probably don’t know, was basically a modern rip of Archon, but with a Street Fighter-esque combat system instead. The fighting system was completely physics based, and when two pieces came together to fight, as people mashed the controllers they would just kinda float around in circles chasing each other, never connecting. I decided to start over, which physics only for root motion and animation for all the moves. I worked on it for a few months, until I realized there was no way for me to get these systems to work together.
I mean these systems *can* work together, but there’s no way for *me* to get them to work together. At least not now.
So I gave up. I put the game down and just took a break for a while. This is what I learned.
Admitting you can’t do something isn’t really a bad thing. It’s just being realistic. If you gave it the ol’ college try, and it doesn’t work, and you can’t find anyone to help you make it work, then just step back, and walk away.
Giving up really gives you a good idea of how far your skills have progressed, and what you need to look into in the future. For me, I need to look into physics and animation more, but maybe not both at the same time, and maybe not as complicated of an implementation.
You don’t have to give up forever. Maybe some day I’ll go back some day when I’ve learned more.
It’s okay not to have a game after working on making games for the last four years, even if you want to submit to BIC fest and BitSummit, but can’t, and kinda look like a hanger-on-dork at Haeundae/Kamogawa every year. It’s okay. Kinda.
So yeah. Things are better. Working on a new game now. It’s more story based, and it builds on things I know a bit about, like linguistics, and hating. I hope to have something to show in a few months.
Until then, know that we’re just chugging along, making things. Curtis is streaming and reviewing games and working on stuff, and I’m just working on stuff. More soonish. 🙂
As alluded to in the last Game Dev with the Underdev’d, here at Burpy Fresh, we love writing about games, but we also love making them. We’re proud to announce the alpha version of our very first game, Controller Clash. Now available on itch.io for Mac. (Windows etc coming soon, we had to rush to get something out for BitSummit!*) It’s Almost Fun (TM)!
Controller Clash is more of a exercise in learning C# and the Unity interface than making an actual marketable game. In reality very little about this project makes it in any way commercially viable. As our tag line says above, it’s “Almost Fun (TM)!” In this post, I’ll explain about the game, and more importantly the problems I faced, and how I overcame (read: blindly struggled my way through) them. Maybe someone starting out will find this useful, or perhaps more advanced people will be able to remember how to explain issues to us n00bs again.
About the Game
Controller Clash is a four player local multiplayer game where bases shaped like controller buttons battle for the control of Controllerscape (TM??). Each player claims a controller button base. Pressing their own button shields themselves. Pressing any of the other face buttons sends a missile towards the corresponding enemy. Left and right bumpers shimmy your base left and right to dodge some attacks. Using the D-pad, you can compose simple fighter style moves.
That’s about it. You can only do one action at a time, so you can only defend or attack. There’s a cool down timer of one second on each action. Your shield has 10 HP, but if you get hit with your shield down, you die automatically. There’s a lot of politics going on in this game, piss people off and you’ll be outed pretty quick.
Things Learned – Things “Solved” – Face Palmed
What is a GameObject?
A GameObject is an entity that exists in a scene. Holy crap did that take me a while to figure out. GameObjects have either predefined features, or features that you define with code. They can be instantiated, destroyed, turned on, turned off, and basically manipulating them is how you create anything in Unity.
Mind Blown. I should have paid more attention when I learned Java in like 199…umm.. 7?
Honestly, it took me about a year to understand the Unity interface. Don’t get me wrong, I think it’s really good, but it took me a long time to understand certain key factors. In Unity, you need to create scenes, which houses the environment your player will traverse, the camera that will view it, and all of the entities you’d like to have present.
The hardest thing for me to understand was that Unity, as an engine and an interface, was basically a piece of code that executed itself and the rest of your project. When you create a piece of custom code, you need to attach it as a component to something that will be present in the scene upon execution. Many people in tutorials attached their scripts to the camera, which really confused me, as I thought that the camera was executing code somehow. Unity will go through the list of GameObjects and execute what code is there to execute. Really though, the camera is just always present, which is why I guess people do it.
In a similar note I now get why variables need to be public for you to assign values to them in the Unity interface. If they’re not public the Unity code can’t see them due to the way scope works. Again, something completely obvious, yet I didn’t get it for a long long time.
Basically, I’ve been trying to make a game for years, and while I understood that a class was an abstract entity that could be assigned features and behaviour, I didn’t understand the level of recursion and abstraction that was possible. In Controller Clash, there are four players, basically Cross, Triangle, Circle and Square, and they’re all slightly different. They move and throw up their shield the same way, but the moves they can make with their missiles are different. I wrote four different classes, called PlayerCross, PlayerTriangle, PlayerCircle and PlayerSquare and duplicated the code I needed to duplicate in each one. I was worried that at some point I may want to give one player or another an advantage, so I figured duplicating code was the easiest way to do individual manipulations later.
What I didn’t understand was that inheriting MonoBehaviour wasn’t just some text you had to put in the code to make everything work, it’s what you need to do to make sure that your class has all of the methods you need to use in Unity. I didn’t understand that MonoBehaviour was a class that contained the declarations for essential methods such as Awake, which activates as soon as the class loads, Start, which is very similar to Awake, but comes after it, and Update, which activates every frame, basically every tick of the clock in the game. I also didn’t understand that you could make a class that inherited from something other than MonoBehaviour.
So, I created a class called Player, that housed everything needed for each player, and then made PlayerCross etc inherit from Player instead of MonoBehaviour. Player held all the variable declaration and the methods, which PlayerCross etc initialized all the variables, and called methods in the MonoBehaviour Awake, Start, or Update methods. There was still code duplication, but only 40 or so lines as opposed to about 600. Optimization!
How to Handle Translation (The Wrong Way)
If I was more intelligent, I would have set up some sort of data file, like a plist on Apple-based products, and I would have called the text from all three languages in the game on runtime based on the language selection. Instead I created a gameObject that acted as a Game Manager, made a script attached to it that had all the strings in it, plus a public variable for selected language. Every time a text box loaded, the Game Manager was called, and the placeholder text was subbed out at run time, which basically meant I was translating every piece of text in the app as it was being displayed.
Effective? Yes. Cost Effective? I don’t see how it could be.
While I didn’t learn how to do this the right way (some help?), I did learn something crucial. Code first, clean up later. While it’s always advisable to keep code tight and well optimized, at the end of the day, it’s more important to have spaghetti code done than a few neatly written modules that only do half of what you want them to do. People may disagree on this, but I don’t think I would have ever been able to put anything out at all if I didn’t swallow some pride and just hack some mess together.
How to Do Fighter Style Moves – Understanding Update.
Update is a function that is called on every frame, or every tick of the computer clock. What do you do when something, like a fighter-style move that requires multiple things to happen over multiple frames? This took me about four hours to work out.
In the end I made a public iterator variable, and variables called moveOne, moveTwo… etc. There is a method called MoveGenerator that takes a series of inputs and spits out a move based on the input. Right now, all moves involve a single tap on the D-pad followed by a button press. MoveGenerator reads the iterator variable, and if it’s one, it initiates a move if the input is a face button, or it stores the direction of the D-pad pressed as a string in moveOne, and the iterator is incremented.
The trick at this point, which took me, again, four hours to figure out, is to exit the MoveGenerator method, and then re-enter it on the next frame where a button has been pressed, this time the MoveGenerator is looking for a face button. It records any face button press as a string in MoveTwo, and then it determines which move has been selected from a list of moves, initiates that move (an attack or a defensive maneuver, and then it sets the iterator back to one, ready for the next move to start. Any improper input sends the iterator back to one and empties the strings MoveOne and MoveTwo.
This feels right to me. You’re listening every frame for a button press, and when you get it you store it away until you find a combination that makes a move, and then you fire it off. I’m not sure I could think of anything simpler.
I did have a problem initiating animations in update until I understand how flags worked. Basically, I would set an animation to go upon some condition, and then because update was called every frame, often several animations would occur when there should have been just one. By having a bool that I could turn on when an animation was happening, and then off when it stopped, I ensured that there was only one animation at a time… which brings up…
Why You Need an Instantiated GameManager
If you have anything you need Unity to carry with it throughout the whole game, you need a GameManager. Basically, make an empty gameObject, call it GameManager, and then throw a script on it to … erm… manage the game. Basically, player stats, environmental settings, whether or not something is visible, these can all handled here.
Instantiating the GameManager when you start (ie. not having it in your object hierarchy when you start to begin with), and then always checking before instantiating when the game starts over ensures that all of your crucial variables are always stored in one safe place.
This, like everything else, took me several hours to figure out.
How to Tween
Download DOTween. It just works. I mean, I got it to work in like 5 minutes. Literally, 5 minutes.
Failures of the Game
When all is said and done, there’s still a lot wrong with the game.
No way to understand what’s going on if you aren’t playing (not fun for larger groups watching)
Not a lot of fun. It’s a bit of fun to be honest, but you need a group of people willing to take the piss.
Conceptually flawed, especially when only two players are remaining.
That said, if some people play it, I might be able to get some minor suggestions that could make this more balanced, and then more fun. Right now, the shield can turn on and off, and that’s it. Perhaps creating a move to recover HP or prevent players from riding the shield could work. Need to think about it.
Where to Go From Here
So, honestly there’s a lot of work left to do on Controller Clash. The game will always be free on itch.io, but still I should “complete” it before moving on. Mostly, it’s a way to experiment in learning new things in an environment that I’m very familiar with, so expect some useless features.
What’s Left To Do
Make it fun – Right now, it’s Almost Fun (TM), but I think there can be a way to tweak things to make it more enjoyable. Toying with the idea of having a shield generator move that allows you to get HP back, and maybe some way to keep people from riding the shield. Also, Bomberman style dead players that attack random people might work too.
SFX Volume – It’s in the settings menu, but it’s not implemented now. The only way I’ve found to actually make it work is to tag every one of the SFX file entities in Unity with some tag, or put them in a list or something, and then iterate through them one by one, changing the volume of each file individually as the user changes the volume. It’s really cumbersome, but I can’t find another way.
Graphics – Bullet trails? More glowy bases? There’s a lot of room for improvement.
Animations – So, right now the characters just fade out into nothingness. I’d like to add a sprite animation for when they die. Maybe put some crystal shattering sound effect in there as well.
Collision Effects – Maybe a short pause when some player or shield gets hit with a missile? Something like that would improve the game feel a lot I think.
Neaten Code – The code right now is basically a mess. Every now and then I went through and organized everything, but as it got more complicated, the mess grew and grew. It’ll take a little while to find the best way to do things, so this is a long term goal.
Other Polish – Anything I haven’t really mentioned here.
Making this game has been (and continues to be) an amazing learning experience, which I’ll take with me on the development of my second title, which I think actually has legs to stand on. If you’ve read this far, and have thoughts on what I’ve done wrong (or right?) drop me a line here, or on twitter. Or wherever fine comments are sold.
I’ll just be over here, on Itch, fiddling around.
*More on BitSummit when I do up the photos I took and see if there’s anything good!
I’m going to be frank. I’m shit at making awesome things. Or rather, I’m really good at making a lot of slightly-better-than-mediocre things. Jack of some trades, master of (break out laughing here).
But this is not another exercise in getting off on self-deprecation.* What I’m going to introduce today is basically the culmination of what I’ve learned in the last 20+ years of attempting to develop something… an actual, honest-to-goodness, hand-“crafted” video game. It’s pretty terrible, but at least I made (am making) it. Think of this as the first entry in Burpy Fresh Games’ dev blog. A (somewhat less failed) fresh start after 20+ years of failure.
Just to give a little bit of background, I started coding on a TRS-80 back in the …mid 80s, I guess? I didn’t know that there was such a thing as a tape drive so I could store my code, so I would either take snippets of code from the coding book that came with it, type them in, and then mess with them and then shut the computer off, only to have to read from the book again, or I would write my creations down on a piece of paper. Fun.
Over the years, I got a bit better at things. Or rather, technology got better enough** so that I could almost make something. In the 90s I worked up a text based Dragon Quest style Zork rip off in Java, but I gave up after I realized text based adventures were never going to make a come back.*** I also tried to make a Zelda clone, again in Java, but I couldn’t figure out how to get smooth movement without updating the whole screen. I probably should have tried learning something else, but Java was the only language I really knew of that didn’t have crazy memory management issues. But both object oriented programming and I were kinda shit back then, so I gave up.
I gave up a lot.
About 2 years ago, a few buddies and I started going to Seoul Indies, (@seoulindies), and from there BitSummit and BICFest. I met a lot of people, and kinda got it in my head that I could actually try to make something on my own.I got a hold of Unity 4 something, and after a month or two, I gave up and instead took up creative crying and drinking classes at the Y. But then I downloaded Unity 5, and something amazing happened.
I closed, then reopened the program and managed to get my windows back to the same layout I had them before.
This, my friends, was ground breaking. Knowing how to use tabs gave me the confidence to start a new game. The smallest game idea I ever had, so I would have the best chance of finishing it. Now, all I had to do was learn to program, make art, make music, and not completely suck.
Challenge Accepted. Right now we’re about 50% done. I just gotta make it pretty. And functional.
The Burpy Fresh Dev Blog will return with “Controller Clash – Sticking to a Failed Concept.”