Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Today, 04:27 AM

Posts I've Made

In Topic: Where to start with C#

02 October 2016 - 02:19 PM

I might add here that when you have learnt enough C# to move onto an engine, don't just choose Unity because it uses C#. Choose an engine on its merits such as portability and lifespan. Otherwise the whole "XNA thing" will happen again and again to new developers.

Other engines exist and there are many good reasons for that. Things that you will discover over time :)

In Topic: Why do most people recommend Python

28 September 2016 - 03:51 AM

So it looks like you have decided on C++ in the end. A good choice and frankly, my only choice (due to lifespan, support and availability).


However, I can't help but feel that you arrived at this conclusion in the wrong manner. You really need to evaluate for yourself what works rather than be told. Otherwise your next hurdle will be just as difficult for you (OpenGL, DirectX?).


Also... I don't know the best way to tell you this but "the game industry" is unlikely to have written you an email. It cannot write emails since it is not a single entity. It also has no hands making it very hard for it to write emails.


So "Mr Game Industry" (or Jason as in your other post), looks to be responding with a bias that you are entering game programming as a career. This has a massive impact on what choices you make. It means you will be working in large teams and with existing (sometimes legacy) codebases making C++ the obvious choice. Basically indie developers might well choose something else (and Python is still a very valid choice here) so still evaluate and choose for yourself!


... or if you do want to be a professional game developer. Learning them all is the only reasonable option.

In Topic: Why do most people recommend Python

22 September 2016 - 04:43 AM

Although I have only played with swift, it looks quite pleasant to use. However as a developer it is always required that you look outside the language to see what libraries are available, what platforms it can be used for and what is the future feasibility of it. I can try to answer these:


1) It only really has libraries available to it on Apple's Cocoa platform. I.e otherwise you are going to be spending most of your time writing binding layers for every platform you use it on. For example bindings would need to be written for it to use OpenGL or SDL on the Linux platform.


2) It is cross platform because it uses LLVM as its underlying technology but there is very little support on non Apple platforms. IBM was looking at getting it running on some of its enterprise operating systems but lets be honest, we wont be writing games to target them ;)


3) Lifespan... Nothing from Apple really has the best lifespan but it does look like they are committed to Swift. That said they are not going to be rewriting the OS to use Swift rather than Objective-C so you might want to stick with the latter instead. (You can also use SDL and OpenGL directly from Objective-C on non-Apple platforms ;)).


So sometimes it isn't about how easy the language is. It is about how useful the technology (and legacy) behind the language is. Otherwise, lets be honest, C would not be second from the top on the IEEE and TIOBE language stats ;).




In Topic: C++ Angle bracket function

20 September 2016 - 08:32 AM

You certainly don't need to but it avoids risk of something wrong like this:

Component(GameObject& go)

This is wrong because if this constructor is used within make_shared<T> then there will be a double delete.


Also, I prefer the template version because your example seems to take ownership from another unique_ptr (which I don't really like nd is not appropriate in a lot of situations) and if a shared_ptr was to be used instead, there is some redundant ref counting machinery happening behind the scenes. I much prefer something like this:

  std::weak_ptr<SomeComponent> sc = gameObject->addComponent<SomeComponent>();

This is good because it actively suggests to the developer that the ownership and lifespan on the component is now handled elsewhere (in the GameObject) rather than by the reference returned.


Also, arguably since the component hasn't actually been added to a game object by the time the constructor runs, it isn't quite fully "constructed" in that it cannot use it's parent GameObject or siblings. Thus I prefer the addComponent function to trigger the Awake() function (just like in Unity) where much of the processing is done. Technically the way Unity does it is a form of Two stage construction which is normally quite naff but works well in this case.


Yes it does come down to personal preference, and yes there are ways I prefer as an alternative to any of this but since my project is a clone of Unity I am a bit restricted in what I can do haha.

In Topic: C++ Angle bracket function

20 September 2016 - 03:40 AM

Why I recommend the template version is because modern c++ avoids raw pointers (shared_ptr/unique_ptr instead). These cannot be returned by a constructor and yet the memory still gets bound to a smart pointer in a list of components. Try out both solutions and I am sure you will find the template version safer and more elegant.