Need some guidance for 2D games

Hi,

I've been doing the unity tutorials, and I'm having a blast! So far, I finished the roller ball tutorial and the 2D game kit tutorial. I've also done some Brackeys tutorials, too (actually, I started there).

I plan to continue with the unity tutorials, but I had a question about what approach I should take.

I want to try making a simple side scrolling game, with a focus on melee attacks (like Ellen has), and some RPG elements, like HP, elemental damage, damage resistance, critical hits, etc (a bit more than in 2D game kit by default). I also want an autosave system between executions of the game.

Should I:

A) work with the 2D game kit, and try to copy or build on top of its code and framework?
B) try to write 2D script from scratch? If so, should I use the unity physics or make my own physics (there's a unity tutorial on this, I think).
C) buy/use character control scripts and other scripts from the asset atore?

Also, what's the best mechanism for saving the game?

I don't mind spending a few bucks; this is my hobby and I'm having fun. But, I don't want to get bogged down in a lot of animating or coding, because I only get to do this on my free time.

Thanks!

 

Nothing wrong with giving the game kit a try if your game will include elements that are already implemented in the kit.
As far as physics implementation, the one included in Unity (PhysX) tries to behave somewhat true to real physics behavior. If that is what you are going for then use it. Implementing your own physics would be reinventing the wheel, and Unity's implementation is going to be included in your build regardless. Also it is common to use colliders for more than impacts in games, such as a trigger collider to detect if the player is in range of something, which will use Unity's physics implementation anyway.

I wouldn't start buying assets off the Asset Store until you've got a little more experience, unless you have plenty of money to burn, because you will undoubtedly make some poor choices in the beginning. Also asset developers are usually happy to help someone having trouble with their asset, but have to assume a certain proficiency with Unity on your part when explaining what to do, and can't be expected to do any teaching beyond what someone knowledgeable in Unity would need to use the asset.

There's lots of options for saving player progress. Take a look at playerprefs as an option. You could also write out json to disk, or any other standardized format, or even create your own custom format. Or you can save to either your own server on the Internet, or one of the database as a service providers.

 

Hi Joe,

Thanks for guidance! That's a really good idea about using colliders to detect being in range! I didn't think of that, but I can already think of a few ways I could try it. I'll have to play around with that.

I found a really cool unity component, called "Character Controller". What are your thoughts about using that? After playing with the built in 2d physics engine, and Character Controller, I found the latter to be more fitting for a sprite based game. The former is cool, but the realistic rocking and falling and stuff is a bit too much, lol.

I also ended up buying some assets from the store. My weakest skill is animation and drawing (and music, haha). So, I got 2 character sprite creators and some beautiful forest backgrounds/foregrounds from the store (what do we call these products? Assets? Bundles? Packages?). I really wanted to get them so that they add some context for me, and so I have something to work/test/learn against. I get what you mean about help from the asset developers. One of the character sprite packages I got came with some example scripts, and that's how I really learned about the Character Controller mentioned above.

Lastly, I really hope we can talk about saving! I first found PlayerPref, which I understand saves to the registry. However, I also heard that you shouldn't use it to save too much. If I am going to save the whole world state, I get the impression I should use some other approach. Back when I used to code some windows forms, I used to save by using xml serialization into text files. Is this a good idea in the Unity context? Or is there a best practice way of saving the game that I'm not aware of? I intend to autosave frequently, and prevent the user from loading old saves (so like "hardcore mode" or like a rogue-like). For my own extra-credit, I might try to give the player like 3 independent save slots, as well.

Actually, one more question based on that. The serialization worked well with my winforms because there's only 1 thread. But, now we have multiple sprites and scripts running at once, right? If two scripts try to save at once, will it clash, or will one save method finish first, before the next time the save method is called? Do I need to make it multi-thread safe?

In summary:

1. What are your thoughts about using Character Controller component instead of physics? Are there certain situations where this is preferable? Any pitfalls I should be aware of?
2. What are your thoughts on saving? Player Prefs? Xml Serialization? Something else I didn't think about?
3. In PlayerPrefs, what's a good way to handle one or multiple save files?
4. When saving to a file or registry, should I use a lock or deal with multi-threading somehow?

Cheers and thanks!

 

