According to conspiracy theorists, Solar Warden is an ultra-secret project that maintains a fleet (or several fleets) of spaceships that are operating within our solar system. Some say they’re defending us against alien threats.
This is the Development Blog of Dan Tracy's Indie Title - Solar Warden. Follow him as he chronicles his solo development of his Unreal 4 title.
So for January I've been working on some Wormhole tech and got pretty far with it.
These wormholes are not the usual 2D Portals that you see in "Portal" or all of those other tutorials out there for Unreal, but rather more like the move "Interstellar" with a 3D singularity. I wanted to make it feel like the Player or other objects are being pulled into the Singularity and then spat out at the destination that I am rendering in real time. Since the tech worked out really well for a First Person Shooter mechanic, I may in the future release a different Indie title that focuses on this bit of Tech.
Since making this tech, I've also ported it over to Solar Warden and got it working for the most part with the Space Ships.
For the game, this will be near End Game technology that the Player will unlock so they may travel quickly around the Planet rather than using their Mag Drive, as well as an important plot point in the story (NO SPOILERS!)
I'm very excited to have now gone through the Unreal Marketplace submission process. Was actually pretty simple. I'm looking forward now to making some more stuff for the Marketplace just to expand on things to sell.
This last week I've been working on setting up the Dissolve Gradients for UE4 marketplace. Since this was something I wanted and needed for Solar Warden for the Damage Shaders on the hull of the ship (and for later effects like Shield Destruction).
I figured that other projects would be able to utilize this as well. As of yesterday, I've submitted these over to Unreal Martketplace and now waiting to hear back.
Description
Create Dissolving or blending materials from these master material templates. Include any color you wish to the dissolving gradient by changing the parameters on the fly. Noise Maps can either be computational for high quality, or put into a noise map texture to save on performance. Noise maps can also be animated. Examples include melting metal, corrosive acid, dissolving Water/Bubbles, even Ice and Lavastone material examples included. Perfect for Damage Shaders, Weapons/Spells, Enviroments, VFX, etc.
Technical
Number of Materials:
- 5 Material Functions
- 3 Dissolve Master Materials
- 1 Basic PBR Material for reference
- 30 Dissolve Instanced Materials
Do Materials derive from a Master Material with instances as variation: (Yes/No):
- Yes
Number of Textures:
- 19
Texture Resolution (complete list):
- Noise Maps are 1024x1024
- Hull textures are 1024x1024
- Lava Stone textures are 2048x2048
Engine Compatibility:
- UE 4.13 and later
Intended Platform:
- Windows, Mac, Consoles
Platforms Tested:
- Windows (Win 7x64)
Documentation Included: (Yes\No)
- No; Material Parameters are self descriptive
Important\Additional Notes:
- Highly-customizable
- Noise Maps can either be computational or set as a texture to save on performance
- Gradients do not require textures and can be switched on the fly
- Possible Animated shader
- Swap out your PBR textures in Material Instance
- Dissolve can also be used to blend between PBR Textures.
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.
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)
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.
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.
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.
