# Large-Scale Case Handling for 2D Procedural Environment

I am creating a procedurally generated side scroller and I have a question regarding proper code structure/Architecture when it comes to connecting different platforms and large scale cases. There are various platform types I need to connect (e.g. a hill which leads into a tunnel which then leads into a cave, etc). I can successfully generate and connect the meshes using a bezier curve. My problem is that the way I am handling each platform connection case seems very clunky/inelegant the more I expand.

Currently I am using switch statements to handle each scenario like the above mentioned. Below is a small snippet of how I am handling each case.

public void SetTransition(int PrevPlatform, int CurrPlatform , Vector3 LastPosition)
{
switch (PrevPlatform) {
case 0:
GroundTransition (CurrPlatform,LastPosition);
break;
case 1:
CaveTransition (CurrPlatform,LastPosition);
break;
case 2:
WaterTransition (CurrPlatform,LastPosition);
break;
case 3:
TunnelTransition (CurrPlatform,LastPosition);
break;
case 4:
WallJumpTransition (CurrPlatform,LastPosition);
break;
}
}


From here I have separate functions that handle the cases using more switch statements. The problem now is that I am starting to have a large number of branching functions that are relying each case. My code structure is becoming this large tree of switch statements. For the most part it works but I wanted to reach out to other developers before I continued this route. Is there a more effective, organized methodology to handling large scale cases?

• what do have to do on transition? it is not apparent from the description you provided Jun 9 '17 at 18:18
• Hey Sopel, What I need to do is generate correct platform for each case. The CurrPlatform is the current platform type, and the PrevPlatform is the previous platform type. With those two parameters and the last position of the previous platform I generate the mesh so I can transition into the next current Platform type. Jun 11 '17 at 3:37

Typical OO design would avoid switch statements in favour of polymorphism, and if you absolutely have to use switch statements, prefer using just one in your entire program, over an enum.

I'm not sure where your PrevPlatform is coming from, but suppose you have a Platform class:

class Platform {
abstract void Transition(int CurrPlatform, Vector3 LastPosition);
}


Then you simply override the Transition() method, like:

class GroundPlatform : Platform {
override void Transition(int CurrPlatform, Vector3 LastPosition) {
GroundTransition(CurrPlatform, LastPosition);
}
}


So that you call it like this:

public void SetTransition(Platform PrevPlatform, int CurrPlatform , Vector3 LastPosition)
{
PrevPlatform.Transition(CurrPlatform, LastPosition);
}

• Agreed, giving each platform responsibility for handling its own transition is the classic OO solution to the monolithic switch statement. What do you mean by preferring a single switch over an enum? By 'over' do you mean 'instead of' or do you mean 'using'? Jun 7 '17 at 16:04
• @Pikalek this is advice from Clean Code; if you must use a switch, only use one (typically in a factory class or method), and the switch is used on an enum instead of an int. Jun 7 '17 at 23:32
• Makes sense (there's similar advice in Effective Java), the use of the word 'over' was just a bit ambiguous, but it might have just been how I parsed it. Jun 8 '17 at 1:56

A switch statement is actually not that bad in terms of performance Switch statement O(n) is the worst case, though it can be O(1) in your case, it can grow really big, thus hard to maintain.

As @congusbongus earlier suggested, you can go with OOP. That is great approach and should be used everywhere.

But if you later would like to have multiple possible platforms that could be chosen at random for every previous platform - I suggest you place them all in an array(functions array in your case). Then you can access them by making int PrevPlatform - index of that array of platforms.

Although, if you are going to have different random platforms for different types of platforms, then stick with OOP approach from the start.