I have to save some user data from the application on which I'm working.  It's a dictionary, so the data are an array of "WordList" objects, each of which contains "Word" objects.  The structure is something like this:

Array(
    WordList(
        Word,
        Word,
    ),
    WordList(Word)
)

When I serialize using ByteArray.writeObject(array) or SharedObject.data.object=array, the data is output in JSON format - a big nested hash table.  So the types of the custom Word and WordList objects are not preserved.  They all just identify as "Object".  Any values in them are set to null.

I can preserve the WordList type by casting the SharedObject as a WordList when I read it, or by using registerClassName('WordList', WordList) to associate the class name with the data.  But this doesn't help me with the "Word" objects inside "WordList" -  they are still read as "Object".

If I can't find a way around this, I'll just write a "Session" class with my own save/load functions.  Would be interested to see what other people have done, though.

Mercifully, I think I can easily get approval from management.  We have been developing rather slowly, and my boss isn't happy with the way the project has stagnated.  It's just a question of whether to add another layer or wipe the slate clean. 

Now, to come up with a better GUI architecture is a whole different problem.  I'll probably borrow heavily from the design of TK or some other no-bullshit library.

I was brought in to work on an "educational" game for a local company.  The app is very similar to the old Freddi Fish games - there is a network of scenes that you can traverse by clicking on items in a scene.  So I expected that building it would be like building a GUI - you choose a widget, set a layout, write the callbacks, then add children and repeat from there.

Here is what you actually have to do to add a new window.  In this example, I'm adding a "Scavenger Hunt" scene, which has a main window and a side pane.

• Make three new classes, "ScavengerModule", "ScavengerDisplay", and "ScavengerPaneDisplay",  which  handle the behavior, the rendering for the main window, and the rendering for the sidebar, respectively.  All of these classes inherit from a class hierarchy five generations deep. 
• Go into a class called "ModuleUtils" and add a reference to each of the above classes, or they won't be compiled.
• Add the text and image references to a "module descriptor" in an external XML file.  There's a separate module descriptor for every setting, so I also have to create a new "ScavengerModuleDescriptor" XML Element.
• Add a reference to "ScavengerModule" in the "ActivityController" class, which switches application states.  There's also an AudioController, InputController, LoaderController, etc. (13 classes in all).

Is this overkill?  It seems excessive to me, but every programmer thinks their way is best, and this boilerplate may be a necessary evil for a large GUI program.  I could use a second opinion.

It is something to be used sparingly, but it has its place.

OK, let me see if I have this straight.

In your gamepad example, instead of the controller dispatching an event and the game objects listening for it, you could have the controller call a "is-plugged-in" function that affects all the game objects.  But that would require you to track down all affected game objects and handle each of them within the "is-plugged-in" function.  And the function would need to change any time you added or removed game objects.

The observer pattern lets you broadcast a single signal -- which doesn't change -- that can be picked up by any number of game objects.  And the code for how each object responds can be written near that object, where it makes the most sense (decoupling).

TL;DR  It's simpler to have one wireless router for a room full of laptops.  But it's not simpler to have a keyboard with a separate transmitter and receiver for every key.

Is there any benefit to using the observer pattern?  All of the supposed solutions I've seen just make the code slower, buggier and illegible.  I suspect it's one of the following:

• An elegant solution to a problem that never occurs in the real world ( e.g. Lisp)
• An elegant solution that is never used correctly in the real world (e.g. object-oriented programming)
• A clumsy solution that is used because it's a good way to look busy (e.g. Java )

Somebody please post a code sample that proves me wrong.  I WANT TO BELIEVE!

LOL, thanks for the bump!  I'm using Panda3D, which is written in C++ with a Python interface.  To minimize porting problems, I avoid code that is not either written in pure python, or already in the library. 

The engine already includes triangulation with Seidel's method, Bullet physics, pygame, and numpy, so between those libraries, I can accomplish almost everything I need.

There are a few things which I regrettably had to drop.  Triangulation of polygons with holes, light mapping, and constructive solid geometry.

This is a really interesting discussion.  I just had this same argument with one of my co-workers, who uses assertions all the time while I avoid them.

We came to pretty much the same consensus that I see in this thread.  Assertions are easy to misuse, if you use them to avoid learning about how your code works and sweep errors under the carpet.  But they're invaluable for debugging, where, by definition, you don't know how your code works, and no elaborate chain of if-statements will tell you what went wrong.

