When we add these projected flows together we can clearly see where the hotspots will occur and where more calm areas are more likely to occur.
This flow projection map will help determine the probability of finding a player in different areas of the map. This will help when making design decision such as;
This is where we enter the world of the all mighty grid. I already knew that I wanted to make the level for UDK, since the renderer suits sci-fi environments more than Unitys does. But most importantly, it has already a working death match game mode.
Maya is my main modeling tool and a program I am very well used to work with. This is where most of my level design and level building will take place. But for this to happen we must first set up Mayas' grid system to match that of UDK.
(2048*2048) with 2048 grid lines divided by 64 is the largest UDK matching grid you can set up in Maya.
After this I saved the top down level as an alpha .tga file with the walls left out.
In Maya the alpha was used as a heightmap on a highly subdevided plane. Afterwards I reduced unnecessary polygons with the tool reduce.
And "woalla" , I have a 3D projection of my level.
I wasn't sure about the height of the walls or even the size of the level itself. There was only one way to find out. Export the "level" into UDK to try it out.
I scaled the "level" in y-axis and then x/z-axis together. This went on back and forth between Maya and UDK until the size of the level and the height of the walls "felt" good.
Ever since I played Doom 3, I've been fascinated by the rich interior design and wondered how it all got made. After some research It became clear that they used megatextures (a developed form of clipmapping) which made it easy for artists and level designers alike to make amazing environments, highly optimized with little effort.
My goal is to make almost the entire interior out of a single 4096x4096 texture map. with as close as possible to texel perfection! To achieve this a proper pipeline has to be planned and established before starting to model and especially texture.
First I played Doom3 again, made some notice on how much and how they reused their textures. I also made fair notice on how much texture stretching is acceptable without things starts to fall apart.
In Maya (with my UDK grid in place) I created a plane, scaled it to 768*768 and subdivided it into 144 polygons. After which I separated them into individual pieces and centered each individual pivot.
This was made so that each individual piece could be scaled down xyz-0.9 so that they could be UV-mapped with spacing between each and every tile.
This will ensure that no texture bleeding will occur when the engine starts to mip-map the texture.
Every polygonal square equals 0.9*(341*341) = roughly 307 pixels / square at 4096*4096 pixels.
Now my plane is UV-mapped and every square equals 2x2 on Mayas grid. And since it fits on Mayas grid it will fit just as perfectly on UDKs grid!
Now it's time to model some cool sci-fi panels that can we used to build the interior of the level.
And this is where I am right now. Building the level in Maya. I will try to make the modular assets roughly the same polygonal size. This will ensure a very smooth lightbake later on in UDK.
When satisfied with a piece I combine/merge it without worrying if the pieces will fit or not, they are after all made after the same grid size.
The texture also has lots of space left for adding new cool things such as doors, windows and maybe even props.
Thank you for reading, and hope you enjoyed it.
The possibilities are endless!
This was a side project that I worked on during the little spare time that you get when you study at TGA. The main goal with the project was to make a short single-player adventure in UDK where I could exercise as much tech as possible.
The overall level-design is currently in planning phase (and still is, who has time nowdays), but I am starting to see how the map could be played out. But as usual I will change a million things when I get down to actually building the level and gametesting it.
As much as possible of the interior of the base are supposed to be built with one 4096px map (I have baked 2048px atm), with as little special casing as possible. I got the inspiration from how they built Doom3 and how Tor Frick built his sci-fi scene.
When I created the highpoly wall pieces I got very inspired from how they made the Doom3 and Quake4 wall panels. I got a ton of information from this neat project doom3-hr where they imported the original normal-maps from Doom3 and used the maps as a base to make high-resolution copies. By studying those remade hr-normal-map I could see what details that would later translate into good diffuse/normals and what details that wouldn’t.
I am using a tweaked version of my water-shader on a geo-sphere to simulate the shield. Something I will look into is if I can get hit detection on the sphere through either scripting and/or shadernodes so that I can expand a hightmap from where I hit and outwards along the surface(a ripple effect); that would be so cool! This is something that I’m really looking forward to dig into, and I have a few ideas on how to achieve such an effect!
The terrain is a placeholder my first “Mudbox -> WorldMachine ->Photoshop -> UDK” heightmap. I am using it to learn how build landscapes from heightmaps and to set up a landscape-material. The splatmaps where first made in WorldMachine and then tweaked in Photoshop before I used them in my landscape-material.
This is a documentation regarding a small mobil-game level design assignment. The assignment was to create a tutorial level and a more challangeing level for a "Boom Beach" style game where the player is in control of a small squad. The played start at the deployment zone and the objective is to destroy a special building.
Part of this assignment is to make proper level-design documentation and simple explenations regarding your own thoughts as simple as possible.
There are three types of units. The enemy units are the same as the player's but they can be patrolling or idle. No attack speed was given so I assume that they all have the same rate of fire. I gave them all medium.
There are three types of environmental hazards for the player to encounter. No amount of health was given so I assume all towers have the same amount of hitpoints. I gave them twice the amount of a tank-units health, namely 2xHigh.
The rest of the environment is populated by natural occurring objects like rocks and trees and human-made obstacles like empty buildings. The player cannot barricade the empty buildings to his/hers advantage.
Swipe to move the camera. Makes room for bigger levels than the player can see with one overview. No zoom feature so what you see is what you get.
Tap to assign waypoints or to attack targets with all your deployed units. This means that you move your entire squad at the same time. Which means that it is not possible to make strategic decisions based on units individual rock/paper/scissor properties.
Cast an area-of-effect attack that temporarily stuns enemy units and defensive buildings. This means that even if the player for some reason cannot follow the rock/paper/scissor principle he/she still might have a chance with stun plus high burst damage.
3 minute play sessions. As with most, if not all mobile games, the play sessions should be roughly 3 minutes (approximately the same time it takes an average person to go to the bathroom or a short inner-city bus/tram ride).
Clear goals, even if they're tricky. Even if you make a game for "the average mobile gamer", you still have a lot to work with to ensure a fun gaming experience. For instance; instead of having one long challenging level (9 minutes), you can break it up into three smaller (3 minutes) levels.
Isometric perspective Iso-perspective isn't realistic but you'll still buy it if it's wrapped in a cartoony form. It also has great game view vs. playing field ratio. Which is crucial if you're unable to rotate or zoom the camera.
Now that the rules of the game are laid out, it's time to step forward to phase two, pre-production.
It seems all units, the players and the enemies are following the basic rock/paper/scissor principle. It's also stated that they are exactly the same units so I presume they also have the same amount of health and do the same amount of damage. We also have the units rate of fire and their damage on a low, mid, high scale which is really great since now we can calculate the units effective damage per seconds, and use it when we design our levels.
The term effective damage per second (short eDPS) is a term used in RPG games where the players overall effectiveness is determined through his offensive stats and abilities and his defensive stats and abilities.
Making levels with even these few variables is tricky, so the more you can simplify it at this stage the better. In the end it all boils down to play testing and iterations anyway. That's why I find it easier to define units theoretical eDPS when making levels fo rpg/rts/tbs style games. It makes it easier to predict game play outcomes and designing key elements of a level e.g. size, range and where to place obstacles.
Since I don't have any determined attackspeeds, damages or healthpoints, everything from this point is fabricated, but is based on what is stated in the assignment, namely high, medium and low.
With our fabricated numbers we can apply it to a very simplified eDPS formula.
eDPS only determines the overall effectiveness of a unit, and as you can see ranged units almost always out-perform close combat units because they have the advantage of being just ranged.
That is why competitive games based on rock/paper/scissor principles usually give close combat units large health-pools, high burst damage but low sustain and ranged units high sustain, low burst and small health-pools.
So that at the end of the day the outcome of a fight is mostly based on player skill and not the unit of choice.
With my partly fabricated eDPS chart I can roughly determine the amount of enemies for the player to encounter on any level, may it be a tutorial level for an inexperienced player or a more hardcore endgame level for the experienced players.
The assignments stated that two levels where to be made. One tutorial level and one for the more experienced users.
On the tutorial level, the player has 5 basic units, 2 tank units and 3 ranged units at his/hers disposal, making up a total player eDPS of 1775.
On the harder level, the player has twice the amount of units in the same order which totals a player eDPS of 3550.
I think it's good if the player has a lot more eDPS than the enemy on a tutorial level, but equal or close to equal on a more hardcore level.
The closer to equal eDPS, the less errors can be made before the player most likely will fail the objective.
Now I have 2 numbers to work with when I design my two levels.
I have to assume that you are unable to zoom in and out since nothing has been stated about that in the assignment. This makes the camera view/zoom in correlation with the level size much more important.
I also guess that iOS would be the main platform to aim for, mostly because iPhone users are more prone to pay for their apps than Android users. I would also guess that iPhone 5 would be the most targeted device since iPhone 6 just hit the market.
A good camera view for this type of game is the one that is used in Robocalypse Lite (Vogster Entertainment). The game is made with Iso-perspective and is zoomed in enough so you can see the details of the units and the surrounding areas without obscuring the overall view.
I chose to do my paper planning in Maya. Simply because I find it much easier to plan distances in correlation to camera angle and the range of the units.
First off I made 6 units in Maya that showed me the differences in their attack range. After which I prepared Maya to work as my level-planner.
There where many things that came to mind when I went through this assignment. Since it was so vaguely written there where many things that I just had to assume. Like zoom feature, which made it important to determine the range of the units to determine the overall size of the level.
Moving all you units with your waypoints makes sense when it comes down to mobile games. You want to make it easy for the player and it is hard and tedious to micro manage troops on a mobile device.
BUT, if you as a player are unable to micro manage your units, you need to implement very sophisticated path finding algorithms that basically do some of the micro managing for you.
For instance, you don't want your squishy ranged units in the front line, you want them behind your cannon fodder when you move forward
This type of algorithms where implemented into Supreme Commander 2 and is called flowfield and is extremely complicated and very cpu intensive.
Designing fun and interactive levels more or less requires trigger systems. In this assignment there could have been a lot more trigger. For instance, fetching a bomb to blow up an obstacle, or sabotaging a bridge to stop an enemy swarm of troops.
Cover nodes can be implemented into a mobile RTS game like this one without making the game more complicated. Just interact with a node on the map and the units will move there and automatically take cover. They might even fire automatically when in cover to make the whole process easier for the player.
You can also combine triggers with cover-nodes, like interacting with a tree which makes your troops fire at it. It falls over and creates a cover node for your troops. All of this interactivity adds to the game play and makes the player stronger. It'll make it possible to increase the amount of enemies to kill without making the level impossible to finish.
It would be fun to barricade buildings, and fairly simple to achieve. It would make the environment so much more interactive and fun to play around with, than just static buildings.
This was a great assignment and also a good exercise to touch up my level design skills. It made me really sit down and think before I got going. I'm happy with how the levels turned out, and it would have been fun to try them out.
When we made our spaceshooter on TGA which was our first 3D-project we ran into a lot of problems. Not only where the programmers required to build a 3D-engine during a very limited time-period but everyone had to adapt to working with in-house tools and broken code. This made it especially hard for us level-designers to script and make levels when the entire trigger system was broken until the very end. When our game was done my level still had a lot of trigger system bugs that made it unstable to play. I was required to fix those bugs but I really, really didn't want to work with the unfinished an buggy engine that we had. So I it fell down to make my level in Unity instead.
Making a close replica of our spaceshooter in Unity was a lot of work. I had to build input controllers, AI, projectile systems, meshes and make textures etc. Long story short, I had to make everything except the skybox and the gray static asteroids by myself. Fortunatley we used Maya as a level editor which gave me the ability to import the .mb file into unity to get a nice base to work with.
After that I took my newly remade and rewritten shoot'em up as a base and converted it into a spaceshooter.
The entire conversion process went smoother than anticipated. I again ran into problems with collisions and reusing missiles. It seemed the missiles' rotation where affected by the collision when they hit objects and that needed to be solved. The problem was that I couldn't deactivate the missile fast enough. This had to do with physics being calculated before the update and is called at the same time as FixedUpdate.
So I solved it with a " rigidbody.constraints = RigidbodyConstraints.FreezeAll". There was also some problems with aligning the crosshairs correctly to hit with bullets. I never really nailed it, so the crosshair is slightly off. But if I had the time I would have ray-traced to the enemy I was aiming at and then recalibrate the bullets angles so that I would hit exactly where I was aiming. This aiming problem occurred because I wanted a 3rd person view of my ship (it's just way cooler that way than sitting inside a cockpit), but it left me with a strain of problems... But you live and learn.
After the player has gotten the mission briefing, the objective arrow will lead him/her into the asteroid field, aiming for the huge hyper-ring in the middle.
Very soon the player will collide with a huge trigger box that surrounds the field.
This will spawn a number of enemies behind nearby asteroids (out of the players direct sight), and give the player some opportunity to get familiar with the firing mechanism of the game.
The players main goal at this point is still to reach the hyper-ring. So after the enemies has been taken care of, the player will venture towards the ring and hit another trigger.
The player now needs to collect 4 silicon tetrahydride (SiH4) crystals to refuel the ring. 4 Crystals are now spawned out of sight from the player. New objective is added.
Each crystals collected spawns a wave of enemies that the player has to take care of.
Once the player has collected all 4 crystals a new objective is added so the player understands that he/she is supposed to head back to the hyper-ring.
When the player reach the ring, he quickly gains knowledge about a 30 second charge-up timer. But that's not all, he/she not only activated the large main ring, but also the 5 smaller rings spread out in the asteroid field. These rings however works as enemy spawners, forcing the player to fight for his survival for the remainder of the time. New objective is added.
After 30 second the ring is charged and it's time to warp away from this deathtrap! New objective is added.
Level complete, new level is loading...
This was a little project of my own to refresh my memories on physically based lighting, hard-surface modeling and material definition texturing. I used Kostas Gialitakis CGFX shader for the physically based rendering inside of Maya's viewport. I was fun to sit down and just fiddle around with textures until you felt satisfied.
Approximately time spend; 1 day on modeling, 1 days on texture and bake.
Making this game was a true challenge not only because I had to learn most of the code from scratch. It also helped me be more causes in writing code and building systems since I shot myself in the foot many times during the process and I learned so much from it.
The last mandatory genre-based game on TGA is a first person shooter. The main goal of the project is to put everyones' skills to the test. Some of the demands where, SSAO, PBL (physical based lightning), "smart" AI (pathnodes etc), fun and well thought-through levels (scripted events) and proper design, game and level planning.
I was designing the first level for our fps and I went completly over the top, not thinking that our engine wasn't as optimsed as conventional engines (ofc not, what was I thinking), and where some of the art, sound, animations etc slowed down the overall performance.
This resulted in a performance fix entering very late during the project. The performance fix was culling rooms with door portals. This resulted in my entire design and my level couldn't be played the way I designed it. I couldn't use open spaces or houses with many floors, since I now had to take into consideration culling rooms during my design process. It's just one of those things you learn when you develope your engine at the same time as you develope and design levels.
At the end of the project we as a group struggled to tie everything together and we decided to scrap my level, since there wasn't enough time to fix it.
Later, when our engine was way more stable I sat down and made a level that I designed specifically for our pixel-engine. Now I knew exactly how it worked and it was a relief to know that nothing major would be implemented or changed later down the path. Just design, build, play test and iterate until satisfied.
The YouTube-clip above show the level I sat down and made, taking into consideration culling rooms path finding systems and overall engine performance. The Images under shows the old level (the one that was cut), and as you can see it is way more complicated with open spaces and a much less linear level-design.
During our advanced production we level-designers where supposed to make either a single-player adventure or a multiplayer map in UDK based on a location in Malmö city, Sweden. We were also supposed to make all the graphics by ourselves. I chose to make Malmö Central Station into a ctf map with full bot support.
First up I gather a ton of information about the station in forms of images and blueprints, and then I did some rough paperplanning. During this entire process I followed a book called Preproduction Blueprint which was a very good book to read and gave me a lot of good pointers, especially since I read it in combination to this project.
After that I made a blockup in Maya based on the blueprints that I had. Then it was just a matter of making everything in Maya and export large chunks with advanced collisions attached. The collisions are the Deep red pieced that you can see on the workflow images below. When I was done in Maya it was just a matter of importing everything into UDK and building it into a playable level. It took some time to make the bot-supoort work well, and it was a pain to make the AI actually capture the flag and return it to the home base. When the bot-support was working it was a matter of tweaking to get a decent playflow.
During playtesting it was apparent that I needed a side patch from blue to red base. I also wanted to test how to import animations into UDK so I animated the turret in Maya and scripted the event in Kismet where I also synced both sound and particles to the animation. Via kismet I also triggered the drop down of the animated ship that’s flying around outside. You can either activate the event by pushing two buttons, one in each base and use the main lever in the middle or wait 5 minutes for it to activate itself. The main idea of opening up a new path with an event was to make the level more fun and dynamic.
All normal-maps are made with Ndo1, since I didn’t have time to make high-polys for an entire scene and make it into a playable level in the short period of time that we had for the assignment.
I got a ton of shading errors when I mirrored the meshes in Maya, which is really showing throughout the level. There are also some minor kismet errors when the ship crashes through the wall. I hope to correct these errors in the future since the quite obvious and annoying.
I'm pretty happey with the resaults, considering we only had 1.5 weeks from start to finnish during this assignment.
The real time strategy project bumped up the level of both tech and difficulty for everyone since it was required to have a thinking AI that would pathfind with the help of a navMesh and do the smartest move to counter the players actions.
During the planning phase we as a group decided the main story and what the game would be all about. I was decided that our game would consist of one map and that we should use World In Conflict as a good reference for an RTS. This included scripted events and that the game should be a more of a single-player-campaign driven game rather than a skirmish game where you face a clever AI. We level-designers did a lot of paperplanning for our missions and some RTS gaming to get a better understanding of what we were supposed to do.
When we felt that we had enough to work with, each one of us level-designer made an entire mission from start to finish. After that we sat down together and talked about our ideas and gave each other vital input. During the next iteration of this process we mashed together a unified mission composed of the best parts of our different ideas. It is important to work close to the entire team at this phase to ensure that the map and mission design don’t stray too far away from the main idea.
After this we sent our ideas to the artists who then made a rough map in Mudbox. The map we got back was a roughly 200k map UV-mapped with a 4k texture and ready to be used as a base for blocking in Maya.
After blocking up my part of map with props from the artist in our in-house editor we were ready for some little testing. But this road was hard since a lot of the functionality for AI, navMesh etc. where were still in progress, which delayed our work.
The game had bug where the AI didn't have a spawn cooldown. This combined with several other tweaking errors made it impossible to beat the AI unless you pinned him down early in the game. So I wanted to make the AI and the overall gameplay feel a little more polished and not as broken as it was. These where the changes I made.
The first 3D project we made at TGA in second grade was a space shooter. The game was made over 8 weeks half time in a inhouse-engine that the programmers wrote from scratch at the same time! So level-designers and 3D artist had to work with what we got.
Our goal was to make a basic space shooter, with some fairly easy scripted events thrown at the player. This was also the first project that we were supposed to work without leads and only focus on scrum with task-forces.
I was in the taskforce that decided the main setting and story of the game. When we had mission and story design planned out on paper, we invited the rest of the group to do some feedback. When that was done us lds took one level each.
I was in charge of designing the first level which was supposed to have a tutorial part at the beginning of the level. So it was important to keep the overall difficulty of this level low.
We used Maya as our level editor, with custom scripts for saving object orientations to xml files. The majority of the lua scripting was made by another level-designer and I was in charge of implementing it into the level and hocking it up to triggers via xml.
When that was done I sat down to integrate the tutorial part of the level with a more interesting mission design. I wanted the player to experience a huge asteroid field. So I took a lot of the asteroids provided by the artists and placed hundreds of them in center of the Maya scene. Then I randomly rotated every one of them and finished the build with object translate the asteroids in x-axis. That made the asteroids explode into a giant sphere, an asteroid field was created!
I sat at the middle and the end of the project I worked a lot on weapon tweaking, and a little with sound effect making. I also had the time to make a giant hyperring that would work as a start/end hero prop for the game.
Sizes of objects is hard to grasp if you don’t have anything to refer to, especially an abstract object such as a sci-fi hyperring. To achieve the illusion of size, I UV-mapped the hyperring in such a way that it got very high texture resolution at the cost of high polygon count. Both the turbine engine and the hyperring shared the same 2048px map.
The neat thing with this project is that this was the first we ever did that was done with pure 3D. Even if I (of course) prefer to work with a finished engine I still think it was an unbelievable feat to make this game and build the base engine at the same time!
Even though we hit some snags down the road we managed to tie all the strings together and deliver a game!
The last project during the first year at TGA was to create a turn based strategy game. Together with the group we decided to make a game based on the popular jagged alliance game were you have command a little squad with different features. The core dynamics of the game are to solve different situations by combining the strengths of the different characters in your team.
We later divided the group into small task-forces that would take care of things e.g. story, game-design and features. When the main setting, story and features were decided I started to paperplan the first part of the game, level one. I did a top down sketch in Photoshop that I later put into Mudbox to be able to sculpt the base terrain. When I was finished with that (normal and AO bakes) I handed it over to the artists who later did the final touches.
When we at the middle of the project waited for core game-play elements from the programmers I took the initiative to make some FX. I sat down and chatted with the artists about what kind of fxs we needed and then started to work. I sat up animation/render scenes in Maya and did all the aura effects for out characters.
Somewhat after three quarters into the project we were at the point where we needed a menu, so I slapped together a little animated duststorm in Maya, just to bring a little more “woaw” into first impressions.
At the end of the project I helped the rest of the team with things that needed to be done such as placing object in the world, tweaking enemies and game-play values (hp, ap, dmg – etc).
We did what we could with what we had and can therefore say that I am happy with what we achieved.
The shoot em up project is the third project in the line of eight at TGA. It was a project that would turn out to be one of the toughest projects to pull through. But in the end, as always, we managed to cross the finish line!
My responsibilities during this project were the same as always, to ensure a good gameplay and to design levels based upon features that where feasible for the programmers to accomplish.
We began by setting the theme of the game and it was decided that we should make a sidescroller where the main mission was to kill a big flying whale. Sounds a lot like a shoot em up version of mobi dick which was exactly what we were aiming for.
Since I was already experienced in Mayas particle system and was fairly experienced with animations etc, I took on the tasks of fx making. This involved setting up render-scenes in Maya where I could animate and render projectiles with a ton of effects. We also needed explosions, so I sat down trying to figure out how Maya’s fluid system works (which were a lot harder than initially thought).
We built our levels in a very rough level editor that was composed of us making an MsExel-file for each z-layer, where every cell represented an in-game block. My idea to use MsExel to edit the open and edit the .xml files helped a lot to speed up the process! This was tedious work, but it was still a thousand times better than pure xml.
I was in charge of the entire bossfight, how it would play out and decided together with one of our programmers how bullet-pattern creation should work. When the five stages of the boss were done it was down to game-testing and tweaking.
I was also together with my fellow lds in charge of weapon tweaking such as bullet spread and damage. This project really showed me how important it is to never ask for features that are too hard to implement. The more difficult the project is, the more important it is to work tight as a team!
But, when I play the fixed version of this game today, I can still see how much work that was put into it and I can’t help but smiling from the heart!
The second game-project that I did at TheGameAssembly was a point and click adventure. It was mad in a group of me as a single level-designer, four artists and three programmers.
I took charge as lead and with everyone’s vision we decided to make a game that was cute, gory and fun. We ended up with an adventure starring a little girl that was sucked into the world of the television. Inside this realm you as the player had to solve several puzzles throughout two levels to figure out why you have entered the realm to begin with and who was responsible for it.
When we had the setting I sat down to make the level-design. I did first on paper, and then I made a level-design overview in photoshop so that everyone knew how the levels would play out. Having done this paper/image planning at the start was very important since we early in the project could see what kind of features and amount of art that was needed.
During the project I made a decision that most of the things that was floating around in the world should be animated to bring life to the world. To ensure animation consistency I sat up a Maya scene with a fixed camera and predefined render-settings, so that everyone could animate the things that they made for the game. I made some 1300 images for the project were most of them were sprites for the spritesheets. Making spritesheets and going from planning to game was a great ordeal since it’s a 2D game. We had to think of z-levels, and how and in what order things where supposed to be rendered. I had on top of this think out pipelines that would speed up the process of production, like specific imagesizes (power of two) and distance from object to.
While this was set up we met the problem with texture-consistency. Other groups started UV mapping and textureing stuff, while I saw the opportunity to build a shader applied to a special colormap. This ensured us that everything in the game would be rendered with the same result and would hopefully eliminate inconsistency between the artists.
I took a lot of responsibility making the art connected to the puzzles that I sat up. This really kick started my 3D knowledge. I also found it fairly easy to make particle effects for the game, so all the effects was made by me.
I learned a lot from this project. How it is to fight as an underdog. To boost and brace people and to make sure the project was finished and delivered on time. For many, if not all of us, this project was synonym with struggle and crunch. Even tough we as a group made a ton of errors we managed to pull through and deliver, and that makes me proud!
This was the first school project that we made at TheGameAssembly and it’s still something I’m proud of. It was made over the course of 8 weeks (half time) by a team of 2 level designers, 3 artists and 3 programmers.
It was an introduction to the complexity of the creation of games and how important it is to be able to work well as a team to meet deadlines and to have a realistic scope.
During this period we had to write user stories for everything about the game, and a lot of time went to write user stories for the puzzles and scenarios that I was responsible for. Example of one of my userstories(Swedish atm).
I quickly became well aware of the difficulties to explain ideas for artists and programmers so that they both understood how scenarios were meant to play out, both graphically and code wise. User stories only takes you this far and I felt the need to find a new medium of explanations.
This new medium was 3d! But I didn’t know Maya (and wasn’t experienced enough in any other 3d application), so I downloaded Google SketchUp and started to learn and understand the program. This made me able to visualize my ideas in 3d and to show the artists what I meant and simplify the communication process in the group.
So all my puzzles and “rooms/scenarios” where made in SketchUp, which I sent to the artists in the form of a print screen which worked as a good perspective and asset base for their paintovers!
One of the puzzle that I made that I am particularly proud of is the laser-puzzle. The main idea was to get from point A to point B and turn on the laser communication node. But the player had to navigate through a server hall that was composed of 4 by 4 rooms. And the only way to get from one room to the next was to enter the parallel universe were you could navigate freely in all directions.
For every new room you entered in the parallel universe we presented the “current room” for the player by randomizing a number between 1 and 999 and randomizing an image of the parallel universe rooms. The reason for this was to confuse the player, and giving him the feeling of being lost. But when he reentered the normal world again he could see that he had progressed through the puzzle by looking at the map visualized on the wall.
Once the player had gotten to the laser node and activated it, it was just a matter of aligning the node through the different rooms. This was fairly easy, but some of the rooms had broken nodes to prevent it from being a too easy puzzle to solve.
The puzzle was very complex for being in a text adventure and I am proud of what me and another programmer achieved!
If you would pitch the game to a friend it would probably sound something like this; “Combine cabin in the woods with a sick Nazi doctor. Slap on some metaphysics, valve’s portal and parallel universes. Now take all that and imagine it to be an interactive comic book!”
The game was full of leftoversbugs from bad game testing and a to grand of a scope, but if you take it for what it is, I think it turned out quite well.
This was a project that I did back in 2011 in the TitanQuest editor. I was completely new to game-engines, 3D-art, normal maps etc, but I had one goal: to maximize my chances to enter my dream education.
It started out as an item map where you were supposed to pick up items and fight a dummy to measure your dps. But I just got so hooked on level-design and level-propping that I couldn’t stop expanding the level. The more I learned about the engine and how to do custom quests, scripts, make new items and new enemies, the more I just wanted to progress and build with everything that the game had to offer.
I got so lost in time that the average playthrough-time is approximately 1 hour!
I learned so much doing this in my own pace since I had the time to redo things over and over until I got it right!
I have to admit that I didn’t really know what I was doing with the level-design, but since I’ve always been a hardcore gamer and an addict to blizzards Diablo universe it came kind of natural to produce decent missions and experiences throughout the level.
I even re-tweaked all the enemies and weapons since I felt that everything died too quickly when the player was equipped with the best gear in the game.
Doing this map really laid the foundation for my love to game-development and I am to this day very proud of what I accomplished.
Copyright © 2018 to Date | Daniel Duh | All Rights Reserved.