GameObject.Find(...)

Convoluted messaging systems that use enums as parameters are all the rage in avoiding confusion. I think you must have missed that lesson in coding 101.

It's one of the real downsides of being a self taught programmer. My code just gets the job done and moves on.

 

Microsoft programmers who designed Windows API and its MFC 'wrapper' system, that is still in use today by one of the largest software companies on the planet, would disagree with that comment.

In my view also, it is a good solution in the interests of avoiding spaghetti code like function calls between modules or objects. And a great consistent way of making code easy (or easier) to get your head around once you are up to speed with the coding standard.

And as I have previous said, with my 'salute' to the Microsoft standard, there is only one function name throughout all my scripts in which I need to place all my break points when debugging inter-object communication.

There are no doubt ways that I can improve a solution as my knowledge of Unity and C# builds. But, given my current level of knowledge, I feel I have made a respectable stab at it.

You may not like it, but in the end it comes down to a difference of opinions.

 

Look I am self taught in electronics and Arduino microcontrollers over the past 18-24 months.

While I have a respectable amount of knowledge, that knowledge is rather piecemeal.

And I KNOW that I would benefit greatly by undertaking some sort of formal coarse (if I could afford it) to fill in the many holes in my knowledge.

Coding is no different.

I started off with formal training in Pascal and then later C / C++, with several years as a medical scientist in between.

From there I went to commercial experience in MFC / Visual C++ programming, and a short Microsoft coarse in MFC programming.

From there I taught myself ASP and Javascript, followed later by PHP and CSS, which resulted in my website http://www.gregsindigenouslandscapes.com.au/

But even here I bet I would benefit from a short course PHP, javascript and CSS and I bet there are ways of using these that I am not yet aware of.

While formal training does not guarantee that you will be a good programmer, maintaining that you would not benefit from it seems a little arrogant to me (not you personally of course)

 

DoDispatchMessage(...) is not a virtual function - all my scripts point to the exact same function in the base class.

The function that DoDispatchMessage(...) calls is the virtual one with overrides in all scripts that are actually attached to a game object.

So I am at a bit of a loss as to why SendMessage("DoDispatchMessage",...) works just fine and sees me stepping through all the override functions

But McCormickMonoBehaviourBase s......s.DoDispatchMessage(...) sees me stepping through McCormickMonoBehaviourBase.DoReceiveMessage(...)

If I was attempting this McCormickMonoBehaviourBase s......s.DoReceiveMessage(...) then I would understand.

It seems as though, given the way that Unity apparently implements scripts, McCormickMonoBehaviourBase s renders all the derived classes, and therefore function overrides, invisible/non-existent.

 

I think folks are just responding to your constant touting of your education, which ultimately has no meaning in this world. There are many paths to mastery here. And also your resistance to the advice you're asking for isn't generally taken well - if you're asking for advice, don't make excuses for not following it.

 

Dave I have accepted some advice but other advice I simply disagree with.

And I have been searching the unity forums about various pieces of advice in this thread and there is great deal of divided opinion on much of it regardless of whether or not I have accepted it.

As to ditching my class hierarchy in order to fit in with Unity as it is at present ....any advice to that end I am simply never going to agree with. If Unity pro-ports to be an object oriented environment then it should support all aspects of inheritance and polymorphism across the board.

Based on all my training and experience, repeating the exact same segments of code in multiple scripts, because you can't use inheritance and polymorphism, is simply not good programming practice.

I have found a work around through SendMessage(...) (until a better solution presents itself) and, as some ones else said in another thread I was reading: "This is not a problem until it needs to be".

 

I have started listening to Jonothan Blow's video and have gotten as far as his arrays of records.

That suggests that I should consider ignoring the advice re how slow GameObject.Find(...) is a not bother with my binary tree thing. Not that a binary tree is onerously difficult to code or complicated to understand.

Perhaps I might implement it anyway, as an exercise, but not use it until such time as a real need for it arises.

And my current class hierarchy really has nothing to do with optimising, with fancy algorithms, how fast the code executes, rather how many lines of code I need to write and maintain with future apps.

UPDATE....

It just occurred to me that C# probably has the equivalent of a PHP associative array and, after googling, it appears to be Dictionary<type, type>.
That would be a far more convenient choice than a binary tree - don't have to stress about an unbalanced binary tree or implementing a re-balancing function.

