Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Yesterday, 01:40 PM

Posts I've Made

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.

In Topic: C++ Angle bracket function

19 September 2016 - 12:16 PM

You can check out the GameObject::addComponent<T>() function for my engine here (it is only 5 lines):




Just be aware that template functions in C++ can only really be done in header files.

In Topic: Advice on engine to use

09 September 2016 - 02:32 PM

Stardew Valley looks like a kinda neat harvest moon clone :)


Since you are looking to do a 2D game, you will find that you don't really need an engine as such. So Cocos2D is pretty good. I personally would go slightly lower level towards SDL for slightly more portability but this is a non issue at this point (and it is C not C++).


Another one you might want to look at is SFML which is not an engine but a framework and provides very similar functionality to Cocos2D.