This is a very barebones class so far, but what I plan on doing for the level implementation is having a sort of buffer system (similar to that of texture swapping). There's two dictionaries holding 2 sections: One that's currently being used/made and one that will need to be used/made next.
Based on that system, when the class first initializes it parses the script into one dictionary, then generates the appropriate length of the section based on the parsed file. Finally, it adds the obstacles (blocks above ground level) to the stage and completes the entire layout!.
Here's an example text file:
Test.txt
0,0,0
0,0,0
0,0,0
1,0,0
1,0,0
0,1,0
0,0,0
0,0,1
0,0,0
1,0,1
0,0,0
0,0,0
0,2,1
Now here's what the Level Generator class outputs (red light was used to help distinguish blocks):
The class will later have a system implemented for the treadmill/movement effect as well as testing for when the next section will have to be loaded. It essentially works off of the "InitializePlane" and "InitializeObstacles" methods.
The text-based level generation is a huge part of our game design; allowing use to create levels fast and efficiently for our limited project scope.
Group Members/Anyone Reading, let me know if you have any suggestions/other features you need me to add in coming weeks!
-David
***UPDATE***
Here's a demo of the generator in action! It loads the same script 10 times, but it works nonetheless. Feedback is appreciated.
Level Generator Demo
***UPDATE #2***
Sorry to keep spamming these updates, I just keep implementing new stuff that I want your guys' feedback on. I revamped the level gen system to no longer use the stupid file buffering system, but instead read in all files and then generate/destroy cubes based on player progress. Here's a video demo of the player cube going through a basic level layout. Nothing has physics/collision detection yet, but everything exists and functions properly in physical space. Let me know what you think! :D
Level Generator Demo 2 + Character Movement
That's really awesome David. You churned that out damn fast. So with these two dictionaries are you going to treat one as a pool that you can add used blocks to and pull new ones from? I'm just wondering how to plan to recycle their states.
ReplyDeleteThe dictionaries are used for buffering the upcoming script values, not management of cubes-
ReplyDeleteAs of now what I do is delete blocks as they pass a certain point and once you've moved a set percentage through the current "section" it parses another script and pumps the layout into existence. All cubes are managed by the same list.
Here's the logic behind the execution:
Level Generator Update
{
if the current amount of cubes is less than half of the initial amount-
*parse script (into appropriate list)
*initialize plane
*initialize obstacles
}
I don't recycle cubes but destroy them. I'm not sure why my initial thought wasn't to use a data structure to hold dead cubes and active cubes. I think it was 3AM when I was designing it and kinda dropped the ball on cube recycling due to being half-awake. It works nicely as of now, definitely enough for a prototype- but I'll be sure to look into making it more efficient if necessary.
Also, I updated the original post with a link- it's a video of the class generating a level. I use the same test script 10 times and the reason it doesn't delete the sections at the end is because it's the end of the level and there will be a separate end-level state that is triggered.
Let me know what you guys think! :D