Goals

Hi,

Here are my goals for the course Game Design in Practice as part of the assignment:

1. I want to release a game to the public.
2. Learn more about the work flow when working on a Serious Game
3. Get better at marketing & producing a game.
4. I want to improve my programming skills in C# and the Unity Engine.

Here is also a link to the work blog of our new game where we will post updates as the game develops.

https://moneytreegame.wordpress.com/

It will be a Serious game about rising house prices and banking.

Big Game Project, Final Post

So one month has past since the project ended. So what did we end up with?

We have a working level and I'm happy with what we accomplished in such a short time even though the game is lacking in certain areas like UI functionality and maybe some gameplay mechanics.
I do however like the graphical style of the game and the feeling it gives when played.

The last week of the project I went back to working with the UI again with help of the graphical artists we remade the whole UI. 

The main menu now has 3D text and is a proper menu level. I't still needs some work but is overall quite okay. The buttons in each screen is in different positions and need some more work to have good consistency. It's good custom to place the buttons in the similar area in all screens so the player don't have to look for them as soon as a menu screen is changed. Some tweaking needs to be done with that but It's working for now.

In the actual game we replaced the boring placeholder art for our HUD and we finally added our real UI made looking like background vegetation.

(The old UI)

(The new UI)

The UI seemed to be accepted and used by the players. The experienced players (players who had played 2-3 times) could easily interact with the UI and knew what it all meant.
New players had problems though. almost none of them saw the blinking "C"-Leaf when a level was gained. By clicking the C-Leaf button the character screen opened up so the player could increase the players attributes gained by the new level. If the new player did not see that he missed to increase the stats and was too weak to handle the coming challenges and died easily as a result.

Some players also had problems feeling the sense of danger because of lacking UI interactions with the player when the health was low, In lack of particle effects or visual effects and sound effects. Not much warned the player that just got hit by a "You lose screen" when the health reached zero.

I have learned a lot from this project. one of the biggest lessons is that UI takes A LOT more time than you think. It's not something you just slap onto the game afterwards. It needs to be iterated upon again and again....and again....and then some more and when you think you are done you need to remake the whole thing and work on it some more.

Here are two more screens of what the game looks like in action:

A BIG thank you to my amazing group!

Big Game Project, Week 4

Hi,

I'm a bit late with this post but this is for week 4 of the project. So this week (previous week) I was put on handling AI so I have put the menu and HUD stuff on hold for now. So lets dive into behavior trees!

For AI we will use Unreals built in behavior tree. The behavior tree in Unreal is a very big plus for the Unreal engine because it makes this so much more easy because normally when you create behavior trees in code you need to visualise it or draw it down on paper to understand it and here Unreal allows you to build it visually right in the engine. You can also see where in the tree the AI/NPC is at run time by opening the window next to your game. its amazingly good!

For those of you who want to know more about behavior trees in general here is a good link:

http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php

The tree starts from the top with the root node and works it way down and it starts going to the left branches and works itself down all the way and moves right when it can't move further down. It's kind of like a finite state machine but in a three structure where it chooses different paths in the tree depending on if different conditions are met or not.

My tree is still work in progress and is still very simple. It works something like this:
Do I see an enemy? if yes then attack, if no just wander around. That's basically what the tree does now.

Here is a screenshot of the wander part of my tree.































It first checks if I have a Target (enemy), if not then it will step down to the left and check if I have a TargetLocation to walk to, If not it finds a random spot in a certain radius and sets that as the next TargetLocation. After that it goes to the next task and sets the walking speed to 150. When that is done it returns true all the way up the tree.

Next time this three is run it won't go down to the left because it has a TargetLocation set so it will move done right and move to the TargetLocation. When the TargetLocation is reached it will move back to its starting position, it's HomeLocation. Fairly simple and it works quite well. I didn't choose Unreals built in walk to tasks, I made my own custom walk to tasks that also checks to see if a enemy is spotted while walking and if it is it return false up the tree to trigger the other parts of the tree related to attacks.

One thing that is fairly easy to forget when starting out with behavior trees is that it can be very easy to forget to add both success and fail on tasks when they are done (as seen below). I forgot to put a fail on a task that needed it and the tree got stuck there every time it ran and I couldn't for my life figure out why. Depending on how you build the tree this might be very important and I would say add fail on tasks rather then not adding fail even if it might seem pointless at the time.

In a few days I will write my next post and continue on behavior trees.

Big Game Project, Week 3 - Serialisation and Character Selection

Hi,

This week has been about finishing up the character selection (the programming part) and figuring out how to save and load a game since we will be able to unlock characters we kill in our game so we needed some way to track that as well as all the regular data that needs to be saved like stats on your character and such.


Now the player can choose a character, click the new game button and can then add a name and press play to play as that character.

The game saves the selection and name for the next time the game is played. When the player returns he or she can choose to continue with the saved character or press the new game button.

If the player unlocks a new character in the game it will be available in the menu like this gnome character below. Here you can see that no name is displayed and only the New Game Button is available.

There is quite a lot of code that goes in behind all this...or should I say visual code perhaps since all is done using Unreal's Blueprints. I won't go into all that but I will mention the saving part of this.

