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

Puzzle Game Logic, best practices?

Discussion in 'Game Design' started by SEG-Veenstra, Jan 23, 2016.

  1. SEG-Veenstra

    SEG-Veenstra

    Joined:
    Sep 3, 2010
    Posts:
    326
    Hi, I want to create a puzzle game.
    It would be the first puzzle game I will make in Unity3D.

    But I came to a struggle on how I would design it.
    The game will be something like the famous 2048 game, where squares will move over the board based on user input.

    My approach would be to create the game logic and make some simple gameobjects to represent the visual part.
    The gameobjects will just be the 'view' of the game. In short:
    1. The player makes a 'move'.
    2. The game logic calculates the outcome of that 'move'.
    3. The 'view' will take that outcome and animates the 'move' that has been made.
    BUT, would did be the way to go, or should the gameobjects just contain the logic? So:
    1. The player makes a 'move'.
    2. The gameobjects act on that 'move'.
    The reason I'm struggling about this is because I might add in some AI later (so the game may make a 'move' for you if you earned 'hints', or a puzzle editor that can check if the puzzle is solvable). And having the logic of the game separated would mean I can use it without actually moving any gameobjects.
    Is there anyone that has experience with this decision and what are the pro's and con's that I might have missed?
    I hope my explanation is clear enough, else just ask what you need to know and I can try and clarify.

    Thank you!
     
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    You're asking implementation questions, not game design questions. So this should really be in the Scripting forum.

    And yeah, when you add AI or need automatic puzzle generation, you are almost certainly going to need a lightweight representation of the game state (i.e. separate from GameObjects) that you can manipulate. But I would also advise you to not worry about this too much in the early stages — just go get something working! You can always refactor later.
     
    Kiwasi likes this.
  3. SEG-Veenstra

    SEG-Veenstra

    Joined:
    Sep 3, 2010
    Posts:
    326
    Thank you JoeStrout for your answer. I thought this question didn't fit the scripting forum because I'm not really asking an HOW TO script is, just the general design idea.
    I think I'm going for the lightweight version first. I'm more a programmer then a designer so I rather have the logic working and later try to make the game actually look ' nice'.
    Thanks again!