So Casablocka: A Gentleman's Tale is coming along nicely. I previously posted prototypes of the level generation/manager class handling basic assets fairly well and working with a few kinks here and there. This time I'd like to recap the implementation of the level design/practical scope concepts from our pitch as well as update you all on the progress of the game on the coding side. Let's just say I've been hard at work in the lab :D
Recap of Pitch
So when we pitched our game, we mentioned that we needed a game that was within the scope of reason (10 weeks!) as well as easy to execute in a well-polished manner. Seeing as blocks/cubes are our main asset, this already made everyone's life easier in terms of asset creation. The level generation system is based on text files, as mentioned/explained in my previous post, and can be popped in and out of the game in a matter of seconds. Our levels are essentially streams of blocks, either one or two (maybe three if we end up adding a jump feature) blocks high. The player is moving into this stream of blocks looking to dodge and maneuver around these obstacles. When the player collides into a block, they transfer control over to the block that they hit and slow in speed. Dodging obstacles and speed management are our two main mechanics thus far.
Time to Implement
So I already had a level generator that was performing at protoype-level, but there was no gameplay yet. Going into this next step in the project I was a bit intimidated, seeing as I haven't worked with data structures very much before this project (in CSC 393 right now! :P) as well as work on dynamic asset control. Luckily, unity makes both of these very easy to work with, and once I became a little more comfortable with the environment I was able to implement player control, dynamic control passing between colliding objects, a simple collision system, a basic cube recycling system (probably will need to optimize this later), and a much cleaner level generation method
So with my previous level generation system, the blocks would be moving towards the player on a conveyor belt-like system and the player's x-value would be fixed. This was all fine and well until the "player's speed" would change. I put player speed in quotes because technically it was the speed of the ground, not the player, that was being adjusted.
The problem was when the speed would change, the new cubes would sometimes be created with the old speed first and be too far from the other cubes or do the opposite and get the new speed too soon and start too close to the previous row. I also realized that all of the cubes on the screen were having their update methods called when I could do the inverse and instead only have the player's update method called.
tl;dr -> I now made the track's position fixed and the player/camera position dynamic.
The other changes previously mentioned are fairly self explanatory. Player's can only collide with other cubes from the front, not from the side- so if they're between two cubes they aren't able to move side-to-side. Cube recycling is now based on a queue where cubes are enqueued/dequeued when they are out of frame/needing to generate a new row.
Now, for the player control passing- this took some time for me to conceptualize. Luckily, Unity makes this very easy, because essentially you can place/remove code into an object's update method via behavior scripts whenever you want. This is both very handy, and very dangerous. Here's the code for the collision test/control transfer:
void OnTriggerEnter(Collider other){
this.gameObject.AddComponent("GameCube");
Destroy(this.gameObject.GetComponent("Player"));
LevelGenerator.cubes.Add(this.gameObject);
other.rigidbody.collider.isTrigger = false;
other.gameObject.AddComponent("Player");
LevelGenerator.player = other.gameObject;
Destroy(other.gameObject.GetComponent("GameCube"));
other.renderer.material.color = new Color(Random.Range(0.0f,1.0f),Random.Range(0.0f,1.0f), Random.Range(0.0f,1.0f));
LevelGenerator.cubes.Remove(other.gameObject);
Camera.mainCamera.transform.Translate(0, 0, (other.rigidbody.position.z - this.rigidbody.position.z), other.transform);
//Update Player Speed
if(LevelGenerator.tickMod < 17)
{
LevelGenerator.tickMod += 3;
distanceCounter = 0;
}
else
print("You Lose!"); //Will send player back to last checkpoint
}
What's happening here is the passing of behavior scripts from one object to another, as well as triggering a universal system recognition of this occurrence (i.e. LevelGenerator's player object being updated, as well as the camera position). The object material color change looks nice for now, but was my way of creating a visual cue for successful collision detection.
As the comments suggest, once I implement a checkpoint system- if the player collides with an object at minimal speed they will be sent back to checkpoint (or start if they don't have any checkpoints activated). Otherwise they slow down and have to gain momentum in order to get back to full speed.
///////////////////////////////////////////////////////////////////////
Well, that sure was a mouthful. I apologize if this was dull/tedious for you to read, I just get excited about coding. Oh, and I might as well post a new video of the game's progress too! Check it out below, feedback is appreciated!
-David
Game Prototype Update
No comments:
Post a Comment