Welcome to the first in hopefully a series on making a space game. For some time I’ve been thinking of creating blog posts and videos about how I am creating Space Warfare: Infinite and creating a resource for other aspiring developers. I’ve been messing around with programming games since I was 11, but I am completely self taught so I never feel like an expert enough to really tell people how to do stuff in this world. However, I do lots of research and have been collecting lots of resources. So while I might post some vids / tuts on how I did things, I also want to share some places I found helpful. Below are a number of videos on how to model sci-fi scenes, space ships, and other related things. I am storing them here for myself and my own work as well as for you!
Blocking out – Design Videos – Not Blender Specific
The video above does not use Blender, but watching how he designs and his commentary is really cool for your process. No matter what software is used or what language, you can always learn from people who know what they are doing and then try to apply that learning to your own world. So don’t only look at Blender or Unity tutorials when you can apply overall concepts.
It’s been a long week with lots of snow days to work on Space Warfare: Infinite. While I added some features, I have been spending a lot of time on optimizing and finding bugs.
Porting to Unity 5 – set-backs, opportunities
I converted my game over to Unity 5 only to find after many hours of fixing all my prefab connections and UI stuff as well as as many Red and Yellow warnings in the console that I could, that Unity 5 would not compile my game to stand-alone or when it did the game would be a black screen, a black screen with music or a the actual scene at 1 frame per second. Not good. I ended up starting a new Unity 5 project from scratch and began exporting component packages of my game as well as just importing assets one at a time. I figured as I developed I had lots of random scripts and tries at things that might be mucking up the code. Additionally I had a bunch of 3rd party stuff that I wasn’t using anymore or have pieces of but don’t need the whole thing. I left all that extra stuff behind. When I was done – although I am still bring in some non-essential or unfinished stuff – everything compiled and worked!! It was a bit of a wasted 8 hours, but I took the time to organize my code, make folders for everything, clean up the scene. In the end the project is more user friendly and easier to work with than before.
Here is a gameplay video of the latest build in action:
Start Menu and Unity 5 Tutorial
I made a new start menu! I put in place holder buttons and filled them with names for my aspirational game modes. Some day when all the buttons actually work, the game will be somewhere close to donish. I suppose there will be more to this menu and I need to build the sub menues like Options etc. Currently they take you to my test missions. I guess they are a kinda instant action more than a coherent campaign. The Instant Action button will someday take you to a menu of instant battle scenarios to select from as well as any user generated battles that were flagged as instant. The Campaign menu will have the list of selectable campaigns as well as the load and save functions.
This one has tooltips to explain the different modes and options when you hover over a button! If you can figure out a non-invasive way to explain stuff, I am all for it. I want people to be able to just play my game. (He says as he joins the time honored tradition of using every key on the keyboard). And generally you can just jump in with a 3 button mouse and WASD controls you can fly the ship and shoot at things. However, the game can also be pretty complicated as I add more and more systems. I want the player to be able to control all the things.
I also made a video on how I did the tooltips for other Unity 5 game devs out there. Now that Unity 5 is super free, perhaps I should my more of this videos for my students and other folks.
Object Pooling for Projectiles
Was this a problem I had to fix? Who knows! Mike Geig told me in a video that it could increase my frames per second by 10! Why not give it a whirl. Also I know that instantiating something big sometimes stutters a computer and I don’t want that to happen. I’m working in more loading screens. There is now a loading screen for the beginning of a mission, but it loads so fast you don’t see it. But, you might soon as I want to instantiate all the missions ships at the very beginning during the loading phase rather than one at a time. Once I set that up, the ship initialization can be have – plus they build their object pools at the same time. So I need to do all this on the front behind the load screen – can’t have things pausing in the middle of the action so another ship can warp in.
The battle editor is one of the main things I want to set my game apart from others. A major inspiration for what I am trying to accomplish in Space Warfare: Infinite is Gratuitous Space Battles. I love the giant fleet battles and wonder what its like to be that little fighter in the midst of it (or the capital ship commander for that matter). I also share Cliffsky’s love of explosions. Building a simple drag and drop battle editor toy box is a huge part of making this dream a reality. I want the game to basically be modible from the start. Growing up my favorite thing about some games was being able to build my own maps and missions. Before we had stuff like the Unity and Unreal engines, and you had to read the 2000 page Tricks of the Windows Game Programming Gurus and wade through pages of DirectX code to make a game, having a map editor or an easy modding tool was the best. I loved making Doom levels of my own. I loved building Starcraft maps to play–especially filling the map with tanks and bunkers lined up against each other. I had a great time making 3D studio worlds.
Anyway, now kids have Minecraft (and make whatever they want all the time) and the first question people ask you about any game you are making is: is it sandbox based and will there be crafting? The short answer is – yes you will get to fly to an asteroid, don your space suit and your intergalactic pick axe and mine cubes of ore to forge it with your bare hands into an Ion Cannon–all while being shot at by a heavy cruise with a rail gun aimed right at your flying refrigerator ship. Wait, no. The short answer is no. At least I think so. I plan to have miners in my game. But they will mainly be there to get blown up by pirates. You can just have the Ion cannon. At the same time… I am building tool so that a player can add an item/ship/projectile/weapon to the game with a unique name, look and functionality. You just craft it in the Battle Editor and add it to your custom Campaign, mission, scenario, free play rather than in game while wearing your space suit.
Currently the editor is not much to look at. You can select ships and drop them in the sector. Currently everything will be on the same plane –in game things fly in all directions though. The sector distance I settled on is 50 kilometers in every direct from center. I think this is ok based on floating point limitations (which is the data type used in the position vectors). From what I understand you can have 7 digits of accuracy using floating points. Since each unity is a meter I can get down to a 100th of a meter-known to the rest of the world as a centimeter. I guess I could go from 50000.00 to 99999.99 but 50k in game already seems pretty large for a battlefield and I want room on the edges so that if combat takes place at the 50km mark there is lots of room around it before float point errors occur. I can only see this happening with an AI going haywire and running in a straight line out into the distance and a very determined player with a lot of time on their hands chasing them.
The editor will eventually have the ability to add scripted events like Comm messages, ships jumping in at certain times, check points, objectives to complete or fail.
Additionally, I envision that when you select to create a new battle you will be taken to a map of the universe first, allowing you to chose a system and then a sector of the system to use as the battlefield. At some point, when I player creates a new campaign, they will be able to generate a randomized universe or map out a custom one and then use that to build their battles. Each battle will be linked by a campaign editor which will be able to take into account objectives met/failed and choose branching paths.
In the near future, I want to get the basic place ships functions really working so you can save it and load different battle configurations in instant action. After that we will add controls over the more advanced events and objectives. Having a functional battle editing toy and a few default instant action missions will basically mean some sort of demo will be ready to send out to my pre-alpha testers.
Bug of Doom!
So I compiled my stand alone after rebuilding my entire project, everything awesome! Bugs destroyed. Let’s play this game… Game began crashing the moment a certain ship warps in on the 3rd play through only. I only noticed it after I built a stand-alone. My nightmares had returned. It was an insane bug. You could play a whole mission, no crash. You could restart on the start menu and play again. Nothing. But restart and play that third time and about 5 seconds in the screen freezes. Nooooo! I figured I was never going to get to build a stand-alone game in Unity 5. I spent an entire day debugging and finally pinned it down to using a static class for pilot names. I guess it creates a memory error after being reloaded (I believe statics stay in memory after a scene reloads). Since the game crashed, I could only watch my Unity Console up to the moment of the crash and if I was playing I couldn’t see it at all. I relied on the system console to read the debug.logs. I basically added debug.logs before and after every function call in the AI initialization until it became clear. I know Statics can be bad, but man, my game crashed because I wrote a dumb class to give my fighter pilots funny names.
On the plus side, before I figured all that out, I added garbage collection, making sure Invokes and Coroutines were stopped when the game reset. I tried to make the audio better. I began working on the object pooling. Lots of good coding practice came out of this nightmare. Sometimes you have to be tenacious as a programmer.
Cool new music – and a music player that chooses a random track so I (and you) don’t hear the same song over and over again for the last year…oh wait that was before I added this feature. The music is techno western-ish, need more. If you read this and make electronic music for games and can make electronic/western music or just music that won’t clash too much with that and be good for epic space warfare and won’t charge me lots of money….send me a twitter msg. Brown Coats forever.
New yellow Power bar – gives you available power, all guns use a small amount, beams use a ton, engine thrusts have the green thrust reserve bar but can dip into the power after its gone. (or is this a huge thing?)
Bleep sound when a comm message appears or changes so you remember to look up and read the story
Made some fighter based lasers -will be continuous and pulse versions
Made the J.I.M. anti-missile turret for fighters (still need to import to the newest build though)
Added some anti-cap ship torpedoes – limited guidance, big punch if landed
The player now flies my fighter model for better or worse
If your players are reporting that they keep spinning in your game and can’t stop, there might be an issue with the joystick inputs on their end that makes it impossible for you to find the bug. However… you can program to solve it if you make enabling Joysticks optional.
Here is a player video of the bug!
The best way to solve this from the programmer end is to write your input scripts to deal with it. Currently, your game (by default) accepts Horizontal and Vertical Axis info from the keyboard or a joystick. They are labeled the same in the Input Manager… That way you can write code like:
And it won’t matter if the player is using a keyboard or a joystick. Unfortunately when a player has something going on with their joystick stuff (virtual joysticks seem to cause issues), the Axis gets all wonky… Players report spinning around that won’t stop.
BUT… If you change the name of your second set of Horizontal and Vertical Axes in the Input Manager (the ones that correspond to the joysticks) to something like HorizontalJoy and VerticalJoy then they won’t interfere for your keyboard-only using player. You could then add a toggle on your Controls or Pause menu to enable Joystick controls.
Below is a screenshot of the input manager – notice the second set of Horizontal and Vertical Axis are called HorizontalJ and VerticalJ. Do something like that and write code to allow for joy support if you want to give your user the option and the bug should be fixed on your end and the users. This also means joys won’t really be tracked unless you write code to watch the specific axis as stated above. This solution worked for my testers.
//subtract AI thing’s position from waypoint, player, whatever it is going towards…
Thanks to http://wiki.dreamsteep.com/Unity_ai and http://vimeo.com/9304844 for explaining the concept to me. If any readers are having trouble, check those sources… My numbers for distance and repulsion are based on spaceship moving at high speeds. The examples show slow moving spheres so their numbers might work better.
Next I will be adding a case where if all three raycasts hit you need to move one way or another. Otherwise, everything cancels out just about and ships still crash into stuff and explode. I kinda want that to happen a little bit so that you can feel like you are in a good asteroid chase scene, but not so much that it is over in seconds…
As you will see from the video, while I love making games, I am not the best video game player! While I enjoy playing games, I also play stuff that I can get ideas from. The folks behind Strike Suit Zero have made a pretty impressive space battle game. I love the feeling of being in a big space battle with lots of fighters and capital ships flying around. The mission in the video also has a space station. I spend a lot of time trying to blow up a frigate and take lots of damage getting hit by its turrets. Each turret is targetable and destroyable. In my game, charging into Point Defense Turrets like that will probably make for a quick end to your ship. Taking out cap ships will require some strategic targeting of the defensive guns before making any type of bombing run.
Things I love about Strike Suit Zero:
Big cap ships engaging in battle
Nice small fish in a big fight feeling
Engine trails that make it easier to see enemies
Turrets on ships
Cool HUD targeting system – arrows pointing to available targets, boxes on targets, circle that tells you you are aiming right
nice explosions, shield effects, player hud static effects when damaged.
Comms w headshots – moves story along with cinematics
Being able to survive but still lose a mission (sometimes the game doesn’t continue on tho, you have to play until victorious)
Anyway, look forward to my future videos. I am planning to make an intro to Unity tutorial featuring hover tanks and rockets. It should be an ‘easy’ to follow tutorial to get folks started on making their own Unity games.
Here is a quick tutorial I made to help some of my students and game programming club members get started in Unity 3D. The basic idea is that you can use some of the basic assets that Unity gives you to create terrain for your game world, add some nice grass textures, a sky and then drop in a player to explore! I don’t go in to too much detail about the engine, but it’s a start! Post a comment if you have a question about the video. I’ll try to make some more tutorials to help with more involved stuff in the future.