Glad to see someone else is questioning the conventional wisdom though...

This is all very helpful, thanks to everyone!  nyyjen, thanks for that link about non-resident business owners. 

I think the US is the only first-world country that taxes expats.  So I am prepared for double taxation, although I'm not likely to make enough that I need to pay it. 

I would probably incorporate in the state where I grew up - I know more about the business environment there, and there are more people I would trust as a resident agent.

Interesting.  Anyone know about state and municipal residency?  For example, am I a resident of the state I lived in last, the state I lived in longest, or can I declare residency anywhere?

Thanks very much.  If there's a choice, I don't really have a preference for where I start the business.  I really just want to know that there's a way to legally sell my projects if they become popular enough.  I think the business environment will be better in the US (especially after the election), and taxes will be lower.

Would you mind telling me why you chose the specific countries you did? 

don't move the camera move the near plane instead for better visibility and framing. Advence tips is to have a framing effect when the near plane is moved along with a slight forward offset to indicate there is an obstacle. Even more advance is to have a collision box that scale with the near plane + some margin, perfection might be too much but using that collider to register collision, previous movement and line of visibility, but that's too far, just move the near plane and the camera with a fixed offset.

That's a good idea.  I have had problems with the player squeezing through alleys smaller than the near field and getting culled out of the scene.  Until now, I thought this was unavoidable.

I like the framing effect when it's used in RPGs.  But the karts go so fast that advance warning of obstacles isn't that useful.  I'll consider it, though.

I have tried the collision box method, and it was too complicated to justify the few times where it was helpful (partly due the narrow alleys I mentioned before).

Thanks! I should have been using the kart velocity vector all along.  What I really needed to see was where the kart was moving, not where the player wants it to move (kart angle). 

Keeping the camera out of walls is pretty simple.  I cast a ray from player to camera and move the camera to the first intersection with collision geometry.  You can still see inside buildings at extreme angles, but I'm not a perfectionist.

Combining these with an increased follow distance at higher speeds makes a pretty solid default camera.  I eventually want to allow the player to choose from a series of dramatic camera angles (flyby, orbit, Ronin, Battlefield Earth, etc.)  and award them points for completing an entire uninterrupted "shot".

I'm a US Citizen, and am going to be working for a German company, in Germany, for at least a couple years.  Under these circumstances, what are my options for selling my self-developed games?  I've read Derek's sticky, but I'm not sure how much of it applies to expatriates.  Anyone run into this situation before?

[Camera A]

I'm trying to implement a chase camera for a kart racer, and am never really satisfied with the results of my setup.  So far I've tried 2:

Camera A is stationary, and is constrained to stay within an adjustable radius of the kart.  Works well for open areas, but in close corners it's possible to scoot around a corner and be blind until the camera catches up.

Camera B is fixed an adjustable distance behind a "floater" node that lies just above the kart.  When the kart rotates, the "floater" rotates to catch up with it at an adjustable rate.  The main problems are that it restricts the field of view, and goes crazy during crashes as the camera struggles to get behind the kart.  Not sure if this is a problem or not.

I will probably end up doing some combination of these 2, dependent on linear velocity, angular velocity, and proximity to walls.  Curious to see what other people have tried.

A lot of old arcade games had an "attract mode" that would try to attract players with a pre-recorded demo.  The most recent example I've seen was Quake 1, where speedrunners would record "demo files" and pass them around instead of exchanging (much larger) video files.

Has anyone successfully implemented this?  I suppose I'll be recording, at minimum, the seed of the random number generator and every in-game event. 

Thanks very much, that was exactly the right solution.  The documentation for struct is rather cryptic, but there was a longer explanation in the "Programming Python" O'Reilly book.

My file begins with a header consisting of the values 12358113, 2, and 8.  I can read it as follows:

Code:

file=open("/media/sorghum_data/merged_041012.dat", 'rb')  #Open file in binary read mode
data=file.read(12)  #Read 12 bytes (three 32-bit integers)
unpack('>3i', data) #Unpack, based on an assumption of three big-endian (>) integers

This results in:
(12358113, 2, 8 )

I have some binary files that were written by a java program with a series of calls to outputStream.WriteInt(), outputStream.writeFloat(), etc.  Ideally, I would like to read them via a Python script.  Has anyone accomplished this before, or am I stuck making a text format for portability?

