Sign in to follow this  
Tangletail

Unity Tips and Parables From the Gamedev Members

Recommended Posts

As post or thread it's a bit useless as very soon it's non-findable in the sea of other topics of the past.

I don't have lessons, but I do have tactics in programming, which can be expressed in lessons if so desired ;)

My main tactic is "don't plan for the far future". It is relatively easy to aim at a generic piece of code that is extendable in every direction for all needs you have in the future. While this is fine in itself, you likely don't need 7+ of the 10 directions, at least not until a long time in the future.
In the mean time, you're dragging all these possible extension code through all changes, and have to re-implement them if you break them by some other changes. All work that does not pay off immediately.

One risk is that you find you missed some crucial bit before you reach the future where you get to use your extensions, forcing you to move to a different structure/design. You'll have to reconsider all extensions as well, and also make new extension for the new design.
Another risk is, by the time you arrive in the future, you find you don't actually need the extension at all, ideas and circumstances have changed. You need a different 11th extension instead!


My tactic is to not implement anything I don't need today. I build a nice clean solution for my problem today, and will see tomorrow how to do the change of tomorrow.
In practice, "today" and "tomorrow" are a bit more blurry, and I do build hooks today that I surely need tomorrow, but not many.

Share this post


Link to post
Share on other sites

The 1010 Command Statements

I, the Algorithm, am the Lord thy Programming God. Thou shalt never have any programming languages before me.
Thou Shalt Remember The Beer and Pizza Day.
Thou Shalt Honor Thy IDE and Debugger.
Thou Shalt Not Ignore Warnings.
Thou Shalt Not Not Comment.
Thou Shalt Share Code.
Thou Shalt Not Ask For Which Google Can Answer.
Thou Shalt Not Bear False Performance Against Thy Neighbor's Programming Language.
Thou Shalt Optimize Algorithm Before Code.
Thou Shalt Understand The Problem Before Coding The Solution.

Edited by Alpheus

Share this post


Link to post
Share on other sites
1. Get a spec first.
2. Implement the simplest thing that can possibly work.
3. Documentation may lie to you.
4. Write unit tests or never let anyone else touch your code.
5. The maximum number of people on a team without interpersonal conflicts is 1. Edited by Nypyren

Share this post


Link to post
Share on other sites

Find a unique space for your game.  Game is full of crowded spaces (genres)

And its tough to stand out in the crowd 

At the design stage ask yourself: what would make my game unique? (not just better graphics, nor rehash of some old stuff)

Be creative in your game play design.

Its cruel to spend several mental-energy-months in development only to find that you don't do too well in sales because you are just one of several hundreds (or thousands) that look the same 

Share this post


Link to post
Share on other sites

Here's some advice based on my experience throughout the years in no particular order:

 

1) Perfect is the enemy of good. Get it done and working first, then iterate later if there's time and/or necessity. Keep in mind that performance isn't always the first priority.

2) As a corollary to (1), try to come up with more than one solution to a given problem, in case one turns out to be a dead-end or you unexpectedly have to change course. I personally try to have at least three; one that represents the "ideal" solution I'd use if I had infinite time and resources, one that represents the fastest possible solution to get things functional if I was crunching and had to be finished yesterday, and one that's some trade-off between the two. The final solution is usually somewhere between two of the three, and you've established multiple possible starting points for future iteration.

2) Always keep your customers' needs in mind. That doesn't just mean end-users; it includes everyone on your team, even your future self. If that means physically collocating yourself so you can watch a content creator work for a day or two, do it.

3) Demand full specs for every feature. Get clarification for any circumstances or edge cases not covered. Have this information readily accessible to everyone on the team. Miscommunication can be very expensive. Ideally, you should make sure that the information is in a format that makes verification as easy as possible for the testing team (although an addendum with testing procedures also works just fine). Go so far as to follow this testing procedure yourself so you can catch any obvious and low-hanging fruit and eliminate the overhead of sending it down the line.

4) Everything should be owned by someone. Whether that be a feature, a process, a document, a system, a tool, the creative vision of the entire game, etc., there must be someone who has a vision of where it's going and has the authority to make decisions. This sometimes takes the form of one person per discipline, i.e. one engineer, one designer, and one artist, each making decisions on behalf of their respective department. Design by committee can and will grind development to a halt. Vision and decisiveness keeps things moving smoothly.

5) Know where your development time is going. You may have a very robust process in place for scheduling tasks and determining time estimates, but if you don't track how much time it takes to fix bugs, for instance (or allow non-critical bugs to become known issues and backlogged for later once you've spent too much time on them), then you really don't have a full picture of your time costs and it's easier to fall behind.

6) Track everything (partly a corollary to (5)). Get you and your team some decent project tracking software (at work we use JIRA) and don't be afraid to use it. You'll have quantitative measurements of your team's progress and you'll always know who's working on what. Plus, if someone has some extra time between builds or reaches a stopping point, they might find an issue they can knock out a fix for real quick.

7) Don't take unnecessary shortcuts based on guesstimated time savings. Make an honest assessment of how much longer the correct approach will take versus the fast approach, including future maintenance effort and bug risk. Ask yourself if that extra few hours is really worth it. More often than not, it isn't, and the extra time to do something right saves you and your team lots of headaches down the line.

8) Be wary of data that begins to feel too much like code, unless it's actually supposed to be code (like scripts). You tend to see this kind of data with large game-logic systems that "do all the things!", where multiple games over the years have added their one-off features to the system but tried to make them general-purpose under the assumption that it would be used again, but often never is. At some point, the system grows so large and complex that the behavior of the system is defined more by the data than the code, and it becomes a nightmare to work with for everyone involved.

