BulletHell. [First Test Build]

edited in Projects
Since I can't just sit around hoping a gamedev job opportunity arises for me (mails sent all over, no one wants me, poo), and not making any money, I had to think of alternatives. A needed something I could build, make available for cheap (or ad supported), and hope it will be a gamble worth while, and do it fast before what's left of my minimal funds runs out.

Having no fresh game ideas I decided right off to begin building a 3d bullet hell game, which also saves me the time of prototyping or gambling on untried ideas. Also, various types of mechanics I would already be familiar with. Most notably weapon systems, turrets and the like. But my previous implementation was bloody complex: as the turrets then had to work perfectly when mounted on any position at any angle on any ship, even while the ship was upside down. This relied on a technique where a triplanar projection of points on planes were used to calculate the aim from the local perspective of a turret, and was expensive enough on it's own, not counting the targeting, tracking, and firing mechanisms.

Luckily this time round, weapons would be way simpler, as they will only need to work on a single 2D plane, no complicated logic needed there.

DAY 1: (Thursday : June 14)
- Started out with building a low poly fighter as fast as I possibly could. Skipping the UVS and textures for a later time. I wanted to go with a LEO (low earth orbit) style design for my fighters. Thus they will be textured with heat shielding and the like later.
image

- Day one continued with working out how to calculate the playable boundaries for the game for all devices. Boundary is calculated automatically using left edge of viewport. Camera will be pointed down in this game, but not directly down.
image

Blue: Boundary where the player can move within.
Red: Boundary where the outer edges will act is entry points of NPC spawns and waves.
image

Since desktop ratios have far more space than mobile, limits in bullet counts and NPC spawn numbers will be calculated differently between desktop and mobile builds.

For the desktop I also intend to add shared-screen multilayer, and perhaps some additional game modes or challenges.

Continuing on with day 1, I quickly created a small animated shader for my thruster effects, which relies on animated UV texture offsets and vertex animation, so no need to use particles for them.
image

Edit:
- A have made a build. It is not finished. Please see included readme as some UI doesn't exist yet.
https://drive.google.com/open?id=1L0rPgaQVg4dhXdCJxEnfHg-O4QEMhhhB


Thanked by 2pieter iceblademush

