I decided to give myself a break from web-based development/programming to get back to game programming. I use to provide web-development services under subcontracting but I got out of it roughly four years ago due to my lack of passion for web-development. The passion was slowly destroyed by my passion to make and program games.

Beretta 92FS - Facing the sky for better lighting in this dark test map

It’s time to go back to the weapons and tackle a problem I honestly didn’t predict like I should have but I was so concentrated in all the mechanics before going right into producing another promotional video/demo that I simply didn’t have the time to predict this potential problem. Multiple weapon types or styles.

Functionality is extremely similar between all weapons, it’s only the small details that have to change, such as a semi-auto fire mode only for pistols instead of fully automatic like a rifle. However, there is one huge difference between even a pistol and a rifle. The arms, hands, and their positioning. Drastic differences. For first person view this isn’t much of a problem since each weapon can define it’s own animation sets but third person is a different story. You don’t change the player just because they changed a weapon.

The way I’m going about this so far is just by swapping out the Pawn animation sets based on the weapons style (Pistol, Rifle, Submachine, Lightmachine, SniperRifle, Shotgun, and Melee) and may possibly even swap animation tree’s for more flexibility. I have this swap taking place immediately when the weapon is replaced (usually through equipping and unequipping). There are still tests that need to be done to ensure this method works properly without further improvement but I have my plans set to a different task at the moment.

Beretta 92FS Third Person

Beretta 92FS Third Person Aiming

This issue I didn’t notice until I started adding the new Beretta 92FS and it had it’s own set of animations (including it’s own animation set for organization purposes and what proposed the weapon type/style changes discussed above). There are/were several mechanics that relied on timing before performing another action. An example would be firing the weapon and then returning to weapon idle (weapon idle is “injected” so no matter what type of idle; walking, iron-sight aiming, etc., going back to idle works perfectly fine). It technically needs to wait until the end of the firing animation before going back to idle or you’ll notice a hiccup or snap when switching animations.

My overall plan is to eliminate timers all together (except for a few that rely on timers, such as reloading, or equipping weapons) and rely on a few things. In place of “SetTimer” I use instead “AddDelayedAction(AnimationName, FunctionName).” This custom function simply works with a dynamic array which is then used within the “OnAnimEnd” event and then triggers the correct action based on what animation has ended. This makes these delayed types of actions reliable since they are executed at the correct time and it’s no longer guessed with timers.

No more time to blog now, I have to get this weapon class rewritten, because there is more I have to do than what I’ve explained, but the hardest part is finished (the overall planning on how to eliminate this situation).

We’ve now settled into our new home, finally finished this website enough to be some-what presentable, and now it’s time to post our first development blog. I use to blog at another website about development progress on R.A.T.S. because I felt the need to blog (to basically put my thoughts down) and we had plans to do this but hadn’t started yet at the time. Well, now I get to start blogging again, and at the correct location for the topic. This is much better.

Well, I’ll start from the beginning. My name is Paul, as you’ll notice from the author information, and I’m the Lead Programmer for R.A.T.S./Magic Stone Studios, LLC. I’ve been programming for a total of thirteen years, from web-based to software based, and nothing is more visually rewarding than game programming. Especially for people like me whom have grown with games since the Atari. It’s my job here to build R.A.T.S. from the ground-up and that’s what I’ve been doing.

Most people don’t know, or wouldn’t even notice, but directly after E3 I had started the R.A.T.S. project from scratch. Jamie (owner of Magic Stone Studios and R.A.T.S.) had been on the project by himself for roughly three years before I joined. My first task was to prepare a demo for E3 and we had two-and-a-half weeks to do just that. I had extended the Unreal Tournament 3 framework to save time and that isn’t exactly ideal for a final product. Therefore, after E3, I began creating the new framework, and planned around multiple features that we would need (not only for R.A.T.S. but for future projects as well). After almost a month into the process I had started blogging the progress.

And that’s the brief history. Time to begin blogging.

Today I worked more on the weapon cross-hairs. Overall there is more work to be done but how everything is working right now isn’t bad. The hardest part is trying to work with the bullet spread value, convert that to pixels for flash, and then try to match those together. I guess it doesn’t have to be extremely accurate but close enough should work just fine. At the moment it falls under the “almost close enough” category.

Dynamic Crosshairs

Dynamic Crosshairs: Spread

After this I need to move on, I’ve already sidetracked myself doing these cross-hairs but I also considered them “normal mechanics,” at least enough to convince myself that it’s standard mechanics and belongs into the framework by default.

A few blogs back I talked about using a different way of performing the aiming trace from the weapon to it’s range. It was to increase accuracy and allow us to manipulate the weapon in any way and the aiming would change automatically. Well today I realized that it had another benefit that I didn’t see until now.

Due to how everything works, accuracy with range is varied, between all weapons. If you were to “sight” your weapon for medium-range, then long-range would be inaccurate for the cross-hairs. Not by much but technically a realistic amount. One day I’ll have to demonstrate this but for now I think it’s cool. It means we can allow players to adjust their weapons sights for specific ranges.

Figured I’d post a screen-shot along with a short video that is shown below.

Right now the cross-hairs only move when shooting or moving your mouse. I still need to add when you sprint, jump, and more importantly, walk. The plan is to have the cross-hairs disappear when they cannot be used, such as when jumping, sprinting, reloading, and when using iron-sights.

I’ll be working on that once again when Jamie returns to help out with the Scaleform.