Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 May 2006
Offline Last Active Yesterday, 08:38 AM

Posts I've Made

In Topic: Angelscript - C++ Object Destructor Not Getting Called

10 August 2016 - 04:04 AM

Curious, I just checked the code again and now it works. To my knowledge, the only thing I added since starting this topic was to add the assignment operator (for other reasons), but commenting that out does not seem to stop the destructor from being called.


I honestly don't know what made it work but I will let you know what the problem was if I figure it out.

In Topic: Angelscript - C++ Object Destructor Not Getting Called

10 August 2016 - 03:45 AM

What does asGetTypeTraits return?


Stepping into the function with the debugger shows that it correctly detects the constructor, destructor, assignment op and copy constructor. So that part should be ok.



In Topic: Angelscript - C++ Object Destructor Not Getting Called

09 August 2016 - 11:25 AM

And, for the record, when creating a temporary string in a similar fashion in AS the DestructString() function is run. I have a hard time determining what the difference between my case and the string case is.


Any ideas?

In Topic: Game Engine Advice

29 July 2016 - 12:34 AM

Here is a good book on game engines, written by one of Naughty Dog's programmers: http://www.gameenginebook.com/

In Topic: Game Actors Or Input Components?

24 July 2016 - 04:54 AM

I would advise against having an input component that reads straight off the input hardware. It makes it unnecessaily difficult to switch the object that is controlled by the player. For example, lets say you have a character that walks over to a car, gets in it, and drives off. At some point you want to switch the controlled character to the car, possibly removing the character object at the same time. While this is certainly possible to with an input component you have to be very careful that the car and the character dont exist both for a frame or two and happen to both read a key press that causes them both to do something only ever a single object should do at any point in time.

Another example is having the capability to control an enemy character during development. Being able to switch to another character by clicking on them is priceless when testing certain gameplay features.

The solution to this is to have an additional layer between the input hardware and the objects, called a controller. In my engine each controller can have zero or one objects called their "avatar" which is the object that controller controls at the moment. I believe Unreal calls this "possessing". Each human player that joins a game gets their own controller (which can also handle things like key-remapping etc that game objects really should not care about).

Communication between the controller and the object is done through messages. This means that you can make a common movement interface for both your player character and enemies and simply switch the avatar object of the controller. The movement will work the same for both. If the player character can jump but the enemies cant they just wont react to the jump message.

Regarding AI characters, I am not really sure having their behavior be driven through a controller is necessary. In networked games it makes sense, but for single player games I usually have a component that drives their internal AI logic. If the object becomes the avatar of a player controller, the AI component simply switches off.