The blog is being migrated and merged with multiple Imphenzia blogs so the format and content will be inconsistent for a while.

Unity 3.5 and Menu Flow

I've been occupied with fixing up my Yamaha WR250F for the upcoming race, Ränneslättsloppet, on Saturday:

  • New oil and oil filter

  • New air filter with NoToil air filter oil

  • Changed to the enduro tires I also used on Stångebroloppet in July (with new inner tubes)

  • Fitted the coolant reservoir again (engine it runs hot in races like these ones, three hours of slow movement isn't great for the engine that relies on fast flowing air through the radiator)

  • Fitted new hand guards

  • Removed the indicators and number license plate

  • Fitted the race numbers

Here's are some clips from the 2008 year edition of Ränneslättsloppet... Let's hope it isn't too wet this year =)

What about Astrofighter.Net then?

I've also been working on Astrofighter.Net during the past couple of days but most of my work has been shuffling around boxes in Visio to try to get the menu flow and GUI design in order. Even thought this is a fairly small game I want to make sure that the lobby screen, ship selection, hosting options, etc. is very easy to understand. I hope it's worth the time spent on getting it right =)

I'm also looking forward to Unity 3.5 which is scheduled to be released in late 2011. The conference "Unite 11" which is currently being held demonstrated some of the new features and I found quite a lot of useful information in this blog post.

Even though there are some really visually impressive features coming in Unity 3.5, I am looking forward to the new GUI / UI very much. I don't particularly like the limitations of the GUI in the current version of Unity and it would really make things easier if the new GUI Editor is available before I have to have a go at making the final menu system for Astrofighter.Net.

Apparently there is Subspace

Today I was also contacted through my ImphenziaGames YouTube-account by a couple of guys who play a game called Subspace.

I wasn't aware of this game although I now understand 1) it's been around for a long time, and 2) it's a 2D multiplayer space shooting game.

Both guys asked me whether Astrofighter.Net is influenced by Subspace and at the moment it isn't. In fact, there is no influence from any particular space shooting game and I have deliberately not researched any "competition" as I didn't want it to cloud my ideas for Astrofighter.Net.

Due to the nature of my game, and in comparison to Subspace, there will probably be less players on a server in Astrofighter.Net. I will, however, based on how much I can optimize the networking code allow for as many players as possible. My current goal is 16-32 players and since I use rigidbody physics (instead of simply moving objects using velocity and direction) the game uses a fair amount of bandwidth.

I now have most aspects of Astrofighter.Net sorted out in my mind so it's mainly a matter of making it happen. This is a one man show and I do the development, 2D graphics, 3D objects, textures, music, sound effects, and web development by my self so it'll take some time.

Feel free to contact me if you think there are "must-have" features in a game like this. I will consider any input I get, but be aware that I may not necessarily be able to (or want to) implement them =)

Menu flow of Astrofighter.Net

The importance of a flowing menu system

Today I prioritized looking at the menu flow of the game. If there was anything I learned from Beat Ball 2 it was that I shouldn't take for granted that a menu makes sense - especially with assumptions like "people will probably understand." Many won't.

The reason why the menu system in Beat Ball 2 is confusing is because I added features "on the go" without any proper thought to it. I've got a chance to get it right in Astrofighter.Net from the lessons learned before.

Flowchart the menu

I've created a flow chart today that contains all the menus: Main Menu, Find Game, Host Game, Options, Lobby, etc. For each screen and item in the menu I think very carefully about:

  • Does the flow between screens make perfect sense?

  • Are the options labeled correctly?

  • Is every screen absolutely necessary?

  • Is every option absolutely necessary?

I'm putting effort into this process now because how I continue with development of fundamental building block of the game and game states (menu, lobby, match, etc.) depends heavily upon the menu and game flow.

What bout the menu design?

The actual design of the menu is secondary in comparison to the flow. Of course, it's important with a visually pleasing menu, but it can't harm ease of use and navigation.

Even though I am focusing mainly of the menu flow rather than the actual design I made a proof of concept main menu screen. The idea is space oriented with high contrast where white text is always clickable and orange text is always a title of a menu / section. Menu navigation will be to the left and context and buttons will be to the right.

[caption id="attachment_447" align="aligncenter" width="620" caption="Astrofighter.Net Main Menu Draft"][/caption]

Free game but registration for statistics

As you can see in the main menu draft picture you can see a "pilot profile" which is essentially a player. First of all I will, most likely, make the game free for every to play. If a player wishes to record statistics (such as kills / deaths / weapon use / ranking etc.) the player will have to "Register" the pilot for a small fee. There will be a lot of communication and database handling to store all the information and hosting the service to enable the statistics feature costs money so I think it is only fair to charge a small amount to offer this functionality.

I am also putting a lot of effort and resources into Astrofighter.Net at the moment with some sacrifices such as lost social time and sleep =) For this reason it will also be required to be a registered pilot in order to pilot all the different ship types.

