Jump to content
  • entries
    17
  • comments
    4
  • views
    878

Dev Log #3

Sign in to follow this  
FatPugStudio

245 views

Intro

Turns out that thing aren’t always simple as they seem at first glance. I spent more time than planned on overhauling the weapon pickup and replacement system i wrote about in the previous dev log. Apparently, despite the system being laid out well, there were some hurdles that appeared.

First of all, the weapon switching system that was meant to be extremely basic and function by simply activating and deactivating children objects (weapon objects with firing FSMs) on the gunpoint of the ship proved too common for the concept of weapon equipping, upgrading and dropping during the game. I upgraded the system and while it’s very complicated and probably can be laid out a lot simpler, it works as intended.

The setup

Upon starting the game, Player is spawned, its child Gunpoint, and Gunpoint children, Basic Weapon Object (Level 1 out of 5 weapon) and Empty Weapon Object. You’re probably wondering why would i put something like Empty Weapon when it’s not even used, but we’ll get to it. Every Weapon Object has two FSMs, Main FSM, used for the upgrade system, and Firing FSM, used for firing the weapon. Gunpoint object stores the Weapon Switch FSM. Bear in mind that Weapon Object can also be Weapon On Ship, or a Weapon Pickup, depending on the state in which it is and the fact that Player can have two weapons equipped, but only one active at the same time.

Weapon Upgrade System – how it works?

Main FSM controller on the Basic Weapon Object enters the first state. It searches for the Gunpoint object (place on the ship where it will be spawned. Search is done by tag, since it is quicker than searching for it by name). When it finds it, it stores it in the variable. By checking if the Weapon Object is childed to a Gunpoint or not, the Main FSM is branching in two directions, which determines if it’s really a weapon equipped by Player, or a Pickup waiting to be collected.

Shorter branch is executed is if the Weapon Object is a child of the Gunpoint object. It is then stored in the Weapons On Ship array, and the Main FSM finishes it’s job for now. That means that it is a weapon equipped by Player and it can be fired.

If it is not childed, it means it’s a Pickup (drifting in space, waiting to be collected), its Firing FSM is disabled, a child which is an animated circle indicator for easier visibility is activated and the state machine starts its next event.

Weapon Object starts measuring distance from the Player. When the distance drops below defined value, Weapon Object can receive the key command from the Player, otherwise, it’s non-responsive to key press. In game terms, when the Player hovers over the weapon, by pressing key following states can occur:

Simplest case occurs ff the same weapon type of maximum upgrade level exists on the ship (checked by iterating through the Weapons On Ship array). “Weapon is at maximum upgrade level” message appears, the pickup eventually leaves the screen and it is despawned.

If the same weapon type of lower upgrade levels exist on the ship, it is upgraded. If the pickup is of the same or lower level than the weapon on the ship, the weapon on the ship is upgraded by one level. But if the pickup is one or more levels higher than the weapon on ship, the weapon on the ship is upgraded to that level. So, you get a pickup and it upgrades your weapon by one or more levels and it disappears. In game terms, it sounds simple, but actually there’s a lot of mechanics behind it.

For example, Player is equiped with Level 1 Weapon, and there’s a Level 1 Weapon Pickup which we collect. Level 1 Weapon Pickup iterates through the Weapons On Ship array, and it finds the Level 1 Weapon of the same type. It gets the position of the Gunpoint object, spawns Level 2 Weapon and adds it to the Weapons On Ship array. It also checks if the Level 1 Weapon in the array has its Main FSM enabled or not. If it is enabled, that means it’s an active weapon (we’ll also get to it when we get to the Weapon Switching mechanism), which means that the Level 2 Weapon that is spawned should also be active which is done by activating Firing FSM on Level 2 Weapon nad adding it to the Active Weapon array (needed for the Weapon Switching mechanism). Firing FSM on Level 1 Weapon is disabled, it is removed from the Active Weapon array, removed from the Weapons On Ship array, Level 1 Weapon equipped on ship itself is despawned and Level 1 Pickup is finally despawned at the end of the last state. If the Level 1 Weapon on ship is inactive (its Firing FSM is deactivated), the Level 2 Weapon also spawns with its Firing FSM deactivated, but is not added to the Active Weapon array.

What happens if the Player is equipped with one or two weapons that are different from the pickup?

Things get a bit complicated there. If Weapon On Ship array does not contain any of the levels of the Weapon Object that is the same as the Weapon Object pickup, a Replace Active/Replace Empty state is entered. Remember the Empty Weapon object from the setup? It is used as a placeholder when picking up a weapon that is different from the basic equipped weapon. By iterating the Weapon On Ship array and finding no weapons of the same type but finding an Empty Weapon object, it is simply despawned, removed from Weapons On Ship array and replaced by the picked up Weapon Object. Since it is not active, spawned weapon Firing FSM is also not active, thus not added to the Active Weapon array.

