#DevlogsBecoming a #Gamedev

This game development malarkey… is it for me? Then Crashy Bash Boom!

My Two Year Development Challenge

Share
FavoriteLoadingAdd to favorites

First off, a bit of background

Back in 2004, I completed a Bachelor of Arts (BA) in Computer Animation; achieving a 2:1, and the world was to be my oyster - one filled with TV, films and special effects. For one brief moment, I actually thought this was going to happen (hint - it didn't). I achieved an internship with a small company in Glasgow, working on a children's TV series. The hours were incredibly long and the pay was incredibly small but I was told that when it was all done, my name would be in the show's credits and it would open doors for me. My name never appeared in the credits and my 'foot in the door' never opened far enough for me to sneak into the world of light entertainment.

Here's me fresh out of Uni, hanging with my mates. Not sure what happened to Russell, I think he does a bit of work in 'light entertainment'. Probably cruise ships or something.

When my contract as a Junior Compositor ended, I found myself looking for work and through good fortune, I did manage to find steady jobs in both graphic and web design.

Around two years ago, for reasons I can't recall, I decided that I wanted to start dabbling again in 3D modeling. I had the skills and experience but knew that I was a bit 'rusty' and wanted to see what I could achieve. I didn't have much any money so I knew that I was going to have to look at either my old software; I had a legit copy of Softimage XSI, or see what else was available. That's when I remembered Blender. I'd used it in the past but found it slightly confusing when compared to 3D Studio Max and XSI. Well, time had moved on and Blender had improved. Vastly. I found out it had its own game engine and was suddenly convinced that I could create something that people would want to play. Sure, Blender's game engine wasn't immediately intuitive but I found myself able to move a cube with the arrow keys within a couple of hours. I was a master game developer - my rise to meteoric fame and bundles of cash was imminent! After a few more hours, a realization hit me and I found myself thinking that maybe this game development malarkey wasn't for me.

This is a screengrab from the Blender Game Engine. I think it's given away by the number of times the word 'game' appears in the interface.

I don't know if it was fate or the fact that Google had been monitoring my search history, but my phone's news-feed brought up details of Unreal Engine 4 becoming free to use. What was even better was that it included 'Blueprints' - UE4's visual scripting tool. I couldn't code to save my life so this would make it actually feasible for an arty type like me to actually be able to make things move. This was it - my rise to meteoric fame and bundles of cash was imminent. I think everyone can see where this is going...

Here's a screengrab from 'Blueprints' in UE4. I know it is because it has the word 'BLUEPRINT' in the bottom right corner. That and because I have absolutely no clue as to what's going on...

So. I now had a game engine, a 3D modeling tool and an old creaking computer with a shockingly poor amount of RAM to use them on. I needed to come up with something to develop. It was obvious, I'd build a game. based. on... Yup, I didn't have a clue.

They say that inspiration comes from the world around you. And that's when it hit me. A building brick hurled at me by my youngest daughter*. This leads nicely into the next part of this blog post.

So why did I choose to make my game 'Crashy Bash Boom'?

Have you ever tried to get a phone or a tablet off a pre-teen whilst they're in the middle of a game? I have many times and the resulting tantrum of them not wanting to relinquish a device can be heartbreaking. Its snot and tears, the stamping of feet, and sometimes the children get upset too.

And there it was. Finally, the inspiration I needed. A children's game for mobile devices that would be simple and easy to play but with no long, drawn-out missions or tasks. Essentially, a game which could be picked up and played, but just as easily end when the time came to prise the device from their somehow always clammy, sticky hands.

So I was off. I had the tools and now I had an idea - a virtual building site with a digger, a dump-truck, and a crane. Suitable for kids of all ages. Boys and girls. Sure, it needed refinement but now I was getting somewhere. With hindsight, if I had known that my lack of refinement would result in a two-year development plan, I probably would have tackled it slightly better.

Unreal Engine 4 wasn't quite the game development nirvana that I thought it would be. Blueprint did work but it didn't seem to be quite as intuitive as I hoped. Then there were the build times. I think I once managed to make a meal, eat it and still have time to put the children to bed before it finished compiling. Then a month or so later I read that UE4 'wasn't really optimized for mobile devices' - now it made sense when my prototype worked smooth as silk on a PC but was like wading through treacle in trousers made from a hessian sack on my tablet. And there it was. My game development hopes dashed until I could either learn to code or wait for UE4 to catch up with mobile technology.

To my rescue came the modern day verb that is 'Google'. Whilst searching the web looking for some beacon of hope, I found out about the glorious Hutong Games PlayMaker visual scripting tool. I downloaded Unity and made the migration over to what would become my now, a platform of choice. Once I got my head around the layout, PlayMaker was intuitive, easy to use. Their YouTube videos actually had me developing interactive elements in a matter of hours. No longer would my coding deficiency hold me back. Now I could make my vehicles move, they would emit sound and the crane, with its wrecking ball, would spin about smashing things like a conker tethered to an over-excited child in a play park with slightly concerned parents.

An example of a conker threaded on a string. Players proceed to try and strike the other player's conker, knocking it from the string. In reality, the winner is the one who can actually put up with the most whacks to their knuckles, fingers and occasionally, a face.

Why did it take two years to make the game?!

As a solo game developer, you have to become a jack of all trades. You can't just be good at one thing and hope that the other bits will sort themselves out along the way. I kind of knew this but boy, was I in for a shock how long it would take.

I knew it was gonna be a steep learning curve but with support on forums, access to YouTube tutorials and various websites, I slowly but surely picked bits up and saw the game take shape.

The game now in Unity and an example of my first experiment with PlayMaker's Finite State Machine (FSM) system. 

As I mentioned previously, the game initially centered around three vehicles in a construction yard but as the development progressed, I realized that my ambitions were maybe a bit too grand. The construction site became a playroom and the vehicles became toys. Furniture came and went. A sofa was built but became too big. A lamp in the corner of the room became pointless as the base was the only thing visible. A detailed window frame was causing lighting issues and in the end, was outside the player's field of view. It was curtains for the curtains - the same problem as the window frame. All the detail was near the roof - it wasn't visible to the player.

Over time it dawned on me that I was building 3D models and they were being scrapped. My well thought out room was great on paper but I just hadn't taken into consideration the low camera angle and it's viewing limitations.

Looking at the actually playable elements of the game, the wheel movements of the vehicles seemed odd, like they were simply skating on the surface. I knew that I wasn't aiming for total realism but still, it grated on me when I couldn't get it to work right. Months went past and I couldn't get the control system right. It almost became an obsession. I tried virtual joysticks and swipe controllers from the Unity Asset Store but nothing seemed to work quite as I had hoped.

I knew something had to give and so the crane changed from a moving vehicle to a static one. The dump-truck was removed and the remaining vehicle, the digger - a model I had spent days getting right, was shelved. I now had a playroom with nothing in it. After a year, I had nothing to show for my efforts and my moral and enthusiasm for developing the game dwindled to nothing. It was time to concede defeat.

Absence doesn't always make the heart grow fonder but what it did do was allow me time to collect my thoughts and review where I was with the game. A few months later, a box set or two of 'Game of Thrones' and some time away from the development, I was going over things in my head when it dawned on me that the digger could be a bulldozer with caterpillar tracks. It didn't need realistic wheel movements and I could continue to build the rest of the playroom and toys. I built the tracks for the bulldozer, used the wheels from the digger and it was starting to take shape. It was then a further realization hit me. With no crane, no digger and no dump-truck, why was I still building a construction vehicle?! I wanted a vehicle - I knew that much - but what else would be fun to control?

I returned to Google and looked up reference pictures for tanks. One of the images that leaped out was that of the tanks from Advance Wars, a Japanese game developed for the Game Boy Advance. They looked great and the style fits in perfectly with my idea of a toy tank that wasn't your typical Abrams or Panzer style realistic ones. After a few sketches and some hit and miss elements, the toy tank was ready for modeling in Blender. As I was enthused about building it, it didn't take too long. The build of the tank also acted as a catalyst for the rest of the game development and soon I had the other vehicles; a police car, an ambulance, a fire engine and a sports car. The other playroom toys also formed more rapidly, including a castle with knights and a catapult, a diver and his wobbly platform and a musical keyboard play-mat, amongst others.

 

 

Finally, my game was starting to take shape. Shadows were based on a mixture of baked lighting on static objects and real-time lighting on moving/physics-based ones.

Jack of all trades, master of none

3D modeling has always been something I enjoy once I've started but texturing has always been something that I find to get in the way, which is odd when you consider how intrinsically linked they actually are. To my relief, I found out about vertex coloring - which rather brilliantly added a visual aesthetic to the game. I'd tried using bump maps with baked ambient occlusion and I'd never felt that I had a look that was sitting right with the game. With vertex coloring, the simple colors and the low polygon models suited each other perfectly. At least with what was in my mind's eye.

Sound production was something I enjoyed at University but since then, I'd never had a reason to do it. So with a microphone from some Wii Disney sing-along game that we'd never actually played in the house; a fear of being mocked by my own children would ruin my dreams that I may not actually be a good singer, I downloaded Audacity and got to work making as many weird and daft sounds as I could, in the hope that some of them would actually be usable. Incredibly, most of them were - by the way, if you want the sound of a toy tank engine, I'm your human sound effect machine. Oddly enough, I'll make stupid rumbling and popping sounds in front of you, just don't ask me to break out into 'Let It Go' - I'll crumble like a house of poorly arranged playing cards.

With the modeling, texturing (or in my case, lack thereof) and sound effects done. It was now a case of bringing it all together inside Unity. I'd already mastered the art of bringing models of various sizes and scaling them to fit but of course, it was only when I started tweaking the physics side of things that you realise that a toy scaled to a tenth of its original size will not react quite the same as one which has been scaled UP to become consistent in the game world. Scale it right first in your 3D modeling app or use the properties tool in Unity before dragging into the level.

Thankfully, sound effects were pretty straightforward. I used PlayMaker to detect collisions and play the responding sounds and triggers for most everything else. I did struggle a bit with fall off but after a day or two, I'd figured out the majority of it. Music was sourced from a free audio website that had a number of tunes perfect for retro-style games and two of these were suitable for my game, acting as the intro screen music and the actual in-game tune.

Surely that's it now?

You'd think so but sadly no. I had a working game but there was still that slightly glitchy control system. When profiling the game using Unity's own tunneling profiler, I could see that the physics engine was being hammered due to my ramping up of the game's 'time' setting. This needed fixing immediately as on older devices, the game dropped to refresh rates of 15 to 12 frames per second.

crashy bash boom

The Unity profiler! Basically, a visual guide telling you "Your game is a physics-based nightmare - sort it out! Now!" 

Quick tip - if you are building an iOS or Android game never just run the game and use the profiler directly in Unity. You'll see a whole host of weird things happening that have no reference to your mobile device or tablet. Build the game and allow it to run on your device with the profiler monitoring that. You'll then get an idea of where the bottlenecks are and what you need to fix.

So, back to the control system. I was using a look and translate the object to move the toy tank around the game. This meant that any collisions between it - a NON-physics based movement with something that IS physics based was incredibly expensive for the game to work out. Now that I knew the issue I had to fix it. It was back to the nightmare that was the movement of the player.

I had been playing with wheel colliders and had developed a rig that worked perfectly on the other vehicles. When the ambulance, police car, fire engine or sports car were approached, a collision trigger told them to provide torque to the wheels and drive off for 3 seconds and then return the torque to zero. Could it be that simple for the main player? Could I add hidden wheels to the tank and make it move when the screen was touched and then 'brake' when the player's finger lifted off the screen? The answer was yes. Dead simple. I'd only spent just over a year trying to fix that and in one day, as an experiment and no real forward planning, it worked. I'm not gonna lie - I almost cried when I figured that out.

Finally, there were the graphic design bits to do. No great struggle there thankfully and then that was it. Upload it to the Google Play Store and phew, I was all done...

You know it's not gonna be that simple...

I always feel like somebody's watching me...

Yup, when I installed the game on my own device (which by the way was really confusing when the Play Store told me I couldn't install it - not compatible with ANY of my devices. I almost had a panic attack and thought I'd got something wrong in the final build. Turns out you can't install your own game via your own email registered with the Play Store), I had requests for GPS location services and access to device storage - not a thing a parent is going to ignore when installing a game on their child's device. Is someone watching, monitoring where my child is?! Why would a game need to know my child's location?!

It turns out that the Android Manifest demands access to these services and that Unity can't revoke these. As a workaround (and a major pain in the butt) you have to perform a Gradle build, remove the two lines in the manifest and then perform the APK build in Android Studio. That's not a nuisance, is it?

Wow, surely that's it done now?!

Funnily enough, after two years on this one project. I said pretty much the same thing. Probably more expletive-filled but yes, I was finally glad to say that I had designed, built and published my own game on the Google Play Store and the Amazon Appstore. So with that now done, I can sit back and watch the money come rolling in. Fame will be around the corner... won't it?

And there it is, on the Google Play Store. After years of work, I'm honestly proud to see it there. It's not 'World of Tanks' but for a solo developer working a full-time job, Monday to Friday and raising a family, it's my magnum opus.

 

Join us!


How about writing your own piece for IndieWatch?


Tags
challenge gamedev newbie mobile #android #unity solodev playmaker Unreal engine 4 Unity Asset Store Google Play

Barry Collard

Originally from Cambridge, England, I now live in Inverness, which is located in the North of Scotland. By day, I work as a Graphic Designer but by night (at least once the kids are settled), I switch to game development using Blender and Unity as my tools of choice. I launched 'Crashy Bash Boom' on the Google Play Store at the end of December 2017. The game is a simple but fun 'swipe to move' tank game set in a toy-filled playroom. It's designed for young children but also for parents who are fed up with losing their phones and tablets to their offspring who seem intent on completing challenge after challenge, task after task!

Leave a Reply

Your email address will not be published.

Back to top button
Close

Adblocker Detected

Please, consider turning off your Adblocker so you can enjoy IndieWatch and contribute to our site's existence. We need to display ads so we can keep our gears smooth and running. Thanks for you cooperation!