If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
1 Like
Hello Ben,
I have one question in mind.
In OnUserInput method >>> I changed to
public void OnUserInput (input string) {
...}
the code didn’t work when I add “public”. adding public supposed to be seen globally in the program ?
Could you please enlighten me?
Thanks!
aksoe, I think you’re asking a “really good question”.
Unfortunately, I can’t explain all the why’s and who’s but I did discover the where:
When I made this change on line 44 of Terminal.cs (from NonPublic to Public) I was able to get my game working with a public OnUserInput method in my Hacker.cs…
I think there are certain cases where being public “isn’t enough” when then public method is on a child component or something… I wish I understood better, so just forget I mentioned that, but it seems in this case, that allowing that method to be public (or not) is an explicit choice “we” make (because Terminal.cs is part of our assets, not core Unity).
1 Like
I see. So, basically, there are things like we are not working in traditional programming and if in this case in Unity, we need to make the methods private??
I am sorry, if my question dummy. Not good in programming but still not giving up 
No need for being sorry – we’re both inexperienced, so it will make understanding each-other and the core issue more challenging, but not impossible. To that ends, I’ll spill some thoughts that I feel are relevant:
-
While Unity can utilize C#, most of what we will be doing with it inherits from MonoBehaviour. This is a “wrapper” created by Unity creators that allows our code to tie-in to the game engine… it gives us the core features such as Start(), Update(), OnEnable(), etc… MonoBehaviour API
-
In order to facilitate an easy entry to coding for beginners, we were given an asset pack (WM2000) with several scripts and objects already programmed. This includes the scripts Terminal.cs, Buffer.cs, etc… I can’t personally speak to why it’s coded the way it is. As you noticed, by default, if you make your Hacker.cs OnUserInput() public, it breaks the game we’re building; I haven’t thoroughly tested, but it seemed like changing line 44 of Terminal.cs allows you to both: set your OnUserInput to public and still run the game properly.
Summary:
Frankly, I think I would consider this “traditional programming”. Very few people “do it all” themselves. (If you want to build a computer from the ground-up (virtually) check out “From NAND to Tetris” available free online. It gives you the tools to literally build a computer chip by chip from simple NAND logic gates, and in part two uses your virtual computer to write your own compiler and Tetris clone! 
) The fact that we’re using the Unity IDE and an Asset Pack is extremely traditional. We’re building our work on top of the work that others have done before us.
Please don’t give up. The bottom-line is, it seems in this case you have the option to go public or not with your OnUserInput() as long as you also change Terminal.cs.
One thing about programming: there’s almost always an infinite number of ways to do what you want; the secret is in learning the more optimal ways to do what you want. Again, I’m sorry I can’t explain why the makers of WM2000 designed it the way they did, but unless you have a really good reason to make your OnUserInput public, you’re probably better-off working within the confines of the assets as they’re presented; the main benefit being that if an update comes out for your asset(s) you can apply them without (much) fear of breaking things. Good luck!
3 Likes
Wow! Thank you so much for long kind explanations
By reading your thoughts, I think I could grab some understandings.
Let’s Fight to become better Game Developers ! 
http://catlikecoding.com/unity/tutorials/basics/game-objects-and-scripts/
That tutorial clearly described the void public dilemmas.
1 Like
hii