A different Active Weapon acts similar to an Empty Weapon object if all slots are taken. It is removed from the Weapons On Ship array, removed from the Active Weapon array, deparented from the Gunpoint, its children activated (circle indicator that makes it visible more better on screen), and the pickup is spawned on the Gunpoint. As i said in the beginning, whenever a Weapon Object spawns, it immediately checks if it is a parent of the Gunpoint or not, and then added to the Weapons On Ship array or not.

Switching Weapons

Finally, switching the weapons. First we need to make sure that the Player can’t cycle between the equipped weapon and the Empty Weapon object. As long as the Empty Weapon is in the Weapons On Ship array, cycling is not enabled. When it is no longer contained in the array, Player can freely switch between weapons. Every switch gets the first and second index numbers of the Weapons On Ship array, stores them as Weapon 1 and Weapon 2 variables, enables and disables Firing FSM on them, adds the Weapon Object with enabled Firing FSM to the Active Weapon array, and removes the Weapon Object with disabled Firing FSM from the Active Weapon array. We need the information about the Active Weapon so it can be replaced with the pickup that is different from it. That enables the Player to upgrade the weapon of the same type as the pickup on ship whether it is active or not, or select which weapon will be replaced (if both are different from the pickup) by simply switching weapons to active or not.

Complete system for upgrading and replacing weapons. Thing is - every weapon level object needs to have one of these.Complete system for upgrading and replacing weapons. Thing is – every weapon level object needs to have one of these.

 

The post Dev Log #3 appeared first on Fat Pug Studio.


View the full article

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By alien-project
      About me:
      Hi, my name is Christian and I am an enthusiast for games and simulations in the field of artificial life. I am an applied mathematician and have worked in my past for several years as a researcher on mathematical problems for damage mechanics. Currently I am employed as a software engineer.
      Physics engine:
      What I want to announce here is a 2D physics engine for damageable and glueable rigid bodys. Temperature effects such as radiation and heat conduction are also simulated via certain particles and internal energy distributions. The building blocks (nodes) of the bodys can be programmed by a simple assembler-like language enriched with physical actions, communication, sensoring and procreation functions. Portions of code is stored in each node as machine code and also potentially subject to changes. The code is processed by tokens moving/forking on a directed graph which constitutes the body. To get an impression of how the engine looks like in practice I attach some screencasts showing different examples. The engine performs multithreaded computations and is encapsulated in a C++-framework. I think it could be used to create realistic effects for space games. I am very interested in your ideas, opinions and constructive criticism.
      [media]https://www.youtube.com/watch?v=DG61uprKzWg[/media]
      [media]https://www.youtube.com/watch?v=2L3Cr2WwHDc[/media]
      Performance:
      With the current implementation one could simulate rougly 50k - 100k building blocks with 30 fps using 8 CPU threads (measured on Core i7-6700). There is still no finished GPU implementation but after experimenting with CUDA I would estimate that 300k can be simulated
      on my GPU (GeForce 960 GTX). To get an idea of of the computational effort please think that every building block in the scene (size of a pixel in the video) can be glued or detached to/from a body and performs calculations or other physical actions. The high degree of dynamics in simulation (damage and coalescence, function of nodes can change) was one the biggest challenge in the development.
      For broader applications it would be quite nice to port this engine to Unity. But I fear that the performance would then decrease substantially.
      Editor:
      In order to demostrate the engine I had developed an editor/simulator named alien. It allows to create and modify simulations filled with bodys. alien provides a pixel view as well as a graph and code editor for designing and visualizing every detail in a scene. As an demonstrating example I have designed a replicating machines that consumes nearby materials (see video below). More complex machines with sensoring, communication and attacking skills are also conceivable. Thus the material in the simulated world could be equipped with life-like or even intelligent behavior.
      [media]https://www.youtube.com/watch?v=Slba3g7-LK4[/media]

      More information and download:
      alien-project.org (it's opensource)
       
    • By jb-dev
      This is a new relic. Once picked up, it protects the player from status effects. It also reset the player's focus. The texture of this model is actually a map where each channel describes the ratio of colour to use. We then set the colours in code, making a nice dynamic gradient reminiscent of the FIji brand bottled water.
    • By jb-dev
      A more up-to-date version of the status effects. Coupled with tints and indicator icon. Right now, the enemy is supposed to be burning...
    • By jb-dev
      A somewhat early version of the frozen status effect applied to enemies. The abstract texture is screen aligned, which gives it a really abstract feel that I'm going for
    • By jb-dev
      This is an exterior view of the temple. As you can see it's really Japanese inspired. The whole roof is also open. This means that light can come in and be quite beautiful.
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!