Comments

  • DAY 2: Friday, June 15

    - Started out with working out how control setups will work. I went with an approach which allows me to define scriptable controller profiles, for mouse, game-pads, whatever. Since I have no idea how the experimental input system works , I ended up creating a simple asset based equivalent for myself. Setting how a player is controlled in the end is as simple as referencing a controller asset for a player. For mobile I can simply replace the controller asset with a mobile equivalent, so I would not need to implement separate platform specific code directly in the player code itself. This also enables me to spawn multiple players on PC and assign a separate asset to each, one for each gamepad, or one player can use KB and Mouse, while the other uses a gamepad.

    In the end the control bindings are pretty simple, there is only "Move", "Shoot", and later (not exists yet) a Special Ability button (via power up). The absolute maximum number of control inputs required, is three (per player if on PC).

    The initial control asset (Mouse) is used to test the initial control logic. The first half of the day went pretty fast, but I was able to implement all of the control code for motion in one sitting, and even had time to integrate my thrust effects.



    The second half of my day was spent building all the base-classes needed for the player (and npc) weapon systems. NPC logic will require more variety, while the player just needs different behavior and upgrades.

    Using an asset based weapon definition, a system was created to allow the entire behavior of a weapon to be replaced on the fly, instead of replacing the actual weapon (so, no destroying). These "WeaponSetup" assets define everything from "barrels", what prefabs to use, colors, refire rate, burst behavior, etc. As assets this also means I can tweak them in play mode and have the changes persist to edit mode. The Weapon-setup assets have been written to "chain". Setting up unique weapon upgrade chain for each fighter is now a simple case of scripting unique bullet types, and creating prefabs. The Power up logic is simple - simply make a call which switches the weapon setup asset to the next referenced asset But if the player dies, restore the original setup.

    The cubes in the video below act as Test Power-ups for upgrading the player's weapons. Currently there is only one channel of weapons for players, but there will be three in total (per ship) later, indicating that three types of weapon power ups will exist for each ship - thus three chains of weapon upgrades. (Projectile/Beams/Missiles).

    For simplicity, all weapons will always fire from one button input only. Only a special ability later will require a separate input.

    Best of all, the weapon implementation operates only from the root game object of the player. In total, there is only one game object (and two scripts), actually attached to the player.


    Future:
    - Wave/Spawn management, incremental difficulty, and generic NPC spawns.
    - Define BH Style NPC Weapon Behaviours: Generic, Tracking, and Pattern Based
    (eg: sweeping arcs of bullets).
    - Come up with a way to easily implement dynamic path definitions for various NPC spawns:
    (EG: NPC sweep in, do a loop, and exit if they haven't died).
    - Complex NPC spawns.
    - More...


  • edited
    Completely random note, but these things are called "Shock Diamonds".
    image
    They are caused due to shock waves bouncing around inside the exhaust fumes creating areas of high (hot) and low ("cold") pressure.

    It's also one of the coolest names for a natural phenomenon :D
  • pieter said:
    Completely random note, but these things are called "Shock Diamonds".
    That's neat, I always thought of them as "that afterburner effect". :X.
    Thanked by 1pieter
  • DAY 3: Saturday, June 16

    Thanks to loadshedding no time to explain.

    Anyhow, day 3:
  • @MoruganKodi nice rapid progress. I don't want to give feedback too soon, because you probably already have a long list of daily things planned so I would just be stating the obvious. I like 0:45 where ridiculous amounts of bullets start flowing.
  • edited
    Hmm day 4.

  • edited
    Pretty good day:
    - Implemented Formation Support into spawn groups.
    - Improved Boundary Spawner, and it now gives player a bit of "fresh air" periodically.
    - Group Stacking (bearable).
    - Implement Health module for player and initial UI.
    - -- Player has Hull/Shield and Capacitor (because intended to be set in my ProjectOS universe).
    - -- UI Has indicators when shield and cap is charging.
    - -- Capacitor can be used to boost weapons or shields for short period (no visual indicator yet for shields).
    ---- Lives (no visual indicator yet, but UI has indicator).
    ---- NPC weapons less random (more predictable).
    ---- Up to 12 spawn groups can be active at same time (adjustable).
    ---- Other Things.
    ---- Code for 8 powerup types (+ manager, not tested yet).


    The Weapon Boost ability can be seen in video.
    Shield Boosting works too, but I need to setup some visual indicators for it first.
    Thanked by 1konman
  • edited
    Most of my core gameplay things done. Now I can start shifting my attention to other areas of development in here.
    Later on I can go back and add more spawn behaviors and npcs (and bosses).
    And my own game kicks my ass....
  • Something I think is interesting here that I don't see a lot of in Bullet Hell games is that you can shoot projectiles... making your attack both defensive and offensive.

    (Maybe I'm massively in Bullet Hells, but this seems like an interesting avenue of exploration/differentiation to me)
  • Yes. Shooting bullets was important for me from the beginning. But also, some bullets can be marked as indestructible (note: pink and green projectiles in last video).

    My mechanism also supports only one of two projectile being destroyed under certain scenarios:

    EG: Currently only used by boosted weapons - boosted projectiles can hit a bullet and ship but not destroy itself, allowing boosted bullets to pass through and damage multiple enemies in its path, but they do not destroy indestructible bullets either. Though this ability can only be used if the player has capacitor.

    I am trying numerous differences to other bullet hell games, mainly in the area of player health:
    - Player has a Capacitor, which can be used for short shield boosting or for weapon boosting ability, boost fails when player has no cap. Capacitator has a slow recharch.
    - Player has a shield. Shield has a Regen (which can be turned off in difficulty settings)
    - By default, the player gets one life and a spare life currently, and can collect up to 3. (but this will be changed) in favor of...
    - By default: Drop chance for lives is only 0.001% atm, to favor shield management and shield boosting.
    - By Default: Hard Difficulty Setting has ZERO lives, yet the play must survive 60 minutes to beat the game, the game becomes progressively harder.
    - There are level up bonuses for shield, cap regen, and powerup spawns.

    At's kinda hard as hell to balance everything atm.
  • Today I begin texturing the first shuttle-fighter.
    image
    image
  • edited
    ...And finished... though I am beginning to feel like I suck at this.
    image
    image

    ... and setup in Unity...
    image
  • Looking good. Can't wait to try out the demo.
  • Development Video 7.


    Some batching mechanisms implemented. Added planet (placeholder, the shader is shit so will be replaced later). Some menus implemented, but not recorded.

    ++ Some sounds and audio placeholders (forgot to record with desktop audio on, so I overlayed music on video instead).

    ++ It takes 60 minutes to leave LEO (low earth orbit), to see this you have to somehow survive 60 minutes (the only way to beat the game, there will be an objective to complete at this point later).

    ++ Dust Mote Parallax Effect (background).

    ++ Still trying to rebalance/balance powerups and spawn rates of the current NPC grouping mechanisms and player survivability. Which is turning out to be pretty tricky.

    I'm now working on implementing "mini bosses", which will have layered health, and will navigate waypoints, have multiple weapons, etc. These will be referred to as "Officer Spawns".

    I will need to also need to build a quad batcher for displaying healthbars on all damaged NPCs as well as display miniboss and boss healthbars.
    (Using GUI for this would be junk on performance, healthbars will all be rendered in only one draw call via already existing quad batching mechanisms which exist in my framework).


    Luckily, adding custom batchers is really easy as I have created various baseclasses to simplify the process.
    Having a reusable framework which you build and update across many projects makes life easier in the long run.

    So implementing my particles was this easy.... (Mote.Update handles positions).
    image
    Thanked by 1konman
  • This game really wants to kill you. (And initial mini-boss added)
  • edited
    Mini bosses and Bosses get layered health bars.
    A new pooling mechanism has also been permanently added to my framework for all future projects, which currently handles the damage and point labels which spawn around the player or dead npcs.
    All bullets will be updated soon(tm) to spawn through the object prefab pools.
    image

    I have redesigned and re-implemented the Player's Indicator UI elements.
    Using rounded health indicators help save some space. The element is resizable.
    Designed to stack side by side (up to four of them) for shared screen multiplayer implementation later.
    image

    The frame of the bar will blink (as well as the organge "damage" blinker) with greater intensity as the player takes additional hull damage.
    image

    Still more UI things to do. But I think I am getting closer to being able to build out a early playable demo.
  • edited
    The second Player Selectable fighter craft. For the time being there will be only two fighters.
    Textures are work in progress.

    image
    image

    Prototype Description for selection screen (lore):
    - The <fighter_02_name> is a Federation designed non-atmospheric heavy fighter which entered service shortly before the beginning of the first revolutionary war, also Man's first ever Interstellar War . This is one of the first ever space craft designed purely for combat in space, a solid platform against earth based Shuttle like fighters.

    The <fighter_02_name>, like most other advanced Federation spacecraft, was far superior to their earth bound counterparts of the UNC. In space Hybrid Fighters of the UN struggled to match it in combat, however the <fighter_02_name> is incapable of flying below a planet's stratosphere due to lack of thermal shielding and must recovered by a larger spacecraft.

    Development of man's first ever Carrier was developed by the Federation to provide a platform for launching and recovering the <fighter_02_name>.

    The fighter's lack of atmospheric flight capability however allowed development of more advanced shielding against hostile weaponry, unlike Hybrid Fighters which require thermal shielding for earth reentry - have very weak structural resistance against weaponry once their positron fields fail.

    Before the UNC's defeat at Mars, various <fighter_02_name> wrecks were recovered by the UNC. One reverse engineered on earth, the <fighter_02_name> became earth's first pure space fighter, but by this time the fighter was now considered obsolete by Federation standards. By the time of the invasion of earth by the federation, the UNC only has one operational carrier in service to accommodate the earth clones of the federation craft, and thus very small numbers of the <fighter_02_name> are use by earth bound forces, forcing the UNC to rely heavily on inferior Shuttle Fighter hybrids, while the Federation operates a near infinite supply.

    [Traits]
    - Powerful Reactor: Fast Shield Regen, but reduced capacity.
    - Pure Space Craft: Enhanced Structural Integrity.
    - Federation Technology: Advanced Default Weapons.
  • Rapid Texturing ftw...
    image
    image
    image
  • edited
    If I can make a fairly arb suggestion: Since you're already in "desperate enough to try anything" mode, already busy building a game, and already posting videos of the game as it develops, consider actually doing some narrated videos of your work process. You could be turning this into a series on building your games, that may actually grab someone's interest. This could be positive for a couple of reasons:
    -You'd be learning new skills in communication and creating the videos
    -You'd be building an archive of your progress to look back on, which can be super motivating
    -It's a long shot, but if you do manage to gather enough interest, perhaps there's some ad revenue in it for you
    -It's something to set you apart from other developers
  • First test build available.
    - If possible I need some feedback.
    - How far do you get (what is the lowest remaining kilometers when you run out of lives, in which ship?).
    - - Are you able to make it past the 2000km mark?
    - Please stick to default difficulty settings, as this is the difficulty everything will be balanced against.
    - Any bugs? Any Crashes?

    A readme file is included in archive containing notes and control info, please read first.

    [DOWNLOAD]
    https://drive.google.com/open?id=1L0rPgaQVg4dhXdCJxEnfHg-O4QEMhhhB

    Latest Screenshot:
    image

    NOTE: I haven't added a "GameOver" ui or "Pause UI" yet, so for now you will need to Alt-F4 to quit (sorry, but please bear with it honey...).

    The game will start off slow and relatively easy, but after the first miniboss things will pick up.
    After the second mini-boss it will be very hard to stay alive. (there is only one miniboss so far, so it will be the same every cycle). Part if this is due to other NPC types not yet created, and some part due to some spawngroup behaviours which do not exist yet.

    Conserve you weapon boost ( Key "1" above QWERTY ) until you really need it, currently the boost is OP as hell, regular weapons will take time to kill a miniboss, but if you are able to boost, you will make quick work of it, but having no capacitor at a critical moment will probably get you killed. Cap has a slow regen. But if you are lucky, a powerup for charging part of your cap will drop.

    If you are extremely lucky (literally in the 0.001% rng chance), a life may even drop.

    I am struggling to survive now at this point, so not sure if there will be any more builds, but if anyone has a Linux or MacOSX machine please let me know, I would like to build for those platforms as well.
  • mattbenic said:
    If I can make a fairly arb suggestion: ... stuff
    I could try that, though I have tried being narrative before and keep finding myself a somewhat microphone shy in videos (odd, as I have normally had no problems talking in actual online games).

    But if I can, I think i'll give it a shot.

  • @MoruganKodi Looks awesome so far. It's definitely hard, that's for sure. So to preserve some self esteem I won't mention score :D

    Some very initial thoughts/suggestions:

    1) The UI at bottom could be a bit larger. I found it a bit hard to read. Maybe just old age on my part.
    2) The lerp speed between ship position and mouse pointer can be increased. I felt like I lacked a bit of ship control.
    3) I would like if my bullets didn't collide with incoming projectiles. (would make it easier though, so it's down to personal taste)
    4) Code in void Update() somewhere... "if (Input.GetKeyDown(KeyCode.Escape) Application.Quit();" :-D

    Thumbs up, I like. Will play some more...
    K
  • @konman
    thanks for feedback. I don't really need a score. I just need to know what the remaining distance is. (top of screen) when you run out of lives. The score will vary heavily based on how a player plays.

    Killing more ships with high hitpoints results in higher score, but since they are harder to kill - the chance of powerup drops is lower. I do need to work out how I am going to score remaining distance though, or perhaps even award points for picking up more powerups.

    Though score exists, the actual important statistic is how far a player can go before he dies. I want to add distance based achievements and rewards to encourage this stat specifically.
    While on the flip-side, killing more low HP targets results in faster killing, but less points with higher powerup drop chance due to the RNG being triggered more often.

    Adjusting all these little bonuses has actually been a pain to get close to balanced: :o.
    (...play, test, tweak, play test tweak play test tweak play test tweak... bugfix... play, test, tweak, play test tweak play... twerk....).

    Hints
    - Killing more lower HP enemies gives you higher probably of powerups, but less points and slow player EXP gain for leveling up.
    - Killing Higher HP targets give player more exp, thus faster level up, which increases shield and capacitor recharge rates slightly (currently 1% per second per level of total capacity). This means a level 10 player may have a 10% increase in regen, but this can also be tweaked per ship to favor a specific role.


    Player Control
    - The lerp speed isnt actually a lerp, it is rigidbody motion, currently the ship's speed (Agility stat on Select Ship page) determines how fast the ship catches up to mouse input using the current input handler.
    When I implement interchangeable controls the ships should move at the same speed for all input modes (keyboard, gamepads, etc...) so mouse users don't have a big advantage over other input types, and prevents mouse users from teleporting their craft across the screen.

    I think the speed may feel slow because most bullet-hell shooters usually have a vertical play area with fewer npcs, where on landscape boundary the player has far more distance to move (but also more room for way more npc spawns).

    UI. I will have a global setting at some point which will simply will upscale the canvas. But since four of player indicators will be needed later there is a limit of maybe 120%.
    However I will also have to make the players movable boundary change as well. (larger UI = less space for player movement). But I will also look into alternate fonts which may be easier to read.

    Bullets. Don't worry, only limited NPC types will use indestructable projectiles. These exists as a fully upgraded ship would be able to blast a free hole through all projectiles when boosted, which would make it way too easy to survive until the end. Though currently 3 out of 5 NPC spawns use them, so for now there are too many indestructable projectiles in use.
    As I add more generic NPCs the ratio of destructable versus indestructable projectiles will be balanced out as most NPCs wont use them. Turret type NPCs will always have them, and most bosses.

    When huge walls of indestructable projectiles are fired, it would be ideal to stop shooting and concentrate on taking as little damage as possible (especially in the second ship [SF-2], because it has a tiny shield capacity, it has a faster movement speed than the SF-1, but hull hitpoints do not regenerate over time).

    Other random things...

    I intend to add more player ships to favor various playstyles later.
    The SF-1 is a all rounder with lots of weapon spread and a medium shield, and wide weapon spread.
    The SF-2 is a hull buffer tank with mainly concentrated firepower, and when fully upgraded will send cluster projectiles flying everywhere.

    The H-2, when ready, will have powerful lazors (which will be immune to invincible projectile walls). I haven't decided on a weakness for this unit to counter balance that advantage yet.

    Ship Roles I wish to fill: I wanted to implement two variations of each role one favoring shields, one favoring hull.
    [Superiority Fighter] All Rounder (currently the SF-1)
    [Heavy Fighter] Currently the SF-2, though it is more agile than the SF1. Hull Tank.
    [Heavy Fighter] H-2 (Fed SF-2 Variant) (currently disabled). Weapons not implemented. Shield Tank. Cluster Projectiles
    [Interceptor] Pure speed unit with huge capacitor, but little to no defenses.
    [Heavy Assult] Some kind of glass cannon unit. (DPS is your tank, your only tank)
    [Heavy Bomber] Some kind of pure tank unit (slow , heavy, tank)
    .... others?


    -- Note:
    the Cluster weapon's projectiles (on slot 3) on the SF-2 can pass through the walls of indestructible projectiles and explode behind them, with a fuse time between 0.1 and 1.5 seconds, allowing it to damage NPCs currently blocked by indestructible bullets, though the cluster spread on these projectiles is currently set to a full 180 degree arc ,
    I should reduce it to 90 (-45 /+45) so the projectiles can provide more concentrated damage to any NPC in front of them.
    When fully upgraded you are shooting 7 of these cluster bombs at the enemy every second, so if they detonate close to a weak turret they can sometimes guarantee a kill. I will probably increase the weapon damage for this weapon later.

    -- Note to self: increase drop rate of hull repair powerup slightly.

    Thanked by 1konman
  • I played a little, some thoughts are below.

    [-]Have no idea why the game is over 500MB when extracted, for the amount of content I was expecting less than 100MB.
    [-]Like your UI at the beginning and the ship status indicator in the game, all those stats are juicy, however the in-game UI is a bit too small.
    [-]Music is fine, it adds a lot to the game.
    [-]With the first weapon the game is very slow, it took me a while to get an upgrade.
    [-]Player bullets shouldn't die when hitting another bullet, or they should destroy a bullet that they hit.
    [-]Because of the bullet destruction, it's smarter to just let some enemies pass rather than engage them.
    [-]You could bind some abilities or functions to [WASD], the left hand is just sitting there doing nothing.
    [-]There wasn't really anything besides the KM counter on the top pulling me forward, I died at around 3.5k left.
    [-]Indicating which ships carry upgrades would be great, make them glow or shoot special bullets.
  • Made it past the mini boss. Yeah baby! 3614 km... then there was some void sucking happening :D
  • ya. 500MB is mainly textures and audio. Many audio clips not in use yet. Unity doesn't seem to strip out some unused resources on build. As the project progresses it will only get bigger at this point.

    By default Unity's Postprocessing stack eats up 30MB by itself (those bloody lensdirt textures).
    I actually forgot about this one.
    I am not using lense effects or LUT so I can go ahead and delete those.

    The Planet (earth) itself is 7 channels of 8K textures - which alone currently weighs 126mb for 7 channels of texture data (for PC targets). I replaced the previous earth asset the same day I uploaded the game with this planet included, but haven't added a new shader, so for now it is rendered with just the standard shader.
    Mainly because cartesian sphere mapped planets when viewed close do not look good from any angle.
    Textures with alot of color/variation or detail don't compress very well.
    So the albedo channel alones comes out at close to 50mb, while the roughness map with only two shades compresses down to only 2MB. This isn't even counting Mip Maps yet.

    Luckily, this will be the only planet ever to be added. No other texture resources will come anywhere near this big.

    Once I create a new shader to render the planet, I can pack it's Height/Emission/Metallic/Roughness into a single texture and have the shader handle those as a single channel.
    AO and cloud maps can be packed as well later. Additionally I can calculate normals from heights directly in it's shader, which will allow me to remove the normal map as well.

    Once I get around to writing a new shader for the planet I can reduce it from 7 to only 3:
    - [T0] Basecolor (pack heightmap in alpha)
    - [T1] Packed: emission/ao/metallic/roughness
    - [T2] Cloud Maps in R and G. B and A unused.

    But we would still be looking at up to 40MB for each of the 3 textures for desktop platform (not counting mipmaps) due to many colors existing in the textures. They will still weigh in at least 100mb.

    For player selection screens, each fighter of the current two meshes has 6 channels of of texture data (they are generated at 1024x1024, but set to 512x512 via import settings).

    The SF-1's alone consumes 17mb.
    The SF-2 and H-2 combined use 24mb (the two ships share 5 channels of data, but have seperate textures for the albedo channels due to seperate "paint jobs").

    Based on this, every time I add a new fully textured player ship the asset size of the project will increase by an average of 20mb (including mesh as all the meshes in this project are far less than 1MB in size).

    NPC units will only have 256x256 textures at best as they will never have any closeups.
    They will only need 4 channels. I expect each npc will add approx 5MB when fully textured.

    Thanked by 1critic
  • Well...... Unless you're zooming way in to your models and scenes, a lot of that MB is completely wasted - 500MB is not trivial for most people if you're asking them to test your prototype, with each update, especially. I would look for a way to not include full resolution stuff with your builds. Isn't there a way for Unity to build with smaller textures than the original assets? I'm sure there is?
    Thanked by 1critic
  • 20% Increase in player bar (in screenshot).
    image

    Also, next build will see missiles added to SF-2 (also in screenshot).
    Thanked by 1konman
  • edited
    Unity won't include assets unless they are referenced in a scene. We have many many GB of sounds, textures, etc., around 15GB at least - but the game build is 700MB.

    (If you placed all your assets in the Resources folder, they will always be included in the build, which is probably not the outcome you want.)
    Thanked by 2mattbenic critic
  • edited
    Uploaded New version.
    https://drive.google.com/open?id=1L0rPgaQVg4dhXdCJxEnfHg-O4QEMhhhB

    With this build I am trying the new LZ4C Compression option on Unity 2018.2.
    The game builds WAAAAY smaller now.

    Changes:
    - Removed unintentional GI from player setup scene.
    - Removed skybox from player selection scene, scene now uses same lighting with play mode.
    - Global Powerup Modifier on default difficulty level increased (powerups will occur a little more often).
    - Player "should" now always spawn with a full capacitor on default difficulty settings.
    - Planet textures adjusted. (reduced resolution of all channels except the emission channel)
    - Removed anistrophic filtering from all planet textures.
    - Reduced mip map levels on all planet textures.
    - Planet Clouds adjusted (softer, puffier normals).
    - Disabled Deferred Renderer (MSAA bug)
    - Removed portions of the Post Processing Stack (luckily without breaking it).
    - Player Bar increased in size by 20%
    - Recompressed all music.
    - Bug: Music is supposed to change after loading into level (being looked into).
    - Added Missile to the SF-2 . Second weapon slot.
    - - Missile Slot on SF2 fires once every 2 seconds. But fully upgraded will fire four missiles.
    - - Missile uses a sweeping raycast, sometimes it will track an enemy, scan range is 10 world units
    - - Sweep on SF-2 Missile is only 10 - degrees per second, it can fly past an enemy without detecting it.
    - - If A missile loses it's target, there is a chance it can lock onto yet another enemy.
    - Fighter NPC Hitpoint halved.
    - A turret NPC also has it's hitpoints halved (The one which fires green projectiles).
    - On the SF-1, the second weapon slot now has 2 hardpoints enabled by default.
    - Misc Backend bugfixes.


    Note: The SF-2 might be a little OP now compared to SF-1. But testing needed to determine if the SF-1 need more buffs.


    Next Build
    The following I hope to have ready for the next build.
    - UI Elements for GameOver and Pause State
    - A stat mechanism.
    -- These three new NPC units:
    image

    And another Player Ship for the UNC (not including boosters, yet...)
    -- image

    I added boosters mainly on impulse. But now I'm thinking they could be used for a special ability...
Sign In or Register to comment.