Student Project
Vertical Divider
|
Description
The player is a fleet commander who has to prepare their troops for imminent space combat. After the preparations the player will be taken to a projected version of space where they can control their ships in a VR space.
|
Information
Genre: VR, RTS Engine: Custom Team size: 17 Duration: May 2017 - July 2017 Role: Level Designer, Lead Designer Vertical Divider
|
Responsibilities
|
Challenges
Custom Tools Troubles
Like is stated above, this game was made using a custom engine that was being created at the same time the game was. Before this I had only worked with already "finished" game engines (Unity and Unreal) so it was quite a challenge to get used to a lesser refined engine.
For a significant amount of time there was no level editor and no real ways of creating anything resembling a level in the engine (the enemies were all spawned in using code which I was not allowed to touch). After a level editor was implemented it was quite rough. I have a great amount of respect for the programmers on our team for getting so much stuff to work in such short time but it was still really difficult to work with the engine.
It was very slow to place and move objects in the scene. It would also take a long time to edit objects already placed in the scene. Because of all of this (and other issues relating to not enough HTC VIVE's being available) it was nearly impossible to playtest any of the levels I had made. Most of the work I had made for the game is based on estimations (I had some basic data from the brief moments we could actually test the game).
RTS level design
This was the first RTS game I had ever worked on and it required quite a bit of different level design than I am used to (mostly first and third person). Because of this I mainly focused on researching level design for RTS games at the beginner of production. Focusing mainly on games that were similar to ours (Homeworld and weirdly enough a little bit of Totally Accurate Battle Simulator). What I found out quite early on was the fact that most of the research wasn't usable. Considering that our game wasn't really like other RTS games. Like I said before, it was quite similar to Totally Accurate Battle Simulator, with the player progressing through the game by defeating enemy waves that kept on increasing in difficulty and complexity.
Dealing with great loss of work
Near the very end of the project (like last day) there were some complications with made all of my level design more or less useless. We could not use asteroids or any kind of cover in the game space. Making the entire thing a giant empty arena. I was quite upset by this, since the entire project there was never any kind of indication that we could not use objects in the game space.
Like is stated above, this game was made using a custom engine that was being created at the same time the game was. Before this I had only worked with already "finished" game engines (Unity and Unreal) so it was quite a challenge to get used to a lesser refined engine.
For a significant amount of time there was no level editor and no real ways of creating anything resembling a level in the engine (the enemies were all spawned in using code which I was not allowed to touch). After a level editor was implemented it was quite rough. I have a great amount of respect for the programmers on our team for getting so much stuff to work in such short time but it was still really difficult to work with the engine.
It was very slow to place and move objects in the scene. It would also take a long time to edit objects already placed in the scene. Because of all of this (and other issues relating to not enough HTC VIVE's being available) it was nearly impossible to playtest any of the levels I had made. Most of the work I had made for the game is based on estimations (I had some basic data from the brief moments we could actually test the game).
RTS level design
This was the first RTS game I had ever worked on and it required quite a bit of different level design than I am used to (mostly first and third person). Because of this I mainly focused on researching level design for RTS games at the beginner of production. Focusing mainly on games that were similar to ours (Homeworld and weirdly enough a little bit of Totally Accurate Battle Simulator). What I found out quite early on was the fact that most of the research wasn't usable. Considering that our game wasn't really like other RTS games. Like I said before, it was quite similar to Totally Accurate Battle Simulator, with the player progressing through the game by defeating enemy waves that kept on increasing in difficulty and complexity.
Dealing with great loss of work
Near the very end of the project (like last day) there were some complications with made all of my level design more or less useless. We could not use asteroids or any kind of cover in the game space. Making the entire thing a giant empty arena. I was quite upset by this, since the entire project there was never any kind of indication that we could not use objects in the game space.
Level Design
During development I was responsible for creating the different scenarios our player would encounter. After researching similar games in the genre I created several guidelines for the missions:
- Coherent with the theme.
- Everything placed in the level needs to make sense in a vacuum environment.
- Coherent with the difficulty guidelines
- Every level should increase the difficulty in some way (either more enemies in a level or a new ship type introduced).
- Invite new gameplay
- Every level should allow the player to use a different tactic then they have done before.
- Innovate with the game space
- Every level should look different, wether this is due to new rock formations of just the general ambience.
- Consistent build up in available resources.
- Every level should have an increase in available resources compared to the previous level.
- New ship types introduced slowly
- Every time a new ship is introduced, the number of ships should be kept low.
- Asteroids should block artillery ships
- To allow players to first get used to the new level before they are shot at, the artillery ships should first be blocked.
- Carrier ship open space
- Especially important when the carrier is first introduced, there should be minimal blocking in front of the carrier.
- Especially important when the carrier is first introduced, there should be minimal blocking in front of the carrier.
The levels don't have to adhere to every rule on this list, for example if it could lead to new interesting gameplay moments some can be ignored. However, a level must adhere to atleast 5 out of the 8 rules.
|
Cones are medium ships, cubes are artillery ships and the golem is a carrier
Due to the fact that the asteroids were causing issues with the ship AI it was decided that they should be moved to outside the playable area. Which means that most of my designs were useless and I was tasked with creating the one level which would be used in the demo
|