Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Mar 2000
Offline Last Active Today, 10:11 AM

Posts I've Made

In Topic: Rpg Stats - Temporary Changes, Harder Than I Realised!?

Today, 07:33 AM

I love Hodgman's stack idea. In my games it's been a bit simpler - just store a list of modifiers/effects/buffs/whatever on the player, and when querying a stat, the query is always implemented as "base stat + (total of relevant modifiers)". In that situation you have to be careful about ordering because +10 followed by *2 is not the same as *2 followed by +10.

In Topic: Best Client/server Architecture For A Mobile Management Game?

Today, 07:27 AM

Basically, above all, I want the server to be able to know which page/screen/state is each client looking at, and be able to send them messages when another client changes something on that specific screen. It would also be nice if the solution is something lightweight on the server side to be able to scale a little.

This sounds like a simple publisher/subscriber model, or the 'observer pattern'. When a client switches to a given screen, it asks the server to subscribe to that 'publisher' for that screen. When the client switches away, it asks to unsubscribe. When something changes on the server, it publishes those changes only to the specific subscribers. How the data moves from the server to each subscribed client depends on the rest of your architecture, but there's nothing intrinsically wrong with just queueing up the updates and waiting for the client to poll for them.

I have though about using node.js with socket.io to use websockets solving the polling problem. Is this a good idea?

If the reason you don't like HTTP is because it's event-driven and requires the client to poll for data, then using Node.js seems like the wrong approach given that it's explicitly designed to be a fast performer under event-based conditions. That's not to say you can't make it work, but I wouldn't recommend it.

Lots of people seem to use a c# and sockets for unity. Would this be overkill in this situation?

I think it would work well, if you have people who are competent in C# and you have the ability to host it. There are a lot of ready-made libraries which can help with multiplayer games, often intended for use with unity.

Personally I like to use Python servers because they're very quick to develop with and you can deploy them very widely. However they don't scale terribly well (in terms of either performance or code maintainability) and you can't share code with your client.

In Topic: Game Actors Or Input Components?

Today, 04:45 AM

2. I've seen in some places (most notably in Unreal Engine) about Actors or GameActors.  Although it's rarely stated explicitly, I'm assuming an Actor in this context is an Entity that can be controlled (either player or AI)?  The reason for my confusion is in Unreal, it almost seems like an Actor is the same as an Entity, just a different name (although maybe I am wrong about this).  Or is there a fundamental difference? (Does Unreal have both Actors and Entities?)  In that case, are Actors in a pure ECS-model simply Entities with either an input or AI component?

Bear in mind that Unreal (and its terminology) dates back to the mid 90s, whereas the whole entity-component thing is a recent trend*. I would argue that Unreal have just added the concept of components to their Actors to try and make them more like the GameObjects in Unity, as part of their drive to convert indies and hobbyists over.

Most engines I've worked with still use a system much like Unreal's basic hierarchy, where there is a basic 'Actor' type - often under a different name - that represents "a thing that exists in the game world and which moves around and does stuff", and there might be a few subclasses that specialize the behavior. In that sense, an Actor is basically an Entity, but may not necessarily have interchangeable components.

(*Thief, System Shock 2, and Dungeon Siege had similar systems in the late 90s, but it's only the last few years that they've suddenly become popular, largely due to a large degree of evangelism from certain quarters.)

In Topic: An Algorithm To Decide The Cost Of Skills/techniques.

Today, 02:54 AM

I've seen several games where the cost of 'things' is calculated algorithmically, based on a formula the developers created. But often the designers want to override those values based on their own experience, because the formula may not capture the true cost or benefit of a certain skill, spell, unit type, or whatever. In fact it's often close to impossible to derive a formula that is always accurate in all conditions. And sometimes they make certain things cheaper to encourage players to use them, purely to add variety to the game.


It's common for designers to have a formula in their docs that they all work from when deciding a cost, but they don't usually have that built into the game itself for the reasons above.

In Topic: User Interaction System Ideas

22 July 2016 - 07:29 AM

On a very abstract level, this could be:

1) Find out what was clicked on (the target)
2) Determine any properties of the click (eg. "in distance")
3) Find out what object the player has selected (the tool)
4) Find the best match in a table of actions, where 'best match' is probably the one with the most conditions


click_actions = {
    {obj:"tree", properties:["in_distance"], tool:"axe", action:"cut_tree"},
    {obj:"tree", action:"move_to_tree"}