Thank you both. I managed to write something that works with my test data.  Will probably require a bit more hacking, but I'm on the right track.  Will paste it here for posterity.

Code:

#Two unit squares one unit apart
segments=[
( (0,0), (1,0) ),
( (1,0), (1,1) ),
( (1,1), (0,1) ),
( (0,1), (0,0) ),

( (2,0), (3,0) ),
( (3,0), (3,1) ),
( (3,1), (2,1) ),
( (2,1), (2,0) )

]

#Build adjacency list
nodes=dict()
for line in segments:
start, end = line
if start not in nodes: nodes[start]=set() #Add blank neighbor list if endpoints haven't been seen yet
if end not in nodes: nodes[end]=set()
nodes[end].add(start) #Otherwise add each endoint to the other's neighbor list
nodes[start].add(end)

#Assemble connected nodes into polygons
polygon=[]
polygons=[]
currnode=None

#Loop while some lines are left in the adjacency list or the last one is still being built.
while len(nodes)>0 or currnode !=None:

#If no polygons are being built, start a new one with a new random node.
if currnode==None: currnode=nodes.popitem(); polygon=[currnode[0]]

#Check neighbors of current node.  If one is connected to a remaining node, it becomes the new current node
#and is added to polygon.  Otherwise, this polygon is finished.
for neighbor in currnode[1]:
if neighbor in nodes:
polygon.append(neighbor)
currnode=(neighbor, nodes.pop(neighbor))
break
else: currnode=None; polygons.append(polygon)

print polygons

I have an algorithm that generates a road network, and then plots the line segments that separate the road surface from the surrounding terrain (see below).  Right now, these segments are all in one huge array.  I'd like to group them by the polygons of which they are a member.  For example, you can see two octagons in the picture below, but the line segments composing them are not in order or even in consecutive array elements.

In my first attempt, I looped through the line segments one at a time, and partitioned them into polygons.  I compared each to the existing polygons to see if its start or end point overlapped with any of their segments.  If the segment didn't match an existing polygon, I created a new one and added the segment to it.

I'm pretty sure I could get this approach to work eventually, but it's kind of ugly.  Something tells me I should be using some kind of linked list or tree structure. Any thoughts?


 

[road size > terrain resolution.]

I want to make a racing game  in the same vein as Midtown Madness and Crazy Taxi.  That is, you would make short trips through an open world, rather than one long circuit of a predefined track.  So the game world will be a large, computer-generated city, with a small area of high-res geometry (roads) and a large area of low-res geometry (buildings and fields). 

I've made some attempts to generate the mesh from scratch, using 3D floating-point coordinates, but that way lies madness.  The math is just too hard for me, and I would be breaking too much new ground.  Most terrain generation work has been done with heightmaps.  So I'll calculate road, river, and building locations based on a heightmap, then somehow transform the heightmap to a terrain mesh. 

I have three ideas, each with its own tradeoffs:

road size > terrain resolution. 

The world is one humongous heightmap, and roads are flat areas carved through the heightmap. 
Pros: Programming is easy.  Everything's just one big mesh.  Roads are acceptably smooth, and can easily have variable widths and intersections.
Cons: Heightmap has to be enormous to hold the entire world.  Produces a lot of unnecessary detail, since even vacant lots have the same resolution as hairpin turns.  Would slow down level generation, rendering and collision.

road size ~= terrain resolution.

Roads are made out of modular chunks, like a Brio train set, about the size of a heightmap pixel or the terrain mesh's xy spacing.
Pros: Can have high-res roads with a smaller heightmap.  Easier to design and mod.
Cons: Would have to check collision with road segments as well as the terrain.  Not as much variation in level geometry (lots of zig-zags in long grades or decreasing-radius turns). 

road size < terrain resolution.

Roads are high-res meshes draped over a chunky mesh generated from a heightmap.
Pros: Can cut out a lot of visible geometry while still keeping roads smooth.  Roads can be more realistic because their shape is not constrained by the terrain.  Possibly easier to make tunnels and overpasses.
Cons:  Programming is harder.  I've heard that these terrains are prone to "Z-fighting" because the road is a separate mesh that sometimes intersects with the terrain.  Would have to either integrate the road with the terrain mesh or see that they don't interfere with each other too much.  Would have to check collision with road segments as well as the terrain.

Any comments?