Oct updates catchup - Alien and Gameplay Updates

Grubs and other Aliens
Along with all the weapons and backend updates this month. The Aliens are progressing nicely.

First, we have the Grub that has had it's Fusion Beam weapon plugged in.

Alien Fusion Beam

In this video, the Grub spawns from a different Asteroid and fires a powerful beam at the player. This demonstrates that any of the new weapons created can also be applied to the AI as well. Along with the Fusion Beam on the Grub, the Player in this video is equipped with Blast Cannons! These cannons are an automatic shotgun that are great at close range. Also for added effect, I've opened up firing mechanics to have a setup for camera shake to give more feedback to the Player when they are firing powerful weapons.

Further to the Grub, we have created some concept art to be forwarded onto 3D artists to make a high end version.

Additionally, some Whitebox has begun with some of the additional Alien enemies. Here is one of them

Exploder Whitebox

This creature has expandable sacks that are filled with a gaseous compound that can detonate with a high yield of explosive power. These creatures will attempt to fly into the Player and detonate within rage of their explosive blast range to deal massive damage to the Player. They are usually found in swarms.

Oct updates catchup - New Modular Weapon System!

Modular Weapons! - This back end writing on the weapon system has allowed me to split the weapons into the following modules for me to play with.

• Charge Modes
• Fire Modes
• Shot Modes

The reason for making this whole system was mainly to allow me to create new weapons easily and efficiently. So what do these modules open up? Well, here's what I can do now with each of them.

• Charge Modes
• None
• Press and Hold
• Fire and Forget (Press once and charge happens automatically)
• Fire Modes
• Single (Semi-auto)
• Burst (Length of shooting time on Beam)
• Full Automatic (Continuous Shooting with Beam)
• Shot Modes
• Single Shot
• Shotgun (X projectiles)
• Beam

Allowing for a mix and match of any of these above + any projectile I wish, this allows me to make the bulk of common or unique weapons out there with these simple modes. For example I made a few here on the Player's Ship - Ion Beam and Burst Fire Missiles....

Ion Beam and Burst Fire Missiles

This system doesn't just work on the Player, but also the AI as well! In the next update, I'll show this working on the Grub to have him barf out a Fusion beam at the Player!

(reference)

But it doesn't stop here. Tons more weapons I'm planning on making...

• Blast Cannon (Automatic Shotgun)
• Gauss Cannon (Fire and Forget Sniper Rifle)
• Prismatic Laser (Beam Shotgun)
• Ballistic Gatling (Press and Hold Charge + Automatic shooting)
• Laser Gatling (Press and Hold Charge + Automatic Beam)
• Heavy Laser (Press and Hold Charge + Continuous Beam)

And that's just the start!

Oct updates catchup - Fixed time step and Max FPS

Fixed Time Step Rates - So one of the latest discoveries that I really should have thought about was to apply a Fixed Timestep to anything that measures values that are piped through a tickrate. What I mean by that is anything that's relying on Tick updates (updates per frame) like TurnRates, Speed changes, etc.

Since latest testing and optimizations allowed me to achieve FPS heights of over 300 in dead areas and perhaps <60 FPS in some extreme PFX/Light heavy areas, this wild variation in FPS made it very noticeable that Updates per frame were also being affected quite drastically. Relying on Frames when they aren't consistent will make those rate play differently both on the upper end or lower end.

FPS Difference in turn rate

As you can see in the quick video above, you can see the difference in turn rate between an unlimited FPS (turning super fast), vs a limited frame rate of 30 FPS (turning much slower). Easily made sense when you think about it. If the game only has 30 Frames per Second to process an X turn rate, then it would only update 30 times per second vs the 200+ FPS I was getting.

As you can imagine, alot of people might be thinking "Well, force limit your FPS to 30-60 and everything will run just fine", and this is perfectly acceptable to use when doing console development (Xbox, Playstation, etc.), but I refuse to limit my FPS when playing. Personally I would rather have an unlimited FPS so I might enjoy a smoother experience in my titles so there had to be a way around this. The answer that comes with this is to create frame rate independent comparisons with my rates to my Delta Time of the frame.

A great article can be found here...

https://www.scirra.com/tutorials/67/delta-time-and-framerate-independence

What this has allowed me to do is now allow for any FrameRate to occur in the game while making sure my values of things like "TurnRates" can remain at a particular speed I want for the Player to feel, eliminating FPS as either a Play advantage or disadvantage.

Frame Independent TurnRates

Then vs Now - March vs Oct

It's fun to look back and compare where you've been to where you are now.