9) Not everything has to be built to last forever. Acknowledge that a lot of game code is throwaway and can't/shouldn't be used again for another project. Over time, your experience will tell you which code and systems these are. You can always go back and get old code if you realize a need for it in the future.

10) Be as consistent as possible. Don't use different solutions to multiple similar problems. Even if you do something wrong, and you repeat that error in multiple places, it's still easier to fix a consistent mistake than an inconsistent one. Human beings are built to recognize patterns, after all, no matter what they are.

Share this post


Link to post
Share on other sites

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

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628277
    • Total Posts
      2981771
  • Similar Content

    • By ForgedInteractive


      Who We Are
      We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! We're a team of artists, animators, programmers, level designers, writers, composers, producers, and other creative minds. We want to make games that you, the modern gamer want to play! We hope to build a community that enjoys our games as much as we love creating them. With your feedback and support we will be able to achieve that.

      About the Game
      GAME NAME is a fun, action-packed army builder with unique characters, challenges and engaging levels. Set forth on an adventure to protect friends, family and countrymen from new adversaries. Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.

      Previous Work by Team
      Although we are working towards our first game as a team, our team members themselves have past experience in the industry.
      This includes members who have worked on titles including:
      Final Fantasy Kingsglaive, FIFA, Xcom 2 and Civilization.

      Who are we looking for? 3D Modellers Concept Artists Marketing Specialists Level Designer

      What do we expect? Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques
      What can we offer? Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.
      Contact
      If you are interested in knowing more or joining. Please email or PM us on Skype. Myself or Colin will reply to you within 48 hours.

      E-mail: Recruitment@ForgedInteractive.com
      Skype: ForgedInteractive

      Regards,
      David and Colin

      Follow us on:

      Facebook: https://www.facebook.com/ForgedInteractive/
      Twitter: @ForgedInteract
      Youtube: https://www.youtube.com/channel/UCpK..._as=subscriber
      Reddit: https://www.reddit.com/user/Forged_Interactive/
    • By Eck
      I just saw their courses were knocked down to $10 each and figured I'd share the info here. They have stuff for Unity, Unreal, drawing, business, etc. I haven't used their stuff before, but the previews I looked at seemed pretty good and there is a user review system as well.
      https://www.udemy.com/courses/search/?q=Unity&src=ukw
      - Eck
       
    • By zizulot
      first and only logo , for now
    • By sidbhati32
      I am working on a game in which we control a rectangular box at the bottom of the screen. Three sphere which has alphabets in it fall down. When the game starts, a word is generated from the predefined list of words(which I'll give) and we are supposed to touch the correct sphere having the alphabet based on that word. The question is how to detect if I have touched the correct sphere. 
      secondly, if I have touched a correct sphere before and there is no recurrence of that alphabet in that word then during the second wave the game should not proceed if I touch the same alphabet again.
      Looking forward to your answers, i have to submit this project in a couple of days. please help! (Working on Unity 3D)
      Thanks
    • By NDraskovic
      Hey guys,   As the title says, I'm trying to control a desktop game by using my mobile phone as a controller.  I created two scenes, one that acts as a server, other as a client.    Server has this code: void Start () {         Test = "Nothing yet happened";         NetworkServer.Listen(25000);         NetworkServer.RegisterHandler(888, ServerReceiveMessage);     }         private void ServerReceiveMessage(NetworkMessage message)     {                 StringMessage msg = new StringMessage();         msg.value = message.ReadMessage<StringMessage>().value;         if (!String.IsNullOrEmpty(msg.value))         {             Test = "Message received";             string[] deltas = msg.value.Split('|');             Horizontal = Convert.ToSingle(deltas[0]);             Vertical = Convert.ToSingle(deltas[1]);             TestScript.MoveForward(Vertical);             TestScript.RotateAroundY(Horizontal);         }         else         {             Test = "Nothing received";         }     }  
        And client this:  private void Connect()     {              client.Connect(IPAddress, 25000);           }     void Start () {         client = new NetworkClient();         Connect();            }         void Update () {    #if UNITY_ANDROID         MobileTouches = Input.touches;         if (MobileTouches.Length > 0)         {             for (int i = 0; i < MobileTouches.Length; i++)             {                 if (MobileTouches[i].phase == TouchPhase.Moved)                 {                     Horizontal = MobileTouches[i].deltaPosition.x;                     Vertical = MobileTouches[i].deltaPosition.y;                 }else if(MobileTouches[i].phase == TouchPhase.Stationary)                 {                     Connect();                                  }             }         } #elif UNITY_EDITOR               Horizontal = Input.GetAxis("Horizontal");         Vertical = Input.GetAxis("Vertical"); #endif         thumb.Translate(Vector3.up * Vertical * Time.deltaTime);         thumb.Translate(Vector3.right * Horizontal * Time.deltaTime);         SendControllerInfo();     }     static public void SendControllerInfo()     {         if (client.isConnected)         {             StringMessage msg = new StringMessage();             msg.value = Horizontal + "|" + Vertical;             client.Send(888, msg);         }     }  
        Ip address is hard coded, I just replaced it with the "IpAddress" variable. The code itself builds fine, and when I try to run in on a desktop computer, it works as expected (just a simple movement of an object on the server screen). However when I try to publish the client scene to a mobile device (Android), it doesn't connect to the server. They are both connected to the same network. Can anyone tell me what the problem might be?   Thanks
  • Popular Now