Post news RSS Fullscreening and Unit Behaviors

I have been quite hard at work creating my unit level AIs as well as optimizing the game code. I eliminated several useless instances of variables (for example, in the scaling code I removed a boolean called hasAlpha = true which was only used at if(hasAlpha)...a rather worthless use of a boolean).

Posted by on

Since Last Time
I have been quite hard at work creating my unit level AIs as well as optimizing the game code. I eliminated several useless instances of variables (for example, in the scaling code I removed a boolean called hasAlpha = true which was only used at if(hasAlpha)...a rather worthless use of a boolean).

Unit Behavior Fitting
I have never played an RTS where you could specify HOW a unit attacks a target. It always had been building fairly static units that have one rigid combat behavior. That's lame. So, one of the goals of BoS was to allow some freedom in customizing unit behaviors.

Note: This video contains demos for all 3 unit behaviors, watch the entire thing.


Fullscreen Support
Up until 2 days ago my game always ran in a 1024x768 window. It was good to have a rigid screen size while defining the elements of the HUD, but BoS has grown up. Now it will automatically detect your current desktop resolution, enter fullscreen mode, and scale the backplate and HUD elements to their correct positions!

Here's a look at BoS running in 1680x1050 (Right Click and View Image for full resolution):



Running in fullscreen gives the game a professional look. Very few people play an RTS in windowed mode. The best part is the backplates have been totally redone. The old 1024x768 backplates are now 1440x1080, and being at such a high resolution allows them to scale without any noticeable quality reduction.

Optimizations
I have a very bad habit of making every variable a public one. I went through and redid the scoping of all my variables at a small, but important, 1.7fps gain. I also changed all my public and private methods to public final/private final. The "final" keyword has the effect of locking the method so it cannot be changed at runtime, which makes sense because you never rework methods at runtime (on the other hand, setting an important variable to final would mess the program up horribly). This also provides a small performance gain.

Current Goals
The unit combat fitting is done. But those are not the only important unit behaviors. Other ones that control things such as when to disengage and run, or what to do while idling, will also be changeable. My game will be very unit-level AI oriented. But first, I want to get the computer building frigates as well as add a "loop production" option (and rally points) for player factories.

For those of you who are irritated the game is only 2D, and programmer-art 2D at that, just remember that this will be the deepest and most customizable RTS ever made.

Comments
RagnarokX
RagnarokX

Perhaps you could add a little more description about the simulation. like, what the player has actually to do when playing (research ? just build ?)

Reply Good karma Bad karma+1 vote
masternerdguy Author
masternerdguy

no problem.

The objective of the game will be to take out your opponent's starbase and all their subordinate starbases orbiting other planets. There are currently 6 planets in my testing map, each player starts with one and the others are neutral (there are two players in the testing process).

By capturing planets you gain increased fleet capacity. Unlike in games like Sins where when a unit dies its crew is returned to the fleet capacity pool, they actually die. This means you rely on a constant rate of recruitment, and having more planets increases your recruitment rate.

You start the game with all available units buildable, which is unique in the RTS world. The research system involves picking an area of research, say Missile Operation (15% bonus to missile flight time per level), and researching it. Researching takes exponentially more time to train up to the next level and has a failure chance. If it fails you restart that tier of research. There is no cap on how much you can research a specific area, only the time investment constrains you.

Remember you can fit your ships with different weapons, the units do not come pre-fitted. This means you should research things you actually use. Some ships have bonuses derived from research, for example the Sabre will have these bonuses:

Frigate Operation: 10% increase in shield HP per level
Frigate Offensive Systems: 5% increase in gun damage per level

Whereas the Dagger has these:

Frigate Operation: 15% bonus to max velocity per level
Frigate Offensive Systems: 5% increase in missile damage per level.

There's a lot more to this game, I intend to add a planetary construction minigame where you install facilities and defenses on various places on the planet, and other things.

It's a limit breaking project, I am trying to make the gameplay deep and highly customizable.

Reply Good karma+1 vote
Warrozo
Warrozo

I noticed your bullet's travel in a diagonal line.. Do you need some code to make them travel directly at the target?

Message me if you do :)

Reply Good karma Bad karma+1 vote
masternerdguy Author
masternerdguy

if you are referring to using a vector instead of simply diagonal lines, I know how to do this. I just haven't done it yet. That's very low on my priority list. The bullet movement code is totally contained inside the Bullet class and can easily be changed at any time without having to change anything else.

I am aware of the process of calculating a vector and extracting a VelocityX and VelocityY.

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.