First I created a SaveGameObject that holds all the data that needs to be saved. I then added code in our Gamemode Blueprint that handles loading and saving to and from this SaveGameObject.

The first step the GameMode does in it's "Begin Play" Event is checking if a save game file exists on the computer by calling the below function. If it doesn't it creates a SaveGameObject that will use my SavegameObjects data and then save and load that to file. So Unreal has built in functionality for this.

So first "Does Save Game Exists" is called. If a save game file exist it calls "Load Game From Slot" and cast it and set that to my SaveGameObject I created. If it doesn't it calls "Create Save Game Object" and cast it and set it to my SaveGameObject . After that I "Save Game To Slot" to actually save the game to file so I have it there for next time even if no info is added at this point.

 

Then I have two functions called LoadData and SaveData that basically works similar to the picture above but only do just what the name implies.

Here is a link to Unreal's documentation on the matter: https://docs.unrealengine.com/latest/INT/Gameplay/SaveGame/Blueprints/index.html

A note. I have had some problems with saving data into my SaveGameObject before the actual save is made so I have gotten some strange results and I highly recommend using breakpoints and Print string functions so you see for sure that all data is saved and loaded correctly.

The trouble I had was adding an array of an Actor component to the SaveGameObject which didn't work too well since my SaveGameObject is not an Actor, at least I think that was the problem. I couldn't access the contents of the Actor components so in the end I replaced that with an array of a Blueprint structure to hold all my data instead. It works much better now but its a bit tedious with the structure to access its members and setting them but it works.

If you have any question regarding saving and loading using Unreal's Blueprints feel free to ask by writing a comment.

Big Game Project, Week 2 - GUI

Hi, New week == new blog post.

At the beginning of this week I migrated all the gui stuff I did previous week into the real project. I had to do some tweaks here and there to make it all come together.

I added functionality in most the gui objects so they hold an image behind all buttons and stuff. So when our talented graphical artists have time to make textures and nice art to the gui I can just slap it on there. As you can see in the picture below I added a Character Panel this week with all the stats.

(All the art you so in all the screenshots are placeholders so its not from the final game.)

(closeup of the character panel)

So in a design perspective I have tested different locations for all the gui elements because I want to design it all so it will be minimalistic so the players main focus will be on the actual environment of the game but its hard to test until we have a playable game.

The Character panel and the inventory can be moved outside the screen. I added a "C" and an "I" on them to show the players how to open them because they will start hidden like the picture below.
When the player either press them with the mouse or with the keyboard they animate out to their final position.

(the black borders on the sides will not be there in game. not sure why they show up sometimes)

I also added so that when you mouse over an object it will show what it is and when you stand close to it you get a different text. This is to let the player know that he can do something with a certain object. Se the text "Stone" and "Pick up Stone" below.

In the middle of the week I used about a day to learn about Unreal's Navmesh navigation system. And I found out that its fairly easy. The only thing I had major problems with was when the character was walking in a certain direction he was looking at the final target and not in the walking direction. To fix this I started out with making stuff rotate left and right to get it right but then found a very easy way to do it. Just set so the character orient its rotation to movement.....Done!
It took med 3 hours and it could have taken just a few seconds if I would have known this one.

And lastly I started working on the start and option menu. We will have a menu were you can choose all the monsters you have defeated and then chose to play as them. This is the start screen with some buttons, Nothing much right now but its work in progress

When you click new game you will be able to play all unlocked characters. You will select them by scrolling them in a circle or something similar.  Below is a screenshot of an idea of how it might look.

If you have any questions of how I did a certain thing please leave a comment below and I will try to answer it as soon as possible.

Big Game Project, Week 1

This is the first week of the production of a game for our class Big Game Project.
I'm in a group with three other people, Two graphical artists and one other programmer.
I will have the role of a programmer and I chose to not take a lead role in this project so I could focus more on production and learning. The game we make will be a dungeoun crawler with a camera view similar to that of Diablo 2. The motto of the game is play what you kill. So basiclly if you kill an NPC you are allowed to play as that character. The game will be made with Unreal Engine 4.

I have spent this first week to learn the layout of the unreal engine and focusing on working with Unreal's Blueprints. Blueprints is a visual programming tool and you can make a complete game with it without writing a line of code.

How it works is this, It starts of with an event node (Red on screen) or a function node. And from that you draw a white line that is the execution line and then make a new node that does something.
For example. The red node above "Event Begin Play" is run once when the game starts and then the white line goes to "Create PickupText widget" wich creates a component to handle text to the screen in this case.

Everything that follow the white line will be done in that order. I must say it takes some time to grasp all elements in blueprints but there are many helpful tutorials from Unreal and from the community to get you started.

This week I have been focused on lerning the basics of this system while creating a HUD and some GUI elements like an inventory. Here is a screenshot:

In it you see two bars, Health and Speed they don't do anything at this moment other then the visual.
I also created a pill object with a floating text that you can pick up into your inventory.
While in the inventory you can choose to use / consume the pill, drop it or cancel the action.

Next week I will try to migrate some of this into our real project and create some other components for our game.