I last 56 seconds….
Monthly Archives: December 2014
Dev Log for Space Warfare: Infinite – Beam Weapons are awesome
Still working on capital ship weaponry and it’s fun! I’m actually doing a lot of clean up under the hood since my general programming process is get something working that I can play with on the screen as fast as possible and worry about making the code better later. I am in a make the code better phase because capital ships are far more involved than fighters and they are forcing me to break out some of the systems I just hard coded into my fighter scripts so that after I am done, I’ll be able to iterate more ships, turrets, weapons, other objects faster.
Capital ship with one beam weapon lays waste to a fighter wing…
BEAM WEAPONS!
One example of this current decoupling is beam weapons – a totally different style of ‘projectile’ that still works with the components I built. The main turret I made last weekend just fires off regular cannon projectiles which are the same things that the fighters shoot. It’s been my standard projectile along with missiles for a long time. Standard cannon projectiles do 1 damage to the hull (armor and shields haven’t been implemented yet…) and missiles do a bunch more. The beam weapons are set to 1000. They cut through anything and can destroy multiple ships in one hit. I’ll probably dial it back but its fun to watch the thing just vaporize fighters like gnats. I envision this level strength weapon to be a capital ship attack weapon so the turret will probably track slower and generally just target other big ships. I might also make a short range faster tracking anti-fighter beam to punish players who get to close. The beam weapon definitely makes a cap ship something to fear.
On the technical side – I used a line renderer with a collider for the beam and I hacked together a lense flare and light at the origin of the beam. I might add another lense flare type thing to places it hits stuff so that it looks like a weld torch. Might be a cool effect that is different from the regular sparks and stuff of other weapon collisions.
Space Warfare: Infinite – Screenshots gallery galore
Here are some of the latest screenshots of Space Warfare: Infinite! Still WIP and still in pre-alpha, but it’s also still a lot of fun!
-
- Closing in on the cap ship
Developer Log: Space Warfare: Infinite – Capital Ships and Turrets
I spent the weekend putting together a capital ship and its turrets. Its still a work in progress, but it is fun to have to play around with.
Capital Ship!
I built the capital ship model using Pro Builder. I’m still a true amatuer at modelling, but I am working on it. The ship is a carrier-type with a big fighter bay on the side. It’s about a kilometer in length, but you can only really tell if you put a 3rd person character on it and walked around. It seems like the trick is to put bunches of detail panels and sloped surfaces on it so it doesn’t look like a flying cube. I am using games
like Freespace 2 as a reference since the ships were boxy but people still liked them. Once I get some nice models together, I will explore real texturing. The current carrier isn’t going to be in the finished game – at least not the model in its current form. The main goal was to get something giant to fly around and fight against that had a killer amount of turrets. Ta -da !
Having the cap ship, tho, gives me lots of directions to go. It’s be cool to have the player fly out of a fighter bay tunnel at the start of a battle. I have an idea for smaller gun boats that would be a much smaller cap ship with a big gun and a pd. They’s have less armor, but would be a bit more maneuverable than big stuff. They’d be used in groups to attack big
ger Battleships by attacking from different angles and things to overwhelm defenses. Going one-on-one with a battleship would be a big problem since a big gun might take it out in one hit, but a group could score a bunch of hits while a big gun can only focus fire on one target.
I want to get AI together that will allow the cap ship to maneuver. Once that happens, a second capital ship so that they can fight each other. The current one would have to have AI that would make it find an average waypoint in the middle of the action so it can get in there and mix it up with fighters. Or, it will need AI that can chart a course along the side of another cap to do a flyby. If all caps follow the current gun load out a dive and attack would be a good strategy since a caps guns are on top mostly, so getting under the enemy will offer a passing attack while not getting exposed to the bigger guns on top.
Also there will be at least one cap ship with a giant trench in the middle leading to some sort of highly explosive power core. It will be the only cap ship that a fighter might be able to take out on their own.
Turrets!
The turrets rotate and look up and down to target enemies. Currently they are sort of Point Defense guns, but I am also going to add anti-capital ship guns, beam weapons and missiles. The model for the turret is really for a big anti-cap gun.
My basic thoughts are that all guns on a cap ship should be on a turret since the ship can maneuver as simply as a fighter. Big anti-cap ship guns will rotate slowest, but pack a big punch. Currently, if a fighter is unlucky enough to get hit by a anti-cap projectile its instant explosion. Big guns will prioritize other big ships that aren’t zipping around. Point Defense (PD) guns will track and take out fighters and missiles that get too close. Currently each turret has its own targeting AI. I hope to also add a targeting list function for some guns like PD and high-fire rate missile launchers so that they can move briskly between many targets. In a combat mission against Capital Ships, the main goal of fighters is to take out the PDs and other guns to make way for missiles to take out the ship. I am thinking some classes of cap ship will have strong enough armor that standard cannons on fighters won’t do any damage at all.
Fixing the Unity Constantly Turning or Spinning Player / Camera Problem
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:
float translation = Input.GetAxis(“Vertical”) * speed;
float rotation = Input.GetAxis(“Horizontal”) * rotationSpeed;
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.
then you might write code like this:
if( !joystick )
{
//if joysticks aren’t enabled – just track keyboard axis
float translation = Input.GetAxis(“Vertical”) * speed;
float rotation = Input.GetAxis(“Horizontal”) * rotationSpeed;
} else
{
float translation = Input.GetAxis(“VerticalJoy”) * speed;
float rotation = Input.GetAxis(“HorizontalJoy”) * rotationSpeed;
}
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.
#1GAM Post-Mortem and November’s Game Vocab Stacker – Challenge Complete!!
It’s been an entire year of making a game a month. I started on a snow day and made the Snowpacolypse snowball fight game and finally rounded it out with an educational project I am working on. I’ve delved into a number of spacey games, zombie shoot em ups, a 3rd person platformer, two somewhat abstract games, my first Android app that even sold some copies – Tap Invasion, 2 online multiplayer games, procedural generation maze game, and several (4!) Space Warfare demos.
Needless to say, I’ve experimented a lot and learned a lot. I feel happy about the things I’ve worked on and learned over the year and feel like a much better programmer! I am looking forward to the next year of focusing on just a few projects. Mainly my Space Warfare game and the educational games this months game is a sneak peak at. I have a lot of plans for Space Warfare and feel like it has come a long way. I hope to keep improving it and making it awesome after all the stuff I’ve learned.
Here is a link to the Badger Head Games One Game a Month Page…
The final game is part of a vocabulary game I am working on for my school. This is not the final version, just a demo version that is geared towards my Reading / English class. The final game is going to be focused on History vocab and will hopefully be released on school iPads!