[Devblog] Sear's Action-RPG Game

Discussion in 'TZT GameDev' started by Sear, Mar 10, 2014.

  1. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    Gonna pseudo-devblog it in this thread for the game I've been building.

    This is mostly for my own benefit in tracking and organizing stuff, but I'm totally open to any kind of feedback or questions. For the time being, I'm strictly working on this alone (not counting my girlfriend doing art). The reason for that being that I just spent the past 6'ish years working with hundreds of other chefs in the kitchen and also because it's just easier for me this way + a personal challenge of sorts.


    CURRENT TO-DO

    [Scripting]
    High Priority:
    Create more skills/attacks (basic projectile, different melee attacks, etc)
    Create Friendly NPC class
    Implement start/end game wrapper (main menu & game over loop)
    Item & inventory system (investigate methods/assets to handle this)
    Test Save/Load system
    Start GUI work (use DFGUI for now - just do basic HP bar + name & level display)
    Scene Change Trigger Event (walk on area -> change to new scene)
    Low Priority:
    NPC Dialogue system (investigate unity store assets that handle this)
    Improve Player Controls & Physics (tweak collision and movement/jump feel)
    Improve Player Attributes & Level system (add more attributes, add unlocking event trigger on level-up)
    Improve NPC AI & Pathing (work on waypoint system and player detection, add more complexity/randomness to attacks and movement

    [Graphics/Art/Audio]
    Enemy NPC concepts
    Environment concepts
    Create some kind of shitty title / main menu screen
    Basic assets for GUI (health bar, inventory/menu window)
    Experiment with different shaders and lightning

    [Misc]
    Design advanced attribute growth / leveling system
    Start rough storyboarding of character & storyline progression
    Conceptualize more NPCs and items/equipment


    BACKLOG:

    Cutscenes (After Effects)
    Familiar/Pet Class
    Advanced GUI
    Day/Night Cycle & Weather FX Scripting
    [more shit goes here]



    COMPLETED:

    [Scripting]
    Player Character
    Basic Controls (movement, jump, and attack - tested w/ keyboard and X360 controller)
    Physics & Colliders (simple but works fine)
    Association w/ Skills, Factions, and Attributes
    Basic death trigger event (doesn't loop or include wrapper yet)
    NPC (Enemy)
    Physics & Colliders
    Pathfinding AI (circular wander along Navmesh w/ random idle durations + basic waypoint system)
    Detection AI (detects and attacks player based on configurable line of sight radius)
    Association w/ Skills, Factions, and Attributes
    Skills
    Base Skill Class w/ lots of configurable variables (targeting, distance, cooldown, etc)
    2 test skills created (Player Melee Attack and Enemy Melee Attack)
    Attributes
    XP attribute created (w/ Leveling Experience Curve configurable from the Unity GUI)
    HP attribute created (triggers death event for Player & NPC upon reaching <= zero)
    Factions
    Base Faction Class (can be tied to NPC or Player, has Friendly/Neutral/Hostile matrix)
    Two basic factions created (just for testing NPC detection of player)
    Camera (third-person / top-down hybrid) follows player character + allows for limited tilt/zoom control in-game.
    Tentative Save/Load solution (not implemented or tested yet).
    Tentative Cutscene/Movie solution (After Effects render export -> Unity movie texture). Successfully implemented and tested cutscene trigger event in-game that switches to new scene w/ placeholder movie cutscene and then returns to original scene after done playing.
     

    Attached Files:

    Last edited: May 29, 2019
  2. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    Looking good so far.

    I love making lists like that when doing solo projects. The best part is crossing them out. I would leave them there and just do a strike-thru. Or throw them in the completed section like you have. It feels good to go back and see everything you've done in a readable list.
     
  3. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    Agreed on that, although everything is so sandbox right now that I'm probably jumping the gun by even making lists.


    Case in point, I've thrown out 3D graphics in favor of 2D. The overhead for creating 3D models just sucks too hard, and it's much easier to retain a painterly / hand-drawn look with 2D sprites. 3D modeling software frankly just sucks ass.

    By contrast, I can whip together a fairly high-quality 2D sprite animation in a fraction of the time it would take me just to get a base model mesh done in 3D.

    I found an amazing 2D lighting tool that converts normal / depth / ambient occlusion maps based off a diffuse and lighting texture + already wrote a custom unity shader to support it.

    [​IMG]

    ^not my asset, but a good example of what it does. I used some Link To The Past sprites to test out basic lighting.

    Right now I'm extending/rigging the framework I've been using to support 2D character controllers.
     
  4. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    Wow, that lighting looks awesome.

    When I get on to making my space mystery puzzle game I will NEED that tool. The game is supposed to be scary and awesome lighting effects when there will be not much light in the game would just bring it to a whole new level.

    And yes, I agree with you about the 3D models. It's hard to find a good 3d modeler/animator that's willing to work on an indie game, especially w/ low or no budget. 3D graphics take a lot of time when you factor in the texture mapping and animating and stuff.

    One thing about 2D sprite RPGs though is you either need limited character models as armor makes big upgrades (cloth, leather, chain, plate, epic armor, etc, or like Link wearing green, red, blue), or, if you want each armor piece to change the character's appearance, there will be a lot more work involved and each armor piece will need to be its own sprite layered properly onto the hero (plate helm, leather bp, sword/axe/bow/etc, magic gauntlets, etc. could be one combination).

    For the Kings of Destiny 2d rpg I made, I wanted every armor piece to change the look of that graphic on your hero for unique combinations. I did it in Flash because of their use of MovieClip objects that have nesting and multiple frames for easy updating of individual parts, and not only was it difficult to code my first 5 attempts at it ( i learned a lot real fast ) but Flash MovieClip rendering really sucks and I had to use a lot of different techniques to get loading times and performance to an acceptable level for most PCs.

    I will probably never build a game using Flash rendering again. I still love Flash as a platform because it is flexible, but will only do custom rendering and no MovieClip objects.
     
  5. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    I despise Flash so you have my full empathy on that. I worked with it for years and was even the [only guy who knew how to do certain things in Flash at the entire company] for long stretches of time. I wanted to break my computer monitor on numerous occasions while dealing with the quirky bullshit like you describe (buggy movie clip nesting in their shitty fucking keyframe-and-symbol-driven interface while simultaneously juggling actionscript to make stuff actually do stuff).

    I will never use it or Adobe AIR again, at least for my own projects. There are plenty of better options out there now, and Adobe already announced they were effectively abandoning support of it in favor of HTML5.

    Unity's new 2D features are 1000x better.

    Construct2 is better. Basically anything is better and no one should ever have to endure the pain that is spending hundreds of hours learning how to use Flash and make it do really simple things.
     
  6. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
  7. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    Oh man, $35 pledge just for hobbyist version.

    And really I would probably need the pro version seeing how much more it does than the Hobbyist one, and it costs $90 at this point.

    I would easily drop the cash if I had a game all ready to go looking for this lighting upgrade... *sigh* I'm sure i'll buy it eventually when I go to make the space game
     
  8. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    Reined the scope of the game we're building back in to our original vision: 2D action-RPG from a side perspective (Castlevania, Super Metroid, etc).

    Decided the extra work required for top-down (multi-directional sprite animations) wasn't worth it and also wouldn't allow us to paint the kind of environments we want to.

    I just finished a Megaman style charged attack projectile script.

    Code:
    	public float chargeRate = 1f;
    	private float chargeDamage;
    
    
    
    	void Update ()
    	{
    		// increase shot dmg the longer button is held down
    		if (Input.GetButton("Fire1"))
    		{
    			chargeDamage += Time.deltaTime * chargeRate;
    		}
    		
                    //fire the shit then reset damage 
    		if (Input.GetButtonUp("Fire1"))
    		{
    			Debug.Log(chargeDamage);
    			WeaponScript weapon = GetComponent<WeaponScript>();
    			weapon.Attack(false, chargeDamage);
    			chargeDamage = 0;
    		}
    Now I just need to change the projectile size/object based on how much it's charged.
     
  9. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    I always was a fan of side-scroller RPG and wanted to make one for the longest time. Castlevania Symphony of the Night is one of my top 5 favorite RPG games of all time, one of the only ones i've played thru three times.

    also, while i'm posting i'd like to point out that chargeDamage needs to be initialized to 0 and also you should store off a startTime value on a GetButtonDown event and then do 1 delta time calculation on the GetButtonUp event.
     
  10. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    New float seems to default to 0 when you do nothing (I was curious), but yeah that's probably safer and won't come back to bite me.

    What would a startTime value accomplish?

    Unlike "GetButton" which is effectively a while loop, GetButtonDown or GetButtonUp only fire off once, so I can't really use the delta time calc in those. It will just spit out something like 0.2 or however long it takes to run the Update.
     
  11. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    Castlevania SOTN is prob my fav game of all time btw :smitten:

    Hoping to have a combat system that runs deeper than it did (it was satisfying and had 90000 weapon options, but there wasn't much to fighting)
     
  12. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    I wrote a bit of code to show how I would do it with a startTime endTime thing.. and I realized there are things you can do with a chargeRate value that might be more convenient by updating/calculating per frame like you are doing, that would be more difficult to achieve with a flat startTime / endTime.

    However, both methods have their pros and cons so I will post the code I wrote anyway so you can see how I would do it.


    Code:
    private float startTime;
    private Weapon curWeapon;
    
    void Update()
    {
        if(Input.GetButtonDown("Fire1"))
        {
            // store off current time
            startTime = Time.time;
            curWeapon.StartCharging(); // to start charge animation or whatever
        }
        if(Input.GetButtonUp("Fire1"))
        {
            // Calculate charge time, limited by this weapons max time.
            float chargeTime = (Time.time - startTime) > curWeapon.GetMaxChargeTime() ? curWeapon.GetMaxChargeTime() : (Time.time - startTime);
    
            // Calculate damage based on current/max time ratio
            float chargeDamage = (chargeTime / curWeapon.GetMaxChargeTime()) * curWeapon.GetDamage();
    
            GetComponent<WeaponScript>().Attack(false, chargeDamage);
        }
    }
    
    All of the code inside the GetButtonUp check could probably be done inside of the weapon class. unless all of this IS the weapon class, then remove all the curWeapon stuff and just replace it with the direct member variables. (wasn't sure if this was the Player or Weapon class)
     
  13. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    Hmm... that actually would work. Till just now I didn't know what the difference between Time.time and Time.deltaTime was. I was originally trying to do exactly what you coded, but had used deltatime thinking it operated that way.
     
  14. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Surprised you've gotten along so far without knowing the difference; is this in Unity? Most of the tutorials for it harp endlessly on using Time.deltaTime to normalize operations so you don't get weird behavior based on differences in updating speed e.g. between people w/ different hardware. edit: Everything looks really awesome, though. Dig the artistic style. What are you doing 3D modeling in? Blender, or something proprietary that you were familiar with from past work w/ Riot etc? edit2: The first pic kind of looks like a cartoon-ified Diablo 3, with the 6 y/o Japanimated big-eyes hero standing next to a dungeon entrance.
     
  15. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    ehh.. those people that harp on using Time.deltaTime are wrong. Sort of. It really depends on the game. The weird behavior is usually worse when using deltaTime, not the other way around. (unless you've built something that can run at variable speeds which would be pretty hazardous.)

    It is better to run a fixed frame rate unless you are making a multiplayer game with live position updating. A fixed frame rate (frame dependent updating) will just make your game run slower when the FPS drops. This is fine in all single player games.

    If you are going off of time and your frame rate drops for whatever reason, the game will look very choppy and can cause some major bugs like objects going thru floors/walls/other objects. You can miss costly collisions. But it is necessary in multiplayer games where you want things to keep moving even if you get lag.
     
  16. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    I don't think "A fixed frame rate (frame dependent updating) will just make your game run slower when the FPS drops. This is fine in all single player games." is a very common opinion among developers; it doesn't jive with what I've seen from most of the senior folks in the Unity forums. Generally you're not going to want your game to evolve at a speed determined by the frame rate; you want it to evolve at a fixed speed in time, and normalizing by deltaTime achieves that. It also buffers your game against variations in frame-rate within a single machine; you don't really want your game to move hyper fast when your CPU/GPU/RAM are all totally committed to the game and snail-slow when you're playing a game while you run 6 different TSP solvers.

    edit: Your remark about deltaTime normalization causing missing collisions is interesting. I've had some trouble before with Unity messing up what I thought should have been pretty easy collisions to detect, even with their most computationally intensive dynamic collision detection turned on and some rather large colliders relative to the objects themselves. Wonder if deltaTime normalization had anything to do w/ that. OTOH the frame-rate wasn't varying noticeably, so maybe not.
     
  17. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    Well, fixed frame rate will prevent it from running hyper fast. It will run only at 30fps or 60fps regardless of how fast your computer wants to process it. If you are running 6 TSP solvers maybe you shouldn't be playing a game on that computer haha.

    literally the ONLY time you will see a difference between using deltaTime or just being framerate driven is when you experience a drop in framerate. And then you have to choose if you want choppiness or just reduced speed.

    Since deltaTime just checks the time since the last frame was rendered, it can calculate how many frames your missed and account for it. But, to lower/eliminate risk of what that implicates would require you to lerp the skipped frames.

    This makes a lot of sense to do in most multiplayer games, especially with predictive pathing/positioning. But for a single player game, you are just introducing potential problems and also adding LOTS of deltaTime calculations that aren't necessary (operates exactly the same at full frame rate without those calculations)
     
  18. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Didn't know Unity had a target frame rate function, that's kind of neat. That would stop the FPS from getting too high, I guess; I wonder how well it works / resource-needy it is.

    deltaTime normalization does introduce a lot of extra computations, and the possibility of it scaling up position changes so that collision checks are missed is concerning; I can see why you'd want to avoid worrying about those two things. OTOH I'm not sure "well maybe you shouldn't be playing my game if you want to do a bunch of other stuff too" is a very satisfying explanation for customers. I think you've talked me into trying things without deltaTime to see how I like it, though.
     
  19. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    I've never built a game in Unity but I was aware of fixing a frame rate manually in the main processing loop of threads.

    Agrul you should get FlashDevelop and HaxePunk set up if you haven't already. Sounds like you would add a lot to the TZT game dev team. We can build a Unity game next :)
     
  20. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    I trashed the 3D style completely - going to leave those attachments up anyway just to look back on things someday. Most of them were placeholder or purchased assets. Attached some original stuff here that is closer to the painterly/cutout style we're going in now.

    I did some diving into how Unity handles time/frames and this was the clearest explanation, at least for me:


    Most suggest using deltaTime just to make it framerate-independent. The 2D physics I'm using currently controls it somewhat by setting a maximum amount of time per frame as a static variable, and then returning [the min value of that or the deltatime].

    Code:
    public static float FrameTime {
            get { return Mathf.Min (Time.deltaTime, maxFrameTime);    }
        }
    
    which seems like a smart way of bridging the choice between either being dependent or independent to frame rate.

    I don't expect the type of game I'm building to be very resource-heavy, though, and it's not going to mobile. Even low-end PCs should have no issues running it at a steady frame rate.
     
    Last edited: May 12, 2018