Since my project is finally reaching the end goals, as I finish the final details I can get to the conclusion that, overall, I have met the Object Oriented Design targets that were set throughout the year.
Object Oriented Design was mainly used for the visual, artistic side of assets in the game, although also used for the more technical side, and overall code/blueprints/gameplay
Let's start with the level design:
I had a very vague yet decisive idea of what I wanted to do with the environment - late night, an office and an abandoned street. As the concept was indeed vague, I had to add more to the area and come up with more ideas. I had a huge part of the environment that was empty, which I came up with many solutions for - a bank, a large grocery shop, and finally a public park which is the one I thought was best. Other than that, there were a few changes I had to make which I will mention later.
 |
| Here is my first sketch of the level design. It represents the office area from a side view. |
At first, (and as I also mentioned in previous assessments) I planned on making a different type of game than the one I decided to make - a scripted, cut-scene heavily based game, with an even more detailed but smaller (hence only the office) environment. I later decided that I wasn't going to continue with this concept for my game, so I changed it up, although keeping the office area that I had already built part of.
Side and front views of the office in-game.
 |
| Base floor, Reception. |
If you compare this screenshot to the sketch, you can see that nothing really changed from the initial idea, if anything I just added a bar, a few tables and bathrooms.
 |
| 2nd (and 3rd) floor, Work-space floors. |
For these floors, I decided to remove the storage rooms that were presented in the sketch. This is because it interfered with the way I had already built the staircase, and it was just easier this way. I can still add whatever to the empty space if I have the time.
 |
| Staircase |
Due to technical problems, I had to adapt and move the staircase to a different position than showcased in the sketch so that it wouldn't mess up the whole building.
 |
| Here is the first sketch of how I wanted the street to look like. |
 |
| Here is how the street looks from the same exact angle. |
 |
| Same angle again, but unlit and without the fog for better comparison. |
As we can visualise, I stuck the the OOD plan throughout this part of the environment, only making very minimal, technical, but inevitable changes.
Below are some more screenshots showing the level:
Moving on to another sketch:
 |
| This is the other sketch of the street. You can spot a couple of differences here, such as the traffic lights and the To Be Decided building (which I was going to turn into a bank). |
 |
| Decreased fog so it's easier to compare |
 |
| Unlit and reduced fog for better comparison |
The obvious differences here are that I didn't build a bank, but instead a public park (which I will show later) as well as how the traffic lights look. I felt like the traffic lights I went with look great and fit the environment a lot better than the ones in the sketch. As to the park, I felt that the game didn't need another building but instead another open, large area, since it's a shooting, round based game that involves a lot of moving around - meaning closed spaces with props and obstacles just are not ideal. This way I ended up giving a new look to the environment, a more natural look - not to mention I also learned how to use foliage in the process.
Below are some screenshots of the park:
 |
Now, the fact that I built a park after sketching multiple different things does go against the whole point of Object Oriented Design. It is more of an improvisation if anything. I remember cancelling the grocery store that I was building and decided to go ahead with the park in that same minute. Now, it wasn't a complete improvisation - I did plan as I built but I did think of building a park before, I just didn't sketch or document it.
What I learned from this is that even though it turned out fantastic (in my opinion) and it is okay to improvise and let the creativity take over, it is always better to plan things out, sketch everything and face the project with a very clear image of what you are going to do and how.
|
Now let's focus on the blueprints:
Let's start with this problematic blueprint:
 |
| Heal |
The blueprint Heal is supposed to be a pickup that spawns across the map in various spots. When you collide into it, it gives you a small amount of health if your player is injured, and afterwards it destroys itself, only to respawn sometime later at one of the spots.
The way it relates to OOD is that I planned since the very beginning of the year that I wanted to have heal pickups spread across the map.
Here is the blueprint setup of Heal as well as other setups which I will describe:
 |
| Simply put, if the player character collides with the Heal, it will update your current health with +25 and then destroy it self. |
After destroying itself, it calls two event dispatchers which I will mention later.
 |
| Prop Rotating and Floating |
You can also see here another set of nodes - every tick, the prop moves up and down and also rotates. Basically a looped animation so that it looks more alive. This works absolutely fine.
 |