That's my idea anyway - but everyone will be able to enjoy the game whether you wish to register your pilot or not =)

Platform support

I'm developing this game with the Windows platform in mind but from what I understand it should be easy to compile the game for Mac OS X as well. And not only that, I read great news on the Unity3D web site that Playstation 3, Xbox 360, and Wii support is around the corner and unless Sony, Microsoft, and Nintendo make it very difficult for me to launch the game on their platforms it would be very cool to have it run on consoles as well as computers.

I don't plan to support Linux at the moment. Linux are for servers.

Added homing missiles to the array of weaponry

Just a quick update today - I've just added support from missiles with optional homing / seeking functionality to Astrofighter.Net. The homing feature will need some tweaking though, have a look at this video =)

I'm going continue with development for another couple of hours now.

I lost my vector (Astrofighter.Net)

Today I spent 3 nice hours in the autumn sunshine riding motocross at Uringe which is about a 45 minute drive from where I live. When I came home I first had to wash the bike, then I had to wash my Enduro bike that I had left in the garage all muddy the week before. Since the gear was out I also decided to wash my car.

It was 5:15 PM by the time I got in and we then headed straight to the playground with my son so he could play for a couple of hours. Back at 7:15 PM. Then it was time for him and my daughter to go to sleep so after changing into PJs, the nightly bottle, brushing teeth, saying good night, getting them a sleep, it was 9:00 PM.

Still no development as it was time for me and my wife to eat. I made some fanjitas, or was it burritos, and by the time they were done and we'd finished eating it was 10 PM.

Finally, I'm really tired but I launched Unity to get some more development done.

Today's progress

Didn't get a huge amount done today during the 3 hours I could spend developing (10 PM - 1 AM) but some progress was made.

Missiles on the way

I'm adding support for missile and currently I can fire missiles with smoke trails. Since the trail needs to live longer than the missile (if the missile reaches end of life or impacts) I detach the smoke trail particle system gameObject from the parent missile gameObject so it can fade away nicely.

Vector confusion

I also added parent velocity from the ship that fires a bullet/missile but even though it is correct to do so in real life it didn't feel right in the game. Ok, it's fine if you go straight ahead because if you add the velocity of the spaceship the bullet will move away from my spaceship at the same rate as it would have if the spaceship was stationary... BUT... since the spaceship has drag (funny in space, huh?) and the bullets/missiles do not it looked very peculiar so I'm opting to add part of the parent velocity to my bullets/missiles.

The problem with this partial velocity I need is that I don't know how to calculate it so I had to spend some time drawing a picture and posted a question about it in the Unity3D forums.

Should I treat missiles like bullets?

I've also been faced with some other issues today. For simplicity, should I treat missiles like bullets or should they have a separate class?

The benefit of sharing the same class, even if the name is "Bullet", I would reduce the complexity as anything fired from a weapon is an instance of the bullet class. Another benefit is that they can share properties, so a bullet could become homing if I ever wanted to add that as a feature.

The downside of treating it as a bullet is that I have to do a lot of checking in the code to handle missile-like specific properties, such as a smoke trail, acceleration, homing, etc.

My decision, for now, is to treat it as a bullet. I'll also keep it as a raycast and move it by changing it's position every frame rather than treating it as a rigid body with it's own thruster and physics properties.

Homing missiles might become a networking issue

Firing projectiles and rockets in a straight line is not a big deal with a network game. The server tells all the clients that a bullet was fired at X,Y with a velocity of Speed. All the clients can then instantiate their own bullets and there is no need for the server to keep sending positional data of bullets all the time.

The problem I foresee for homing missiles is that the server, who has the real state of all the objects at the time the homing missile was fired, will probably calculate the trajectory different from my predicting network clients. This could result in the missiles taking a different path on the client missing the object but on the server who is authoritative it actually hit. For the client it would appear the missile missed but a ship may explode anyway because of server registered the hit.

My plan is to give missiles, or at least homing missiles, their own NetworkViewID in Unity and send positional data from the server to ensure they take the same path. The downside is increased network traffic but I suspect missiles will have a low rate of fire and won't be coexisting for a very long time so it should be OK.

Signing off

The past week I've slept between 3-5 hours per night and I think my son will be waking up in about 5 hours from (it's 1:41 AM now) so I best head off to bed.


I solved the issue. What I was looking for was the dot product comparing the velocity vector and the forward direction of my projectile.... Funny what guesswork can do =)


Astrofighter.Net Development Update

Last night and today I rewrote the weapon class for Astrofighter.Net so that it can support a wide range of custom properties for each weapon. I've added about 40 properties so there will be a great number of ways to upgrade weaponry using powerups.

Here is a short video demonstrating two of the properties named "ChargeUp" and "Multiload." If "ChargeUp" is applied to a weapon you can hold the fire button down to increase the power/velocity/life of a shot. The "Multiload" upgrade allows you to hold the fire button to load X number of rounds before discharging the weapon.