1) Any of the provided character controller options are good for trying out, and if they work well for your game they are good to keep using. What you will find as you continue using Unity though is anything from Standard Assets will become too limiting for what you really want, and you'll end up creating your own scripts for controlling your characters from scratch, or you find 3rd party offerings with more customization for your needs. That said, again they are great to get started using. You'll know if/when your needs outgrow them. You outgrow them not because they are bad, but because you transition from learning how to just get basic things going at al,l to learning how to create exactly what you envision for your game. It is unlikely a prebuilt controller is exactly how you envision your game's character controller is all.

As far as Character Controller vs physics based controller, that is entirely game dependent. Games such as RPG's or shooters often have characters that display unrealistic physics on purpose. For example in classic Doom you can instantly run top speed, immediately stop and strafe back and forth, and be back running at full speed without any lag. Twitchy FPS games really depend on this type of control system, where a physics based system of adding forces and using drag would feel sluggish to say the least.

Something like a racecar game though would have entirely different needs, where you probably do want a real physics feel to the control of the vehicle.

2) Use PlayerPrefs for relatively simple data. Volume controls, character name, what scene to start on, what check point the player last crossed, etc. These are all good candidates. If you feel the need to serialize the state of much of your scene objects though you should be looking at other options. XML is fine, JSON or even CSV as well. They have their pros/cons each. JSON is the only one I'm aware of with built in serialize/deserialize support in Unity. (I tend to favor CSV because I find it handy to view full pages of data at a time in a text editor or spreadsheet when troubleshooting the code that creates and uses it, but it is the least friendly for serializing complex types of the 3 so most people probably would say it is the worst choice) If you're focused on making your saves difficult for a user to edit, you might want to consider creating your own custom save format in a binary file rather than a text file instead anyway.

3) I wouldn't put full "save files" in PlayerPrefs.

4) So the Unity engine's API is not thread safe. You're probably accessing the Unity API when serializing all your scene objects when creating your save, so I'd expect you would need to do so on the main thread rather than spawning your own save thread unless you know what you're doing. All Unity's monobehaviour stuff all runs on the main thread, so there isn't actually an opportunity for two scripts to try to save at once. Unity has recently added their new Jobs system for doing work on separate threads while generally not having to worry about thread safe issues you could look into. Unity is working on something they call ECS which works differently than using the component model of monobehaviour scripts, and together with Jobs makes Unity far more multithreaded by default.

But if you're just using monobehaviours without spawning your own threads, like any Unity tutorial would have you do right now, you don't actually have any concern about multithreading because it is all running on the same thread.

 

Hi Joe,

OMG, thank you so much! You're a champ! So much great info!

In particular, thank you for letting me know that all the monobehavior is running on one thread. THAT is exactly what was in my mind, and I'm glad I can finally put that to rest.

Just one question in regards to that: what if I run the save command inside of a method (Method B) call with monobehavior.invoke or invokerepeating? Does that make method B (and saving) run on a seperate thread, or is that still in the main thread?

Someday, I'd like to make a constantly autosaving system like in dark souls, but for sure, I'll simplify it to something I can make and maintain in a timely way. I might go with just saving whenever the player deals or receives damage, when any actor (player or enemy) receives damage (it'll be a simple 2D game). Also, I won't save the whole scene. I'll just save a minimal amount of data (enemy vector2 location and HP), and reconstruct the rest when the scene is loaded.

Thank you so much!

 

Invoke (and also coroutines) are executed on the main thread. As far as saving to disk on the main thread, if it is more than a trivial amount of data then I suggest using save points such as passing a check point in your game rather than saving in the middle of the action. This is because you may see a stutter when doing the save. But of course test the performance yourself to see what is acceptable (especially on slower HDD's).

 

Hi Joe,

Can I ask you another question?

Monobehavior.InvokeRepeating, does it stop when the scene stops? What if the gameobject is not active or is destroyed?

I was thinking of using it to manage counters or simulate regenerating life, etc every .1 seconds. But I don't want to create memory leaks if the invokerepeating never stops.

Thanks!!

 

I don't really use InvokeRepeating, but my understanding is invokeRepeating stops when the object is destroyed. It differs from coroutines a bit regarding when things get disabled as follows:

InvokeRepeating:
* disable GameObject - InvokeRepeating does not stop
* disable only the script component - InvokeRepeating does not stop

For coroutines:
* disable GameObject - coroutine DOES stop
* disable only the script component - coroutine does not stop