I spent today polishing the game camera even further, accomplishing my goal of creating a smooth and convenient camera rotation system. See for yourself:
I accomplished this by generating a point (demonstrated above in pink) a fixed distance away from the camera. From there the game takes the X-axis of the mouse when holding down right click to move around that point. This method works much better than yesterday's implementation of rotation, which used simple key presses to swivel the camera in place.
After accomplishing this, I worked to integrate it seamlessly with the panning and zooming functions. The camera script has several methods running every single frame (multiple times a second), so allowing everything to work in tandem took a good amount of time. Some bugs remain, but I succeeded.
After put my finishing touches on the camera tomorrow, I'm going to move on. My next task will be implementing health bars that hover above enemies, as well as a status bar that opens when you select them, similar to the towers.
0 Comments
It's my second week working on this project, and It's not a decision I regret. I have been making a lot of progress with the time I have available, although I must reiterate that the next three weeks will not be enough time to make a fully fleshed out game.
I spent nearly the entire day today working to overhaul the camera movement system to suit my game. The goal was to have it function like an RTS (real time strategy) game camera. This entails an overhead camera, that allows you to pan, rotate, and zoom around the map. I made very good progress, but the system still needs some work.
Currently, the user can pan around the map using the WASD keys on the keyboard, or by putting the mouse near the borders of the screen. I also added the ability to use the scroll wheel on the mouse to zoom in and out. When the user gets closer to the ground, the angle flattens out. The further the user gets from the ground, the steeper the overhead angle of the camera is. This is a range between 10 and 80 degrees relative to the ground. Furthermore, I added camera location constraints, meaning the player can't zoom or pan too close or far away from the map. Finally, the user can rotate the camera left and right using the Q and E keys. I made a small video showing off my progress below.
The rotation controls are still in development. I would like camera rotation to be achieved by holding down and dragging the right mouse button. In addition, I want the camera to be able to "orbit" around a point when this happens, as opposed to simply turning the camera in place. This will require me to create a system to dynamically create fixed points to orbit around with smart use of raycasts, or straight lines drawn from one point to another that allow the programmer to gather information (these are also used to place the towers down, among other things). For reference, please peruse my professional drawing:
Achieving good results today has been a challenge, with hours spent frustratingly assembling and debugging code, followed by the sense of victory when I solved the bugs. Creating fluid camera controls require extensive use of three-dimensional vectors, transformations, euler angles, and quaternions; as well as solid knowledge of the included functions and libraries available in Unity. As such, I spent a good amount of time today browsing forums and watching youtube tutorials to find the best ways to accomplish this task.
Overall, today has been a very productive today. Tomorrow I will continue working on the camera system.
I accomplished a lot of good work on the wave generator today. The game now has full support for multiple enemy spawning locations and paths. Enemies can now be assigned a path to follow when they are created. By default, the path is inherited from the enemy spawner script that creates the enemies. I also wrote a wave manager script that synchronizes different enemy spawners together, so that one spawner doesn't get ahead of another of another and continue spawning waves without the other ones finishing first. This means that I can handcraft each spawner of each wave, including specific timings and enemies, with relative ease. The framework to create handcrafted, progressively more challenging levels now exists, putting me one more step towards baseline. The level I am currently testing the game in currently has 3 waves, with separate enemies on each path. When I get to fully designing a level and creating more enemies, the amount of waves will increase substantially. I also took the time today to further improve the graphics of the game, using Unity 5.6's Post Processing Stack. This gave me the means to fine tune many effects (pictured below), to improve the look and atmosphere of the game. The before and after screenshots speak for themselves: Some effects need to be tweaked, like the depth of field effect, but the initial improvement is substantial. The most important part of improving the graphical fidelity of the game has yet to come: replacing the placeholders with actual 3D models, and implementing particle effects to make the game more lively.
Work continues, stay tuned! Very little work on the game today. Enjoyed QSOL: A Qualcomm sponsored event that included live music, good food, a famous soccer player, and cake walks! Everyone invited were Qualcomm employees and interns, including Qualcomm Thinkabit interns from High Tech High International. After the event, we gave the Thinkabit interns a tour of our building.
We left a little bit early, so I started teaching my coworker and friend Mitchell the basics of C#. My experience with this externship is not only teaching me C#, it's teaching me how to design 3D graphics and terrain that work to benefit gameplay. The tasks I did today related very much to much of what I was doing at school during the VR worlds project when I made a VR escape room: level design. I didn't do any programming today (I spent a lot of time touring buildings, meeting people, and attending meetings!), but I finished the redesign for the desert map. This map features two mirrored parabolas that intersect each other in the middle. The enemies come from the opposite sides of the northern part of the map, and each go over a bridge and under another one. It also features an oasis, conjured quickly thanks to a prefab water texture and palm trees included with Unity. I also spent a lot of time laying down the path nodes that the enemies follow, and putting down invisible rectangular prisms that prevent the user from placing towers on the path of the enemy. I learned that having an elevated path complicates many things. For example, the mine layer will lay mines through the floor but will still detonate properly. Second, the mortar tower will go through objects if the target is placed below it. These are issues that I will get to eventually, but am prioritising getting a rough completion of the entire game before I fix minor issues. I experimented with having two different wave spawner locations. It showed off some specific features I need to create to work cohesively. First, I need a way for the enemies to differentiate what path to follow (they currently go down one, then awkwardly go down the other). Second, I need a script that syncs the waves together, so that one spawner doesn't start another wave until both are finished. Once I accomplish those two tasks, I will be able to hand design both waves like normal. Random, infinite wave generation is still a task I want to work on, because a mix of both makes the most polished and fun tower defense game.
Overall, the map looks and plays pretty well. I will continue working on polishing the wave generator tomorrow. I finally finished reassembling the legos that formed the foundation of my game. The structure for coding towers is now much cleaner and easier to work with, and every functionality that I broke in the process (just about everything) has now been fixed. This required a lot more work than I originally expected, and took much of last night and half of today to finish. I needed a mental break, so I switched gears. I spent the remainder of today overhauling the terrain graphics. I then started work on a new map. This one is 50% larger than the grass one, and features a long, curvy, desert road that eventually elevates to a bridge that crosses the map. It was sculpted using Unity's built in terrain editor. I also added prefabricated trees to add some life. I'm still refining the terrain, and tomorrow I'm going redesign the road to have multiple entrances and exits for an increased challenge. This will also require me to restructure and flesh out the wave spawner and the enemy AI. It's an essential requirement that I've been meaning to do for a long time, and I look forward to spending time developing that tomorrow as well.
My first impressions of Qualcomm: Building Q are all positive ones. The campus is beautiful, and the rows of computer laboratories, circuit fabricators and servers are a wonder to behold. I was given a relatively quiet workspace with all the resources I need to work on my project. The other members of the team are all easy going and fun to talk to, and have no issue explaining their role in the company. It's been awhile since I started on this project and actively worked on it. I learned as I moved along, meaning some implementations were done cleaner than others. I spent today re-familiarising myself with the code I wrote, as well as meeting Qualcomm employees and touring other buildings. Looking back, I saw some things that weren't implemented very well, and needed to be fixed to move forward with a strong foundation. When someone remodels a bathroom, they must tear it down. That's what I'm doing to the underlying code for the towers. Currently, the 3 fundamentally different tower types (mortar, minelayer, and normal) are all sloppily written and intertwined into the same class. The way it is written doesn't allow the expandability I need to ultimately have tens, if not over a hundred tower variants (lightning, nukes, rail guns, bow and arrows, sniper rifles, flamethrowers, the list goes on!) So I spent today attempting to refactor the tower class to allow the creation of derived classes that all share the common traits of towers- such as being able to place them and being able to see their stats- but still function in fundamentally different ways. This will result in much more organized development and will save me a lot time moving forward. It will also allow me to avoid the bloated, confusing, and redundant inspector (allowing the external modification of values within the script) I currently have to work with. However, I haven't finished yet. More things are currently broken than when I started today. Snippets of dependencies are all over my codebase. When I attempted to separate the code for the mortar tower from the rest of the tower code and instead make it inherit properties from the tower class, I broke the ability to place a target, and spawned an infinite number of seemingly entirely unrelated null reference exceptions. These are all side effects of the unfinished implementation, and is the nature of ongoing development. I will continue working on this tomorrow. All in all, I didn't achieve much in terms of concrete changes, but I have a defined goal and direction. If you're confused, let me try and help: To further explain my workflow, it is important to note that the game is not programmed in one giant code document. C# is what's called an object oriented language. This means that the code I write is separated into many different scripts called classes that serve different functions. Multiple instances of the same class can exist at once and can both run separately and contain separate values. This is very easy to visualise with Unity, because the classes quite literally run on tangible objects. For example, both the basic tower and the rocket tower run the exact same Tower class. The rocket tower simply has a different value for the property explosion radius than the basic tower (2, instead of 0). In addition, every tower placed by the user is running a separate instance of that same code. Both of these towers shoot bullets towards the enemy when the enemy comes into range of that specific tower. Each bullet is a separate instance of the bullet class, with different values for speed, damage, and explosion radius that aren't affected by any other bullets (unless I want them to). See where I'm going here?
The end goal is that these classes all work together and communicate with each (by passing values and functions) seamlessly and effectively. When that goal is achieved, the application can be expanded as much as the user wants. I can place and run three hundred mortar towers if I want to, only limited by my computer's processing power and how well my code is optimised. That is the general idea of C# and the Unity game engine. Moving on, I will be referring to this summary if a reader is confused about the general process of my workflow. Over the course of externship, I will be developing a tower defense video game. I already have the foundation of the (currently untitled) game in place. This was developed during my free time. A link to the game in its current state is provided here . In order to play it, download the folder and launch the executable file located within. It's buggy and incomplete, and serves mostly as a demo that will keep someone occupied for no more than 5 minutes. Here is a full list of what I have so far: Basic Enemies: I have two types of enemies. The tank and the elite tank. They both function exactly the same, with the elite tank having more health. Enemies move along a path and get shot at by the towers. When they die, they explode into several smaller fragments. Money and Lives: You can spend money to buy towers. You make money by destroying enemies. If an enemy reaches the end of the map without getting destroyed, you lose a life. If you lose all of them, it's game over. Stats and Upgrade Panel: Clicking on a tower gives you an overview of the tower. It also lets you sell the tower for your money back, or to upgrade the tower to something better (current implementation of upgrading is very basic). Basic Tower: Target enemies when they get close enough, and shoot bullets at them. Each bullet does a certain amount of damage to the enemy. Rocket Tower: Mostly identical to the basic tower, but has splash damage that hurts nearby enemies upon collision. Mortar Tower: Allows you to place a target anywhere on the map. The tower will constantly bombard that target. Mine Layer: Scatters landmines on the path. When an enemy hits the landmine, it detonates, damaging or destroying the enemy. Path Node Based Enemy Movement: Enemies travel along a predefined path, travelling between placed spheres called nodes. The enemy script searches for those nodes and travels between them sequentially. Drag and Drop Tower Placement: The towers are listed on the bottom left of the screen. Clicking and dragging from the tower you would like to place allows you to drop it anywhere on the map. Rudimentary Wave System: Enemies come in waves. Each wave currently needs to be hand crafted, thus endless waves aren't currently possible. This work has been achieved over several months of sporadic effort. I plan on using the next month to add more content and achieve a baseline (fun, playable, yet incomplete) state. To reiterate, I do not plan to, nor will I be able to, finish the game in its entirety over the course of externship. That isn't laziness, it's feasibility. It takes teams of developers years to create fully polished, feature complete, and fun video games. For reference, look at the ongoing development of other Unity games such as Rust and Kerbal Space Program. I am learning as I go, and will not have any other help. Notwithstanding, here is what I plan on working on throughout externship:
Much Better Camera Movement: The current camera implementation sucks. I would like to have the camera movement be smooth and accessible. This means proper panning, zooming, and orbiting. More Tower Types: Games like these thrive on variety. I plan on designing and adding new towers, such as laser guns, armor piercers, and more. Tower Upgrades: I would like each base tower type to have a branching upgrade path, raising the stats and changing the functionality. For example, an upgrade path for the mortar tower could branch between having more barrels (and thus shooting faster) or a larger one (for more splash damage). More Maps: The current map is a very simple windy road on a poorly textured grass plain. I plan on creating a variety of maps, with multiple paths that enemies can travel down. Sound: Currently, the game has no sound, or a system in place to allow sound. I plan on creating a sound system, and using placeholder sound assets to demonstrate that system. Main Menu: The game has no main menu. I need to add one. Replayability / Wave Overhaul: As part of the goal to achieve baseline, I need to expand the wave system. This also includes expanding the variety of enemy types to better scale the game difficulty. Tower Unlocking / Research: I would not like all the towers to be unlocked off the bat. I want a system in place to unlock them over time, such as researching them with a special tower type. New Models: Currently, every model is constructed out of cubes. I would like to learn Blender in order to create better models, while retaining the cartoony theme. Bug Fixing: Making sure all of these new systems work properly. And More: I might work on other features not listed here. Whether or not I wholeheartedly achieve all of these goals is still up in arms, but the items listed above will be the focus of my time during externship. I will be refining my goals and documenting my progress daily on the dev blogs. I will get specific into technical issues, and do my best to explain them to those who do not understand code. With all of that wrapped up, its time to get started! |
|