How does a character, who is isolated, develop? A story I'm telling has a character who has absolutely no contact with other people. Flashbacks and sentimental items are useful for the exposition, but don't provide much of a catalyst for character growth.

This could relate to video games (as in my case) or just in general: How do you develop such a character?

First, thanks for the response!

The original algorithm was a naive approach to intersection, and caused lots of problems (as you stated.) I ripped that out and went to permadi's tutorial and read over it a bit. It made a lot more sense linking the steps to problems I tried to solve, instead of going in completely blind.

The new system is working really well, except for some more oddities and bugs. The biggest of which is handling rays with undefined slope:



this results in a rendering like:


Which is quite pretty, but also quite wrong. I believe this stems from me using trig functions to determine slope and length of rays. Any thoughts?

C++, Python, and JS depending on the application. Most of work is PHP.

I strongly dislike pythons everything-in-the-same-file thing and i find the syntax for classes to be to verbose.

What everything-in-same-file thing are you referring to?

I've been building a really simple raycaster in hopes of having a better understanding on how they work. Unfortunately I learn a lot bette from tinkering than reading (permadi would be a goldmine otherwise). Through my tinkering I've ironed out a lot of bugs, but a few persist:

And here is a slightly different angle where it matches a hit:

And here's a large scale example:


I've drawn white points on all the edges it detects, and the ray is yellow if it collides with anything solid. Here's the method that drives the rays movement:

Code:

def next_edge(self):
#extends to next edge intersection, horizontal or vertical.

side = 'NS'
size = 32
ray_slope = [ math.cos(math.radians(self.angle)) + 0.0001, -math.sin(math.radians(self.angle) + 0.0001) ]
step_dir = [1 if x >= 0 else -1 for x in ray_slope]
map_position = [int(math.ceil(x / float(32) ) ) for x in self.position] # snap to grid
if self.moved:
edge_position = [ map_position[0] + step_dir[0] , map_position[1] + step_dir[1] ]

else:
edge_position = [ map_position[0], map_position[1] ]
self.moved = True
#delta should never be < 0, and we shouldn't have a floating point position.
dx = abs( edge_position[0] * size - self.position[0] )
dy = abs( edge_position[1] * size - self.position[1] )

#length of the change that will be made
distx = math.sqrt( dx * dx + ( dx * ray_slope[1] / ray_slope[0] ) * ( dx * ray_slope[1] / ray_slope[0] ) )
disty = math.sqrt( dy * dy + ( dy * ray_slope[0] / ray_slope[1] ) * ( dy * ray_slope[0] / ray_slope[1] ) )
print distx, disty,
print edge_position, self.position
print self.angle
if distx > disty:
#use disty
# [ dx = dy * delx/dely , dy + (alignment for grid)]
delta_position = [ dy * step_dir[1] * ray_slope[0] / ray_slope[1], dy * step_dir[1] + step_dir[1] ]
self.position = [x+y for x,y in zip(delta_position, self.position)]
else:
#use distx
delta_position = [ dx * step_dir[0] + step_dir[0], dx * step_dir[0] * ray_slope[1] / ray_slope[0] ]
self.position = [x+y for x,y in zip(delta_position, self.position)]

diff = [math.fabs(x-y) for x,y in zip(self.position, self.start)]
self.length = math.sqrt( diff[0] + diff[1] )

return self.position, side

I'm used to working with multiple eyes on my code for my job, so I figure this might be the best way for me to just get a sense at what I'm doing. If anything looks extremely alient to the process please point it out 

After adjusting for recentering the input, I got success! The only problem now is that it is dependent on the camera being focused on the player. I'm not sure if I'll ever have a situation where the camera won't be focused on the player AND input is enabled, but I'm still compelled to fix this (I'm sure it's just the way I'm adjusting the x/y coordinates).

Thanks for the help!

Yes, of course. Sorry I wrote this post after a long night of tinkering.





The grey line is the actual directional vector used for movement. For this example, I have 'd' held down. The red line is the imagined directional vector based on the window coordinate system that I would prefer to use. I arbitrarily changed the camera angle to better show how the grey line is in that coordinate system.

My original plan was to create a 2d point relative to the player that is {+/- 1, +/- 1} and then project that onto the 3d plane in order to create a directional vector. I believe this approach is flawed, or I don't understand what unproject does. Here's an attempt that proved fruitless:

Code:

    double          mModelView[16];
    double          mProjection[16];
    int             viewport[4];
    glGetDoublev( GL_MODELVIEW_MATRIX, mModelView );
    glGetDoublev( GL_PROJECTION_MATRIX, mProjection );
    glGetIntegerv( GL_VIEWPORT, viewport );

    gluUnProject(
        x, y, z,
        mModelView, mProjection, viewport,
        &dir_vector[0], &dir_vector[1], &dir_vector[2]
        );

For reference, my coordinate system has y as up. the variables x/y/z come from a combination of keypresses to create the {+/- 1, +/- 1} vector, where y is always 0 (not jumping).

I started the journey from 2d/2.5d to 3d, and I'm having trouble understanding the jumps between coordinates systems.

That is, when I have movement (WASD), at the moment the movement is relative to the camera rotation. The direction that is up moves with the camera, and I feel like this causes confusion for the user (It certainly does for me).

I think a much more intuitive way to handle it is to always have w/s handle y window coordinates, and a/d handle x window coordinates, and then convert them into the opengl model space. I have fiddled with unProject, but I just don't understand it.

Any ideas?