Hey Keith,
Do you know if Rick actually monitors these posts? I am a little reluctant to tag him directly as it was a fairly minor query.
None of the instructors really spend a lot of time reviewing posts on the forum, so if there are course specific questions you are better posting those within the Q&A on Udemy where one of the student instructors can either resolve or escalate. That said, often if you tag Rick and often Sam you will have them reply, hence the tag 
As you suggest I could have a go at implementing the suggestions myself and posting the results.
It would be very satisfying to achieve an enhancement on your project like that.
Regarding the more specific queries⌠there are ways you could still incorporate the scriptable objects for the state and also have a non-scriptable object based inventoryâŚ
You would probably need to dial the idea down to its basics initially, i.e pause the randomness, and get a model working first, then introduce extra ideas/concepts. Iâd go as far as just including collecting items initially also, e.g. I wouldnât worry about dropping them. You could then enable options within your states based on whether the player has an item or not. That could be phase one.
You could use the scriptable objects to store where objects in the game spawn initially. The kitchen has a knife. The study has a book. Nice and basic, but initial spawning points.
You would want some form of collection/list/array associated with the player to hold the items they have collected and remove them from the scriptable objects when taken.
Once you have some functionality it will be much easier to build upon it. So after this Iâd probably look at then dropping items. Have the states store what has been dropped, so maybe I take the book from the study, walk into the kitchen and drop it, now thereâs a knife and a book. That suggests that the states need to be able to store a collection of items, not just one, and so the design gets tweaked a little to support that.
Maybe next you introduce Take All and Drop All, just as a player convenience, but youâd already have the main functionality required to implement that, so its a nice win.
You could increase the complexity for the options on each state, so for example, perhaps an option has a reliance on an item. You could make some design decisions with regards to what happens under these circumstances, for example, do you not even show the option that relies on an item if they donât have it, or do you show the option but then handle what happens when they try to use the option without the item. A door is a nice example of this. â2 - Unlock the door and walk throughâ, this could just tell the player that they need a key.
You could later consider the number of items a player can carry, which may make them have to think about what they take, and/or when they drop items to take others instead.
In the block of text above there are a lot of features, but remember, it all started small and got built up bit by bit. This approach would give you the opportunity to build something to suit your game and the direction you want to take it in.
Hope the above is of use