How efficient are Dictionary look ups compared to GameObject.Find(...)?

 

Made it home and coded up a test project for you.

https://www.dropbox.com/s/ujjpvcdpjmpjrrc/InheritanceTest.zip?dl=0

Code (CSharp):

1. public class BaseComponent : MonoBehaviour
2. {
3.     public virtual void Test()
4.     {
5.         Debug.Log("This is the virtual method Test on the BaseComponent");
6.     }
7. }
8.  

Code (CSharp):

1. public class DescendantComponent : BaseComponent
2. {
3.     public override void Test()
4.     {
5.         Debug.Log("This is the overridden method Test on the DescendantComponent");
6.     }
7. }
8.  

Code (CSharp):

1. public class TestComponent : MonoBehaviour
2. {
3.     void Start ()
4.     {
5.         Debug.Log("GetComponent<BaseComponent> and calling virtual method");
6.         var component = GetComponent<BaseComponent>();
7.         component.Test();
8.     }
9. }
10.  

The final class gets the component using BaseComponent as the type. The call to Test prints out the message from the derived class, as one would expect.

It works, you managed to do something wrong.

 

Thanks for that, I will check your code out but it is bed time now.

Dictionary<string, GameObject> seems to be a far more convenient solution for getting rid of GameObject.Find(...) and transform.Find(...) than a binary tree......assuming Dictionary look ups are themselves not slow.

It suddenly occurred to me, due to one of the posts in here about C# / Javascript / PHP, that C# probably has associative arrays like I have used extensively in PHP with my website.

As an added bonus it would allow me to have just one version of my SendMessage(...) function and further reduce and simply by base class.

On the assumption that, if you have any duplicate game object names, then you don't need to find them.

 

Would they disagree? I know I frequently look back at how I designed things in the past and shake my head.

 

All programmers do that, since if you are any good you are constantly improving on your skills.

 

What ? GameObject.Find not removed yet?

 

None the less Microsoft's Visual Studio and MFC is vastly more successful and widely used than Unity.

So it is the height of arrogance for Unity developers and users to assume they universally know better than, and can't learn anything from at all, the Microsoft developers who came up with MFC etc.

There are undoubtedly aspects of the MFC coding system that could be improved, but never the less , it is a good coding system/standard that lets you build and maintain applications quickly and simply.

In general 'old' does not necessarily mean 'bad'.

If people in here want to talk about 'nerd rage'......then I suggest some ought take a look in the mirror!

As was said "Let he/she who is completely without sin, caste the first stone"!

 

Height of arrogance? Perhaps. But it's also pretty arrogant to come into a community and tell everyone who has been using the engine and framework for years that they are doing it wrong.

Anyway, I'm out. I feel like I've been talking to myself most of this thread anyway. Best of luck.

 

It worked for me as well Dave. I'll have another crack at my effort and see if I can figure out why it is doing what it did.

 

Again, just because some one is new to Unity, it doesn't automatically mean they have nothing to contribute from past experience!

All I have really suggested is that it does not make much sense, in an object oriented environment, not to use inheritance and polymorphism to the fullest extent in order to reduce the number of lines of code you have to type.

And I don't expect people to adopt MFC standards, I am merely puting it out there as an alternative to what I have seen in Unity examples to date.

Like I said, my salute to the MFC developers seems to be working well for me with this current project so I will continue to use it......until such time that it falls short of my requirements in future apps.

If you have a hatred for anything Microsoft or anything 'university' then what ever - at the end of the day I don't really care.

But I will contribute them regardless in case anyone IS interested in trying it.

OR in case anyone points out a better alternative to me that I like the look of.

 

.NET is from Microsoft too - Unity is just utilizing that language - they didn't invent it. The standards for coding in .NET aren't the same as coding in MFC, and yet both were created by the same entity. You're more than welcome to try to duplicate what you've used in the past, but in my experience you're often better off embracing the new paradigm that comes with a new language. Don't fight against the intended usage. But that's just me.

 

From what I have seen of it.net coding standards resemble MFC, in some ways at least.

As I understand it the purpose of .net is to provide standardized class interfaces for communication between DLLs, software packages and such like.

