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

Jumping in at the deep end!

Discussion in 'Getting Started' started by Shadefoot, Dec 7, 2015.

  1. Shadefoot

    Shadefoot

    Joined:
    Dec 3, 2015
    Posts:
    8
    So, after investigating with a friend the most viable options for getting a game developed as a tie-in to a children's book they have published, we decided that the most financially viable option (at least to begin with) was for me to learn Unity and C# and have a go myself.

    Bear in mind that the last time I really coded anything was using C to do an ASCII-art version of a Reversi game as part of my degree about 12 years ago! I do have some help hotlines on the C# front from family that program with it, but Unity is totally new.

    The game is going to be essentially a story-driven text-based adventure with static picture backgrounds to make it visually more interesting (I would LOVE to do something a bit more animated, but I don't have the time nor the skill for creating the graphics myself and my friend doesn't have the finances for getting the number we'd need produced). Bit of a shame to not be using Unity to its full potential, but oh well!

    I've obviously been looking through the various tutorials around the place for the GUI options and 2D development, but as most of the 2D stuff is platformers or physics games, it's often hard, as a beginner, to pick out the relevant parts.

    The main part I'm stuck on at the moment (apart from having to learn EVERYTHING!) is a combination of inventory management/persistence and how to "remember" the most recent state of the game (e.g. for a named player):

    So, for example with the inventories, I essentially need two inventories (or at least that's how seems easiest to manage it in my head) - one needs to persist throughout the game, collecting items such as gold stars and named talents, the other only stores items picked up at the beginning of a level and these are released at the end of that level (stuff like tools that will only be used for that level - calling this inventory the player's "backpack" so thematically would not make sense to persist the items, whereas the other inventory is more like being the player's "brain" where things are remembered).

    For the "most recent game state" - essentially I mean progress. It's a bit easier if a level is completed because that completion will register in the "brain" inventory with the "backpack" inventory cleaned out as usual, but if the player is part-way through a level and needs to exit the game, that's what I'm getting stuck with. Maybe it would just be better to make them restart that level?

    Either way, I'm struggling to find some clear tutorials on either of those aspects (possibly just searching in the wrong way/for the wrong terms) - anyone able to point me in the direction of good resources for either?

    Thank you! :)
     
  2. Adam-Buckner

    Adam-Buckner

    Joined:
    Jun 27, 2007
    Posts:
    5,664
    The most simple way of saving data is PlayerPrefs, but:

    Please be aware that this in not very secure!
    This is really meant for simple and somewhat irrelevant and replaceable data, such as audio volume and other things that are not critical to a game. This data is often readily available to anyone with a tiny bit of knowledge and a text editor. This is not the best place to save, say, score, points or money in a competitive game. For a simple children's game, if you don't care if someone hacks it (and very likely to due to the audience) then it's a good place to start.

    Please be aware that this does not scale well! PlayerPrefs stores simple float, int and string values, so if you need to store huge amounts of data, it does not scale well, but it can be a great place to start, especially when at the prototyping phase.

    The next stage beyond that is learning to save data to a file in the file structure of your game's device. This is a subject called serializing data. There are some resources we have on this, including http://unity3d.com/learn/tutorials/...ining-archive/persistence-data-saving-loading

    As saving a game state can be very unique per game, this part of your project could get a little wild and wooly as you find the best solution. As you can see here, this was declined as a feature suggestion.

    One big bullet point here is built-in JSON serialization: UnityEngine.JsonUtility is a runtime API for serializing and deserializing objects to JSON format. Listed on our roadmap as part of the upcoming 5.3 release. I've not yet had a chance to play with it.

    Lastly, there is the Asset Store. There are a number of paid and free solutions on the Asset Store, but I'd suggest that you do your research before buying, as you will want to make sure any solution you pay for will work for you. Search for "Save Game" and "Serialize" for some options.
     
    Ryiah likes this.
  3. Shadefoot

    Shadefoot

    Joined:
    Dec 3, 2015
    Posts:
    8
    Ah, thank you for that. :) The serialization stuff sounds more like what I want, though I'll keep PlayerPrefs in mind as a backup option as we don't anticipate the amount of data needing to be stored to be large.

    I did have a brief look at the asset store, but decided I wanted to understand a bit about how the process was supposed to work before committing to anything as it makes deciding which sounds best for me a bit easier!
     
  4. Adam-Buckner

    Adam-Buckner

    Joined:
    Jun 27, 2007
    Posts:
    5,664
    "Serialization" is essentially encoding data down into simple forms that can be streamed and written to a file - but in a way that if it's read and decoded, the data can be used without (too much) trouble.

    What may be worth looking into is some of the theories and philosophies behind exactly what needs to be saved. You often don't need to save everything, but can simply save the most important information - perhaps the name or type of thing this is in the scene and it's position and rotation... and when reloading the saved scene, you can reconstruct everything locally from this data. Let's say you save level number (an int) and the player (int id, vector3 position) [you may not even need rotation, will the player remember which way they were facing?). This this, you can load the scene by index number and place the player into it at the last recorded position. This could be even easier if you have spawn points: (int levelID, int playerID, int spawnID). Most games will be more complex than this, but there are many proven ways to reduce the amount of data that is saved.
     
  5. Shadefoot

    Shadefoot

    Joined:
    Dec 3, 2015
    Posts:
    8
    That makes sense, and unless I'm misunderstanding something along the way, I think it'll almost be that simple for me as it'll be dropping a player back into "question 2 of level 3" or whatever. Pictures are static and tied to the question (think like how pictures in a storybook accompany the text) so no level or player facing data needs to be generated. Only "variable" thing would be the inventories I think.
     
  6. Adam-Buckner

    Adam-Buckner

    Joined:
    Jun 27, 2007
    Posts:
    5,664
    I'd prototype locally using PlayerPrefs knowing I was going to refactor using serialization before I deployed so I could keep the momentum up on developing the game, and then research serialization techniques along-side.
     
  7. jhocking

    jhocking

    Joined:
    Nov 21, 2009
    Posts:
    813
    The questions you're asking are explained in my book Unity in Action. There are explanations about inventory data, displaying a GUI, and saving the game.

    Given that you already know how to program a bit and the book is written for people who know how to program, it sounds perfect for you.