Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

A few questions regarding code structure for my first game, a twin stick shooter

Discussion in 'Getting Started' started by Cedebo, Jul 6, 2017.

  1. Cedebo

    Cedebo

    Joined:
    Mar 1, 2017
    Posts:
    8
    Hi there,

    I've been reading this forum for a few months and find it very interesting and helpful.
    Right now I'm working on my first game, a simple top down twin stick shooter (3D graphics with 2D gameplay) and I have some questions regarding coding structure.
    I want to keep the code as clean and flexible as possible to have the possibility to add more complexity and variety later on. I already have basic gameplay, but I think that now is a good point in time to think about organizing everything a little bit better.

    1. How should I structure my code files? Right now, I want to implement the following things:
    - enemies that can shoot and move with various weapons moving patterns. It may not be surprising, but they can also be destroyed. ;)
    - player ship that can move and shoot and be destroyed
    - Stationary Turrets or enemies that can spawn other enemies

    Is it a good idea to have one script for everything enemy-related like enemy movements, being destroyed and shooting? Or should I rather have one script for enemy movements, one for shooting stuuff etc.? Or completely different? I know that there may be not the one correct answer, but with your experience maybe you have some good ideas.

    2. Regarding enemy movements: later on I want to implement various movement patterns as going straight to the player, circling him, flying away from him, moving in sine waves etc.
    How do I structure this? Should I have one class for movement and decide from a variable that is set different for each enemy type which kind of movement it uses?
    Like (pseudocode):

    If movementPattern==1
    fly straight towards player ship
    elseif movementPattern==2
    fly away from player ship

    Or is it better to have one class for each movement pattern?

    3. Do you know any good tutorials for twin stick shooters that do a little more than a ship and one enemy type?

    I'm really looking forward to your answers. Please excuse any mistakes, english is not my mother tongue.
     
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Generally I suggest keeping your scripts small, simple, and reusable as much as possible. So I'd probably have separate scripts for movement, shooting, damage & destruction, etc.

    For movement, if each enemy has its own movement type, then I'd probably have different movement scripts for the different behaviors. But if one enemy changes its movement pattern during its lifetime, then that doesn't work nearly as well. You could throw the different movement scripts on there and enable/disable them as needed, but at that point, you're probably better off using one movement script with an enum for selecting the behavior.

    Finally, don't overthink stuff like this. Code it in whatever seems like the simplest way to you at the time. And later if you find it wasn't the best approach, refactor it.
     
    Ryiah, Cedebo, Kiwasi and 1 other person like this.
  3. Schneider21

    Schneider21

    Joined:
    Feb 6, 2014
    Posts:
    3,512
    I want to elaborate on one of Joe's points:
    I start every project trying to build clean, organized, efficient, extensible code. Almost without fail, these projects end up losing steam when I get buried in building complex frameworks to handle a multitude of cases I may want to incorporate at some point.

    The only game I've finished to date (Viking Chess!), I managed to build a working, but sloppily-coded prototype in one week. I then basically started over, cleaning up certain things and adding UI elements and such, but actually copied a lot of code over from the prototype. It was messy and a real bitch to debug, but I finished it.

    At one point I started work on Viking Chess 2, ensuring I followed all the best coding practices and creating clean systems with my own API, and... I stopped working on it. I had dozens of hours of work into it and nothing resembling a game yet.

    If you have a solid, unshakable plan for your game and require a certain degree of 'systems' work before you can get to it, that's one thing. But there's a ton of value in just getting the gameplay going with dirty code and cleaning it up later.
     
    Cedebo, Kiwasi and JoeStrout like this.
  4. Cedebo

    Cedebo

    Joined:
    Mar 1, 2017
    Posts:
    8
    Thank you both very much. To be honest, the answers are not what I expected but I assume you are right. So I will try to get as much gameplay done as possible and clean up later. And I will try to write small reusable scripts.
    The movement patterns won't change over time for one enemy so I will go with one script for each behavior.
     
    JoeStrout likes this.
  5. Schneider21

    Schneider21

    Joined:
    Feb 6, 2014
    Posts:
    3,512
    One last note: You don't need to ever apologize for not speaking English as your native language. Besides for the fact that there's nothing wrong with being one of 7.12 billion people whose primary language is not English, you use it better than half the Americans I know.
     
  6. Cedebo

    Cedebo

    Joined:
    Mar 1, 2017
    Posts:
    8
    Thank you!
     
  7. Deleted User

    Deleted User

    Guest

    May I suggest not using a "Materials" or "Textures" folder and instead keeping a material with the suffix somethingMat and a folder labeled Textures in every asset's "meaningful name" folder ed "Tree-> Textures, Mat." Since they're directly responsible fora A Thing piling them all up doesn't make sense.

    As for AI, it's a big topic and you should read a programming book. No, you shouldn't just use a switch for AI states. One common way is to make an interface-inheriting state class that can be swapped out in a machine class.