Where as the purpose of MFC is to provide a OO layer between windows API messaging system and your application.

If Unity is designed solely to produce stand alone android apps etc, that don't need to communicate with other modules and software, then perhaps using .net coding standards are not necessarily appropriate.

But I have not yet used .net much so I don't have a complete understanding of its coding standards etc. Perhaps if I did then I would like the look of that standard more than the MFC one.

All I am suggesting is that it is silly to dismiss something simply because it has been around for a long time.

The old MS DOS 6.22 batch file system is ancient. But it can, never the less, still do things that the modern windows wisywig file management system cannot do, at least not that I have been able to find. E.G. You can't freshen files - you either copy everything or nothing and you have to be sitting in front of the screen to do so. Where as with xcopy in a batch file you can copy only those files that are different between source and destination and you don't need to be sitting in front of the screen apart from kicking off the batch file.

I use a batch file to backup my personal data - I just kick off the batch file and walk away.

If I use the all or nothing wisywig windows file manager to carry out the same task, it takes a couple of hours to copy a handful of changed files to several backup locations.

Please correct me if I am wrong here.

 

It's not a matter of what is better. Everyone is just trying to make you learn the intended use cases of unity and .net before you bring ideas from elsewhere. You should try and get a solid understanding of how things are done in c# and unity before adding your own concepts to the mix.

It's the same for learning any framework or language. I know many languages all which have effected how I work as a programmer overall. But i always do try and learn the existing standards of a framework or language before i bring in my ideas from elsewhere.

Also c# does support all the same concepts of inheritance and polymorphism as C++ so really don't know where you are getting that idea from.

 

I know it does - I picked that up very quickly.

But what I am still having difficulty with is how Unity API supports it all through its GetComponent<MyScript> interface between game object and scripts.

But BoredMormon has provided me with a simple example where he has obtained a handle to a script base class and invoked a override function in a derived class.

So I admit defeat. It is not that Unity does not properly support polymorphism, it's have more work to do in understanding how Unity's GetComponent<MyScript> interface between game object and script works.

It would be a rather big help if the online Unity documentation went into some what more detail specifically about GetComponent<MyScript>.

 

I can probably begin to see how I could use interfaces in place of an integer based messaging system like in Windows API. But I am not sure I can see why interfaces would be any less bug prone than an integer based messaging system, as has been suggested.

Anyway I am not going to attempt to use interfaces until I understand them better.

And I am still some what attached to the idea of having to debug one single function name across all scripts rather than multiple function names defined in an interface or interfaces.

And Bingo3D, as my third app or so created with Unity, is a very trivial project. Integer based messages and 6 parameters is totally fine for such dialog box like apps but I concede that it is probably completely inadequate for complex games like clash of clans or what ever. I will adapt my approach as the need arises.

 

Right, but being more successful and widely used doesn't automatically make it superior. Just like the VHS tapes that beat out Betamax. Betamax was the superior format, but VHS is the one that caught on and once it reached a critical mass it became outright impossible to replace by any other format until a very good reason came along (like high definition).

It's great that it works for you, but at the same time it seems to be pretty contrary to the way everyone else is using it. It wouldn't surprise me if the original developers of MFC no longer felt like it was a superior path to go but have little choice other than continuing development because it caught on to the degree it did. A bit like how Intel designed the 8086 as a temporary platform but it became permanent and they're now stuck working around it.

 

As with code optimisation or not in android games, the fact that Betamax did not catch on, despite its superior quality, suggests that there were probably other factors (apart from quality) that made VHS superior in the eyes of consumers. Can't comment to specifically because it was before my time as an adult.

I have a copy of visual studio 2015 Community and MFC is still at the heart of any application you write that runs under the windows operating system. If it was truly that out dated and useless then commercial developers wouldn't use it, and I know for a fact that two still do.

Including Victorian Tabcorp with their Easybet terminals in pubs and clubs across Australia - I formerly worked for Tabcorp for a short time and maintained that particular software.

Sure Visual Studio 2015 has expanded to include other platforms, including android, since I worked in the IT sector.

 

Here you go Ryia:

And the quality of Betamax was apparently only marginally better than VHS anyway.

 

yes I was wrong

I was doing my test wrong initially. Assuming it searched by alphabetical order, when really it searches in order of creation.