koobas.hobune.stream
How to setup a typical adventure game?
In terms of architecture, classes/objects/scripts.
I'm interested in knowing what is the typical/optimal setup in terms of Classes.
I have a Player class who has lives, health, points, money.
A Player has an Inventory.
So Items themselves has a script to detect collision, if collision occurs the item is destroyed. Then placed into the inventory. If I destroy the object. I'm not able to put it in the bag correct? Or can I put a copy of the object into the bag and destroy the original item?
Can someone by chance run through an architecture of an adventure game? Like where should scripts go? What's the best way to execute this sort of thing? I'm interested in knowing which objects should I place scripts on? Is there like Standard way? Cause I can imagine we can put scripts on any object and program it to work but that does not seem good :)
You are right that you can put scripts anywhere and it will work, and I think it's a really interesting question. With regard to architecture, I think it is better to have some guiding principals, here are mine:
Most importantly avoid duplication, if there is similar or the same code in multiple places it should be re-factored into shared code.
Next I think about where where it 'make sense' for this code to be. Should the item know how to be picked up or should the player know how to pick up an item; probably the latter.
Next I like to consider how big and complicated a class is, if there is one class doing the majority of the heavy lifting, it might need to be refactored into smaller classes composed together or inherited so that it is easier to work with.
Another thing to consider is which classes know about which other classes and how do they communicate. If the player has an 'inventory' I would try to make that communication one-way: the player calls into the inventory, but inventory doesn't know about the player. This would mean the player is coupled tightly to the inventory, you can't have a player with no inventory - that makes sense, however you could have an inventory without a player - for example an NPC might have an inventory. Loose-coupling is a general object oriented design principal which encourages code reuse as well as making code conceptually simpler. You might end up passing more information into inventory through function parameters, but the payoff is that the class is more autonomous.
These principals are not entirely orthogonal and sometimes they might conflict but most of the time they will compliment each other.
I think with regard to the items, you don't have to destroy them. Here is one possible approach:
player collides with item: disable mesh renderer re-parent the item from 'world objects' to 'inventory'
player selects item from inventory: attach to player hand enable mesh renderer
Although I haven't explicitly answer your question hopefully this is useful.
Many companies avoid this Problem by using a Non 3D element Gui item to replace the 3D Game world object so what they have is a 2d GUi inventory that houses all the items you can pick up as individually separate Gui buttons/labels or something similar. they would usually be turned off ie: not visible or clickable until the moment, When you click on the object in the game world and perform the required action( say for example"pickup") then you would spawn/make visible, Inventory item Graphic at position (x,y) in the Inventory Gui Then destroy the 3D game object
If you make all of your Pick up items "Prefabs"( which you should anyway) then you can call a Re-Spawn of that Prefab instance at any time you like in your script as necessary.
So what you have then is a frame work for any level of complexity you want for an inventory you can if you want to even use 3d Meshes in your GUI if you wanted that specific look
SO it goes..
Create Inventory GUI with slots for new buttons/objects
Create Prefab 3D game world object
Create inventory object button/mesh & set initial visibility states
Create Script event handler for 3D game object pickup include "destroy prefab, Spawn Inventory item button/mesh, and other custom functions like SFX etc
and then repeat step 2-4 as necessary remember that if you wish to remove Inventory objects you may will have to code the Reverse of that process and attach script to Inventory object/buttons/meshes
that way you can add or remove as you see fit
i am sure in the UNITY asset store t here is a prefabbed Inventory that does all this already.. if not? some one will get onto it shortly