| HealDestroyed Dispatcher |
One of the event dispatchers is HealDestroyed. So when Heal is destroyed it calls HealDestroyed over in the level blueprint, and it spawns another Heal within 40 seconds (doesn't show in the screenshot but it is 40 seconds) in a random target point where a Heal isn't already spawned - notice how it says 'Do Not Spawn' on the 'Collision Handling Override', meaning Heals won't spawn inside other Heals (if God wants it that way).
 |
| BloodDestroyer |
The other event dispatcher is BloodDestroyer. Basically, when Heal is destroyed it calls this event which tries to get rid of the blood-splatter effect on the screen by changing the alpha channel to 0 (making it invisible). This works in an unexpected way - instead of clearing the screen as soon as you collide with Heal, it only clears the screen when you get hit by an enemy AFTER you collide with Heal. Don't know how to fix it, tried multiple times.
Overall, the blueprint does its job, but it can be very buggy sometimes, like I mentioned the blood-splatter bug, not to mention that sometimes it doesn't respawn at all or it respawns inside another Heal pickup. Sometimes it also freezes the health regeneration, other times it just does not heal you at all. It is complicated.
Next I am going to talk about my AICharacter blueprint as well as my EnemyPortal blueprint.
The AICharacter blueprint followed the initial OOD planning, and it behaves just like I planned it to (except for a few bugs which I will talk about):
AICharacter works fine on its own - if I spawn it manually, it will do what it is supposed to.
Although, when it is spawned through the EnemyPortal blueprint, it will not roam like it is supposed to, instead, it will stand still until the OnSeePawn event is triggered (only moves when it sees you). This shouldn't happen.
 |
| AI Moves to Random Location |
The problem isn't in the AICharacter's setup, since as I mentioned, works fine when I manually spawn it.
 |
| Enemy |
This is the EnemyPortal blueprint, you can only see 1 but there are 3 difficulties, and they each have their own assigned numbers in their own blueprints (number of enemies that spawn, how fast they spawn, for how long). At the end there is an event dispatcher that links with AICharacter, but it seems to do nothing at the moment. I do believe the solution is in an event dispatcher, and that I have to somehow trigger AiMovesToRandomLocation as soon as the enemies are spawned through the portal. This is what I will work on.
Another example is my Night Time blueprint in the level blueprint:
Very simple setup, the main light source in the sky rotates very slowly (pretty much stays frozen) and the time is set to night hours. The tone of the environment set in the world settings (dark blue) also helps with the night look.
This blueprint was set at the start of the year, when I planned on making my game at night time, so it obviously followed the OOD method quite easily.
Last but not least I will demonstrate some of the blueprints related to the player's health.
This is part of the OOD method since I planned on making a shooter, arena type game, with the purpose of the clowns being to kill you.
 |
| Player Dead |
Very simple blueprint, if player's health is less than or equal to 0 then a message will appear on the screen and the game will end.
This is obviously necessary, since the whole point of the game is to stay alive as long as possible.
 |
| Health System |
This is the health system, more specifically health regeneration. If your player's current health is less than the max health (100), then it will regenerate every second until you're full health. This also links to a widget which displays a health bar on your screen,
It is a pretty useful blueprint since it gives you crucial info to succeed in the game.
 |
| Core |
This is what actually allows the health bar to appear in the viewport as well as what activates the delta seconds for the health regeneration/checks if the player should be dead.
Overall in terms of Object Oriented Design and blueprinting, I have created most of what I wanted to do, and what I have created is at least at acceptable standards. I will add more stuff though, especially blueprints that I had planned before.
Object Oriented Design in Unreal Engine vs GameMaker
As we know, GameMaker has its limitations, and can't even be compared to Unreal in terms of potential or/and power. I will try to keep this in mind and take every critic with a grain of salt.
Below are some screen-shots with OOD from GameMaker.
 |
| Portals |
Before making BrainBox (my GameMaker game) I completed Portal 2 and I loved that game. I thought the idea of the portals could work out in my game. From there I planned it and created them.
 |
| DarkEco/Point System |
One of my favourite games of all time has these purple orbs that float around and feed you power, and I thought making purple shards would be a good idea.
 |
| Enemies |
Didn't really use OOD for the spiders, just improvised.
Blueprinting/Coding OOD Comparison
In Unreal, I have been using the blueprint system. It is a simpler way of coding, but without typing a single line of coding. While this does sound awesome, well, it pretty much is - although, it does have its limitations. Since I've been working on a specific version of Unreal, watching tutorials may confuse you more than actually help you - this is because as the engine gets updated, they tend to make changes to blueprinting, so what you're watching on YouTube might not be useful to you anymore, because you are working on a newer version.
However, this is pretty much the only downside of blueprinting that I personally came across. There are many pros to it such as: It's easier to learn, understand and read the whole thing. Obvious one, at the start of the course I didn't know a single thing about blueprinting, let alone coding. Few months later I can come up with my own blueprints, troubleshoot them, improve them, find ways around them, etc. Which leads us to another pro - It is easier to troubleshoot blueprints. The nodes and the wires make it extremely easy to see what's wrong with your functions and to modify them too.
I remember having nightmares with the coding while working with GameMaker. From not fully understanding what I was doing, to staring at lines of code, to trying different ways and failing. It wasn't a good time, I'll tell you that much.
Overall, compared to C++ and GML, Blueprinting doesn't even feel like coding, and that's a really good thing.
Level Design OOD Comparison
I'll put it like this: Unreal feels harder to master but way more rewarding, while GameMaker feels much easier and not as rewarding. I'm looking at the tools and possibilities here, not power of the engines - Unreal gives you a lot more tools, such as free default grey references and props, default animated characters, default environments and project setups, default textures and particles, better working tools (scale, move, etc), dynamic cameras.
May sound like GameMaker couldn't have these things but it could.
GameMaker feels more straight forward. I remember learning it quickly as I picked it up.
No comments:
Post a Comment