While setting up Blogger and pulling over my 50+ Development updates of old, I realized how powerful it is to keep track of all of this. From my old days of Developing for Mech Warrior: Living Legends and heading that project, I already knew how important keeping up with those monthly news letters were for the fan base. However, Solar Warden is a completely different beast. Since I'm currently doing 100% of the work, it's really easy to just lose myself in just creating and developing without the need to document or chronicle the work being done, or write down about the lessons learned. Alot of times I felt myself digging deep into developing a feature and not really getting anywhere and it gets hard to come back to the same problem every day to see that problem that once defeat you waiting for you... watching you... However, I'm super glad I kept a small journal alive and made sure to write up the progress of each long work session (even if they turned out to be 2-3am). It really helped to remind myself of the progress I've made and a little bit of a confidence boost to push through the current problem and move onto the next.

Much like a hiker reaching lookout points and being able to see back down the mountain from which they came, I feel a huge sense of a accomplishment seeing just how much the project has changed and improved since my first builds in Unreal and also how much I've learned just by figuring all this stuff out on my own. I feel more encouraged than ever to spur on and reach the top of this mountain and bring Solar Warden to it's gold standard (to which I plan to push for perhaps a tentative February release. Don't quote me here :) ).

As a fun aside, I took the very first screenshot of development and made a comparative screenshot with my recent build just to see the difference between March and October. After standing back and seeing the difference, I must admit I giggled a little bit. But see for yourself.

I'd also like to take this time to tell anyone looking at doing game development to remind them that these journals are super important. Maybe you don't want to share them publicly, and that's totally fine, but build on and keep the discipline of writing development journals for yourself. Why? The reason is simple. It's always great to look back and remind yourself how far you've come and what you did. We Game Developers craft experiences, and an Experience is the sum of it's parts. It's a great pick-me-up and reminder of what these parts once were and where you've taken it from there. Also who knows, you may one day pass this knowledge onto other people that will greatly appreciate it and apply it  to their projects in the future.

Blogger Open and New Lighting

Testing out Blogger. This might be my new page for all of my updates regarding development posts until I can get a sight up and running.

Lately in Solar Warden development, I've been making some tweaks to alot of the lighting within the Level and working on bringing back in the Atmospheric fog.

This brought much more atmosphere (no pun intended) to the level without it being dead and a black night. With that, I also added in a much needed lens flare texture that overlays on the sun. This combined with a slight yellow tinted atmosphere fog really makes the space pop alot more. See the image below.

Development Update and small Rant: 10/4/2016 - Spensive Lights and FPS

Progress Update 10/4/2016:
- Fucking Lights! Cast Shadows SPENSIVE! So I had about like 10+ lights on the ship and wow I didn't realize how expensive shadow casting in Unreal is. Then again, they aren't differed lights and are probably full Dynamic. So what ever :D
-- I changed these lights all over to non-shadow casting, and went from ~26 FPS back to 114 FPS. LOL omg. My game runs too smooth
-- A side effect currently with the FPS being super fucking amazing shit hot or terrible (114 FPS or <30 FPS) is that Ticks are frame dependent. Herp-derp I guess that's obvious. However, what kinda isn't is that all the tick functions I do are also frame dependent. Meaning that all the functions that run off tick will run super fast with high frame rate or super slow with low frame rate.
- Found this Cvar "t.MaxFPS 60" to lock the FPS
-- I like the idea to push for a 60 FPS gameplay
TODO: Setup a fixed timestep for Tick Functions to 60fps assumption.

- Got Space Particles working. These are the ambient space dirt particles to give the impression that the player is traveling in different directions.
TODO: Video or GIF showing

- Tweaked up intensity of Milkyway (looks better)
- Changed cubemap of skylight to grey again for better low light visibility.
TODO: Tweak again and get a better cube map?

NOTE: Random screenshot before closing out for the night. It's a good sign that on a random frame of gameplay is screenshot worthy.

Development Update: 9/30 - 10/3/2016 - I'mma Firin Ma Lazors

Progress Update 9/30/2016:
- Ran into a bug with Aim Offset when trying to setup the lasers
-- This might be the cause of missing shots at extreme angles :(
TODO: Fix Aim Offset


Progress Update 10/2/2016:
- Fixed with Aim Offset being done now in world space as was being done in the Debuging of the raycast. I have since moved it to the weapons since the Aim Offset Relative was added with the Ship's rotation relative to camera which caused further offset than what I wanted
BUG: beams render a frame behind and don't use local space :(


Progress Update 10/3/2016:
- Workaround for Beam rendering a frame behind. Instead of using Unreal Particle Beams, I'm doing the MWLL trick of spawning geometry and then stretching it along one axis to achieve the effect.


-- Down side is I don't get the nice gradient of the laser beam material since I'm using a cylinder. I might consider switching back to a plane and then rotate it to camera like Beams do (isn't this just recreating beams though?)
--- I made a kind of work around for this too where I have tripled up the "inner white cores" within the outter cylinder and then had an opacity drop on the White Core material. This overlap on the differently scaled cores gives an illusion of a gradient being there for the laser, but might be expensive for the long run with alot of overlapping transparency...
TODO: Profile Lasers Transparency
TODO: Might eventually go back to Beams and look at how I can set these up with Simulated actors since the PFX on beams is much easier to make cooler beams than to do it with the geo.