B.U.R.N Dev! All systems go!!
polycounter lvl 15
Here I am at it again and I brought a friend along for the ride. Yung is helping a lot by building the mechs for my second and his first indie game using Unity!
So what is B.U.R.N? Burn is an action/mech battle game that puts you in the seat of a B.U.R.N unit. Members of B.U.R.N take on other mechs be that they are autonomous or driven by another human. The story and other details will be revealed as we go along. Hopefully it will get everyone excited enough to want to check out more!
The design for this game was to keep it simple and keep it fun. Before I asked Yung to join in I went and developed most of the movement system. I then went on to add a basic firing abilities and other controls. From there I designed the damage and health system as this is important. Then I did the weapons system and started placing in dummy effects. So after that, I asked Yung to join in and I was lucky he said yes. Most every system is already coded/scripted (whatever you want to call what someone does in Unity).
After a few days Yung had a few concepts for the project and already I can tell it is going to be awesome. Based of the concepts he had, I began to think about the levels that each one would inhabit and began coming up with ideas.
So to kick things off, here's some shots of our concepts and models. From here on out it's adding content and playing the hell out of it. Play testers are already signed up and will get the droid training level soon
. Along the way I'll share my discoveries and other bits of information I hope you'll find useful.
I'll keep everything in this thread so people don't have to sign up for needless websites.
Replies
When I started this project, my goal was " have it play awesome and look good on old hardware". I don't have the latest iPhone/iTouch. It's a couple generations behind. And this is one of the things I love about handheld game development: optimizing. No skinned meshes, I am killing needless items ASAP (including GUI things). I made a manager for the GUI. So if the GUI element isn't needed, the item it's attached to is killed, not just turning off the GUI. There are only three materials used at any one time: sparks, mech texture and world texture.
At first I was going to have the level and mech share a texture, till I saw how much/little memory I was actually using. So we are now using one texture for the world, and one for the mechs. Yung is happy about this.
About scripting...
So Toaster Kun was made all in one script file. It was VERY hard to manage at times. I didn't get into messaging and referencing other scripts. If it's one thing to learn about how Unity works is doing things like this. It has made Burn SO MUCH EASIER. It made it easy to fix and tweak things. I wanted to work on just the health, open the health file. I wanted to make a weapon, just flick a setting.
My weapon script is actually one file. It has settings so I can make almost any kind of weapon needed for this game. From machine guns, to shotguns to a rocket launcher. Then my weapons manager looks for the null objects that I have attached to it, and I can swap between them any time. Want 8 weapons, fill the array with 8 objects. I was thinking of just having a button change values in the script, but it could get hairy. Next time...
Discovery....
I found a way to do side-scroller beat-em ups. And animated jointed (not skinned) objects with physics will break and still play the animation. Add a command to stop the animation and cool things can happen. Like a rock gollum crumbling as it walked type stuff.