Jump to content

  • Log In with Google      Sign In   
  • Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

frob

Member Since 12 Mar 2005
Online Last Active Today, 04:45 PM
*****

Posts I've Made

In Topic: [Future-Proof]Should we try to follow the new technologies? Or going back to...

Today, 03:24 PM

Technologies and languages come and go, it is only algorithms and data structures that you can rely on.

When it comes to languages, it doesn't matter if you are programming in C, C++, Java, Perl, Python, Ruby, Eiffel, Erlang, shell script, or something else entirely. They come and go. Use whatever gets the job done.

The same with technologies. If you can get an app written in MFC, or WPF, or Mono, or Qt, or something else, then use whatever gets the job done at present.

Let's imagine it in other disciplines:

There will be better musical instruments than mine, so I'm not going to play.
There will be better paints, brushes, and canvases than mine, so I'm not going to paint.
There will be better hammers, nails, and building materials than mine, so I'm not going to build.
There will be better landscaping materials than mine, so I'm not going to landscape.


You say you have the basics down. That is enough. Go from there. If you find a tool or technology is useful then employ it, but otherwise just keep going and do your best with what you have got.

If you spend your days just trying to"sit back and wait for the future", you will find the present will have passed you by while you were playing. You may suddenly discover you are left with nothing but "could have" and "should have" to keep you company.

In Topic: Making a "Busy Loop" not consume that much CPU (without Sleep)

Today, 12:05 PM

One of the better options for a short wait is to use the WaitableTimer object. It can be set in (approximately) 200 nanosecond increments, then use WaitForSingleObject (or similar) to wait for it to trigger. There is more on MSDN. Be sure to pass a NEGATIVE time value so it knows the value is relative, otherwise you'll be setting timers that trigger back in the year 1600 or so.

Ultimately, even this solution isn't guaranteed. Windows simply is not a real time operating system. With a waitable timer you will probably get woken up about when you expect, but your thread can be suspended at any time, and the granularity for resuming threads is roughly 10ms. This is just a fact we get to live with.

In Topic: Receive packets in the thread or in game render.

Today, 08:30 AM

C0lumbo is pretty much on track.  Process all messages that have arrived rather than just one, and look at your frequency of messages.

 

I have moved this question to the Networking forum where it belongs.  Check the Forum FAQ and the links it contains, especially Q12 and Q14.


In Topic: [c++] non-recursive way to iterate tree

Yesterday, 04:22 PM

For a a scene tree the best solution is to use recursion ?

Usually a world has multiple data structures involved.

 

A scene or level or world is usually going to be used for many frequent searches and lookups.  Queries are both for existence and also for position. There will be frequent changes to objects in the world.

 

 

 

Generally there is a hash table containing all the objects.  The hash should be a guid assigned to each object.  This is generally the master list.

 

There is also generally a spatial tree, such as a loose quadtree, that indicates where the guid lives in the world.  When an object's position is updated this spatial tree needs to also get updated.

 

There may be yet another graph, called the scene graph, used for display.  Quite likely this graph is not part of the game world since it is part of the renderer's responsibility, not world management's responsibility.


In Topic: how to do this in c++

Yesterday, 02:04 AM

So you say better OO approach is to let the world logic tell what accessibility there is between buildings? the reason for each building to have this information is because if there's a wooden bridge then humans can travel across it, but heavy donkey carts cannot because the bridge might collapse so they need to use stone bridge instead.
every time i add new type of these buildings the pathing possibilities increase.
so i might be moving the conditional code outside the class but that seems to require keeping a list of class vs class accessibilities.

Are you remembering to program to interfaces, and also to use composition?

Everything that exists in the world is a game object.

Some game objects are portals. They should implement a portal interface, or if your design prefers, they should have a portal component.

I'm guessing your portal would be like ours. A portal has some number of lanes (usually 1), and the routing system automatically routes near the portal, waits for a lane to become free, marks the lane as in use, then travels across it. Only certain units can travel across particular lane types. There is an animation that plays (very similar to the basic walking cycle) when a unit travels between the portal endpoints. And finally, you can place multiple portals together end-to-end and have them work continuously.

We have many kinds of portals. They include bridges, ramps, stairs, doors, and elevators.

For us, we simply add a portal component to a game object, fill in a few functions that the interface requires such as the portal type and the animation names, and routing automatically picks up whatever new portal type we added.

PARTNERS