Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 May 2006
Offline Last Active Today, 01:18 AM

Posts I've Made

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.

In Topic: Problems with "stickiness"

22 June 2016 - 06:42 AM

Can you not have high-poly objects for rendering and lower-poly physics spheres if the physics geometry is what is driving your "stickiness"...?

In Topic: How to render my DirectX C++ Engine to a C# Panel

21 June 2016 - 08:22 AM

What exactly are you trying to do? Use a c++ renderer in a c# application? If so, passing the HWND to the renderer is just one of many many things that you need to implement, so us doing that one thing for you won't get you very far. What seems to be the problem with handing the window handle to the c++ side?


FWIW, my editor which is a C# application does this to pass the handle to my C++ renderer, which in my case is in another process so I use the network rather than a C++/CLI wrapper to do the communication, but since the value is an integer you should have no problem sending that across the language border.

public void InitRenderWindow()
    if (EditorApp.Instance.IsConnectedToGame)
        IntPtr handle = m_renderPanel.Handle;
        EditorApp.Instance.GameRPC.initRenderWindow(handle.ToInt32(), m_renderPanel.Width, m_renderPanel.Height, m_renderPanel.Left, m_renderPanel.Top);

But again, if you are having trouble with understanding C++/CLI itself we are not going to do this one thing for you because then you will be stuck on the very next task.

In Topic: Merging groups of entities into convex hulls

16 June 2016 - 01:50 AM

One more thing I am considering adding to the above algorithm is a check that the combined convex hull has the same number of points as the individual shapes. In practice this will always be 4 since we are dealing with boxes. This should eliminate the potential problem case where two boxes are close to each other and one is slightly rotated around the world up axis but the CH area still happens to match the individual shapes' areas. In this case we would not want to merge the boxes since the the resulting convex hull would not match the outline of the individual boxes.


This has not happened to me yet, but I assume it could, given the right circumstances.