Missiles are now functional. The lock on process and launching process are complete. I added a "float" timer to the overall process. Basically, it takes ten seconds to lock a missile to target. Ordinarily, this requires the player to hold a "mouse over" of the target for the full ten seconds. The "float" timer allows the player to lose contact between the mouse pointer and target for a few seconds. Currently, three seconds is the amount of time a player can "float" a lock. The ten and three seconds rule will probably change after AI routines get developed, and I get a better picture of the speed and feel of the game.
There are two issues with the missile script. First, I have not developed a good method to inform the player of what is occurring in the locking process. Second, the missiles have no AI associated with them; they just travel in a straight line like a bullet.
I want to put off dealing with AI routines for now, and concentrate on a user interface.
Currently, the player's viper if flyable; however, you have no idea of your speed, the amount of fuel remaining or the amount of damage sustained by your viper. You can fire bullets and missiles; however, you don't have any idea of how many bullets or missiles are left in inventory. There is no radar (or dradis as it is referred to in BSG).
So, next up is the Heads Up Display.
First, I want to replicate the general features in the older prototype. This includes a radar screen, a f-scope display (like a radar but more height oriented), a targetting camera and a display for fuel, fuel rate, structure, bullets, missiles and countermeasures. I'll use the general processes employed in the previous build and am not too worried about this prospect. I will create a new class called an identification manager to handle what the old "heatsource" class did in the older build. Instead of using Unity's built in tag system, I will be using a faction, type and size variables to help track objects. Size will be a new concept and will be used heavily in future AI routines. It's non-existence in the previous build really hampered creating a viable AI system.
In addition to previous build's HUD features, I will manipulating the mouse pointer and making it an integral part of the user interface. Instead of the standard mouse pointer, the pointer will be a target crosshair. When it mouses over a target, the pointer will change depending on circumstance. Mousing over a friendly (same faction) target will result in a change in mouse pointer. I'll have to come up with a pretty "you can't target this" picture. When mousing over a targettable object, the mouse pointer will disappear or become much smaller. A target recticle will be placed over the target. It will display the lock timer. If the mouse pointer leaves the target during this process, the mouse will change and the float timer will be displayed as part of the change. After obtaining a lock, a different target recticle will replace the "locking on" recticle.
Dealing with the mouse pointer and it's proposed features worries me some. It shouldn't be too hard; however, I can see a few issues that can make this potentially difficult. So, the plan of attack is to get the old features into the new build. After that, I will implement the mouse pointer features.
Once I get the graphical interface functional, I'll probably feel more comfortable releasing some images.
great progress - it would lovely to see screen shots embedded - if you generate webplayer versions of these interim developments I would be happy to host them to allow you to get feedback from me and others on the interim states of the game - reading just the text without actually playing seems like it's hard to give good feedback.
ReplyDeleteEven if you think you can't get good feedback on interim builds, at the very least it would provide a specific record of different versions of the game playable at different stages - would also love to see the code in github or similar so that other learning game makers can get in there and see more of the choices you are making.
Overall I still worry about the complexity of the game. I managed to play the tutorial mission the other day, but it seemed like some of the key concepts that I had trouble with (like the max speed concept etc.) were not the things I was learning about in that tutorial. Of course more tutorials can be added once the game is finalized, but then again you want to be able to train up lots of testers to where they can give you feedback on the issues you are struggling over :-)
I'll probably be adding screen shots after adding a HUD display. Things look too ugly without them, and without any good screen data it's just hard to see any feedback being good. Once I get this batch of code comcpleted, screenshots are a definite occurence.
DeleteI like the idea of iterim builds and will definitely make that happen. In addition, I'll be adding code. Your correction to my attempt at syntax highlighting will make presenting code viable. When I don't have a significant update due to homework or tests, I'll try to visit an almost complete class and display the code.
While you are worried about the complexity, I thinking of revamping the thrust mechanism in the game due it just not feeling very BSGish. I think the revamp can address some of the complexity problems too. I'm not really at the point of doing the revamp though. It'll probably involve a slight change in the AI input routines; so, it'll get done before I work on the AI. I want to get good data on the screen before going back and working on the manuevering stuff.