Jump to content

  • Log In with Google      Sign In   
  • Create Account

viper110110

Member Since 11 Nov 2008
Offline Last Active Jul 27 2016 04:56 AM

Posts I've Made

In Topic: thesis game dev programming related

20 February 2016 - 09:30 AM

Procedural terrain generation is a common one I've seen a few people do (myself included).

 

Network prediction might be an interesting one, or implement some sort of graphical feature. I'm not sure your school's policy on working with your friends, but mine was that your part of the project had to be runnable and marked on its own.


In Topic: Game development with assembly. Where to start?

12 October 2015 - 06:48 PM

I'm not entirely sure about game dev in assembly, but I do know that rollercoaster tycoon was made in assembly except for the parts to interface with windows and directx. My guess would be that you have to do something along those lines.

 

Alternatively, make a game using ascii art?


In Topic: If-else coding style

27 June 2015 - 12:18 PM

 

 

Hi,

This isn't strictly game related, but I like you guys so I thought I'd post it here. I work with C# for my job, and we have to undergo code reviews. Yesterday I finished a work item and used code similar to the following in several places:

SomeType GetSomething 
{ 
    get 
    { 
        if (somecondition) 
        { 
            return something; 
        } 
        else 
        { 
            return null; 
        } 
    } 
}

My code review was completed as "needs work" on the grounds that the above code was "very misleading", which I don't get at all. I understand the "else" isn't necessary here, but I think it not only makes it much more readable, but perfectly follows the way the getter would work if you were to describe it in English: "If this is true, return that; otherwise, return null". Without the else, if you didn't look into the "if" block you might think that the getter ALWAYS returns null. With it, you instantly understand that either the "if" block executes and returns, or the "else" block executes and returns, without even looking at the contents of either of them.

Even if you consider the above to be unnecessary, I still don't get how you could call it misleading. It does exactly the same thing as the alternative he was suggesting (remove the else and just return), only it's much more explicit about it: which is the exact opposite of misleading.

Anyway, I just had to rant about that. I love my job, but everyone I work with is a very experienced coder from different backgrounds, and sometimes our ideologies conflict. What are your thoughts?

 

 

Personally i would invert the logic

get {
 
    if (!somecondition) {
        return null;
    }
 
    //code goes here
 
    return something;
}

 

 

I like what you did, and if I recall correctly its what resharper and/or stylecop will suggest to reduce nesting.

 

The right thing to do is to find out exactly what your coding standards should be at your place of work. If there is no hard established standard, you should ask about establishing one. Where I work, we have a wiki article describing the standard and an emacs config that enforces it.


In Topic: Lake flow

22 June 2015 - 05:50 PM

Breadth-first traversal: Start at the ocean, follow rivers upstream, set the height of each lake to max(current height, downstream lake/ocean height + some amount). Allow the traversal to revisit nodes even if they were reached from another path.

There are more efficient ways to traverse the graph if you have huge numbers of lakes and rivers, but that should get you started, anyway.

It sounds similar to algorithms used in https://en.wikipedia.org/wiki/Layered_graph_drawing , actually.

 

Sounds good, I'll give it a shot. I only have a handful of lakes for now, possibly ranging into the dozens, so time isn't much of an issue here.


In Topic: Delaunay Traingulation

02 March 2015 - 11:12 PM


I would greatly appreciate it if I could take a look at how you solved this!

 

https://www.dropbox.com/s/3nb5lkh8yybrlbs/voronoi%20stuff.zip?dl=0

 

That should contain everything I did related to voronoi/delauny. You might also need Vector2 and Vector3 classes. Everything from the link I posted should still work. Use is as follows:

        float* xValues = new float[numNodes];
	float* yValues = new float[numNodes];

	for (int i = 0; i < numNodes; i++)
	{
		xValues[i] = RandomFloat(size);
		yValues[i] = RandomFloat(size);
	}

	VoronoiDiagramGenerator vdg;
	vdg.generateVoronoi(xValues, yValues, numNodes, 0, size, 0, size, 0.0f);

	points = vdg.outputPoints;
	edges = vdg.outputEdges;
	edgeEndPoints = vdg.outputEndPoints;

You can access the delauny triangulation through:

points[i]->edges[j]->GetOppositePoint(points[i])

PARTNERS