Week 10

We have succeeded in creating a reasonable prototype in Unreal Engine 4, and since we have already used Gamemaker to demonstrate out level design, we felt that it would be best to use the UE4 prototype to show off our mechanical design.

We aim to have a playable prototype ready for the presentation in week 12, but if we struggle to find time to implement all of the things that we currently plan to, then we may have to settle for demonstration in the form of screen-capture videos.

We have continued to keep the game design document and technical design document updated as we add new features to our prototype, and we will hopefully be well equipped to spend most of our time developing the prototypes rather than having to catch up with unfinished work in the documentation.

So far in the UE4 prototype, we have configured the movement of the ball. By default, the player can only control the direction in which the ball spins, so the position of the ball is only controlled by the ball coming into contact with surfaces and having friction with those surfaces. We have added a push force on top of this, so that the player can control the ball's position while it is in mid air. We hope that this will make the game less frustrating for players by providing them with more constant control as they play.

Week 9

Our level design has been focused on more than the prototype, because it’s one of the most key elements of the game. Completion of documentation is a big task too, so there are lots of things to check. The game prototype should probably be the next thing that we focus on. Once it is out of the way, then we can focus more on other tasks.

Our meeting with the producers involved some discussion with regards to the prototype. We described how we have been using Gamemaker to develop the prototype video so far, purely as a way of demonstrating our level design. We now intend to create a prototype using Unreal Engine, as we would like to show what the exact look and feel of the game will be.

This may mean that we should shift our attention from prioritising the completion of the prototype video showing our level design in Gamemaker to a better, more accurate prototype created using Unreal Engine.

Week 8

Despite what was said in the previous internal meeting’s question section, the group has now agreed that there is no reason why we should not create some kind of template that would be applied to each level. We decided that the levels that have been designed so far should be analysed and adapted so that the process that the player must follow in order to complete the levels follows the same basic structure across every level. The difference will be in the specific mechanics that are used, and creativity comes from how to make this same structure does not become obvious to the player.

After this is done, we can continue to design more levels, which will include more unique abilities and interactions. Each team member will ensure that any changes made to the level template are updated in the game design document.

When analysing each level that has been created so far, we should seek answers to each of these questions:-

• What kind of task must the player complete in order to pass each stage of the level? (e.g. object interaction, specific form interaction, skill challenge)
• In what order must these tasks be completed?
• How are these tasks made obvious to the player?

Week 7

We have made steady progress with our level design and the development of the Gamemaker prototype. We have a process for drawing up storyboards for new level ideas, and then using those storyboards to create playable versions of levels in Gamemaker.

All unfinished work from previous meeting has been completed and steady progress has been made on work assigned for this week.

Everything is on track to be completed in time for the next meeting.

Week 6

So far, the group has updated sections of both design documents and continued with practising of Unreal Engine. However, we have decided that more practise is required before commencing with the development of the prototype.

We will maintain contact with each other as we practise using Unreal Engine, and continue with the prototype when we are able to do so.

Week 5

All members of the team agree that we had been relatively overambitious with the tasks that we set out for ourselves prior to our last meeting with the producer. We have successfully caught up with all unfinished work from last week and are making steady progress towards completing new work for this week.
With each of us having completed an Unreal Engine 4 tutorial, we are all ready to continue developing the game design and technical design documents.

Although it was only a small part of our schedule for the week that remained to be completed, our meeting with the producers made it clear that we must ensure that all work for each week is decided upon prior to that week’s meeting with the producers. After our last meeting, we immediately created our plans for the work to be done for this week, as this seemed to be the most urgent of tasks to be completed.

Two members of the group have made good progress with level design, having made storyboards and now moving on to documentation work. The other member has spent more time completing tutorials and using what he has learned to help with sections of the technical design document.

Week 3

Research

We realise that the level of research that we have done so far may be somewhat insufficient in completing some of this week's tasks within the allocated time frame. We have decided that our top priority for this week should be to improve the design documents. As a result, we may have to assign extra time after our next meeting to accommodate for this miscalculation.

We decided to play a lot of games in the ball roller genre as we thought that this would assist us in the creation of our competitor analysis. We also subsequently found that the more unique games that we played gave us inspiration for extra modes which we could potentially include in the later stages of the project, if time permits.

Design Documents

We also have come to realise that completion of the design documents will require a more extended period of time than we had originally anticipated. This is mainly due to us having developed our ideas for more complex game mechanics and level design, requiring a greater deal of elaboration within both design documents. By taking these things into account, and adapting our plan accordingly, we foresee no problems in completing tasks relating to either of the design documents.

Conclusions

Having played through a number of other games within the genre, and having briefly experimented with Unreal Engine 4, we have noticed that a possible issue which may occur during the game's development is that of game physics. The movement of the ball in UE4 feels very different to the way that the balls move in many of the other games that we have played. Due to our inexperience with UE4, and 3D environments/physics in general, we are unsure how much time and experimentation it will take for us to fine-tune the physics of our game to a satisfactory level.

Week 4

Some of our puzzle ideas were inspired from 2D games but designed to work in a 3D environment.

One such inspiration is Paganitzu. Paganitzu  is a tile based 2D puzzle game with a top-down perspective released in 1991.

The object of the game is to collect all the keys in a level to unlock the exit and try not to get killed by monsters and traps.

Rocks can be pushed around by the protagonist. Rocks pushed into water, lava or slime turn the spot into solid terrain.

We use the mechanic of the player being able to push objects around in our game and incorporate it into our puzzles.

We also incorporate geographical elements such as water and lava into our games puzzles.

Week 2

Teamwork

Having had less than full attendance at the first meeting with our producer, we have been made aware that a strong understanding and commitment towards regular communication will be an essential aspect of the success of our project. We have set up a agreement to have regular progress check-ups at least once every two days using Skype. This will ensure that any issues which could arise between meetings with the producer can and will be addressed promptly.

Game Idea

Our team has decided on a single idea for a game. We have chosen to develop a rolling ball game. We chose this because we agree that it provides us the freedom to incorporate elements from a variety of other types of game genres, such as:- role-playing, puzzle, platform, maze, beat 'em up etc. We have yet to agree upon which of these genres will have a more dominant influence on gameplay, but this is the next major step in the design of the game.

Planning

We are currently at the stage of planning a full timeline of our project and producing deadlines for project milestones in preparation for the creation of a Gantt chart for the project. We plan to prioritise a steady progression of both the game design document and technical design document throughout the entire timeline.

Technical

Having reviewed the pros and cons of each game engine provided by Josh, we have decided to use Unreal Engine 4 for the development of our game. Popular/powerful/access to free materials/using it in 4th year/C++ experience/lots of tutorials available.

Week 1

Paul Fitzpatrick

My day 1 plan for third year

My favourite gaming genre is Roleplaying games. specifically I enjoy games with levelling up systems using numbers for character progression. I enjoy everything that includes this mechanic and all kinds of numbers/integers (some examples being “Level, Experience, Money, Health, Mana, Ammo, Attack, Defense, Speed, Equipment slots such as head and legs, the weight of that equipment, the quality and power of that equipment, your characters skills/qualifications and training them”).

I could go on about lots of number I like to progressing higher some more than others.

I think it’s the idea of training your character I like the most especially training their fundamentals that can be practiced in everyday situations.

3d fps’ like “Fallout & Bioshock”, third person MMO’s like “World of Warcraft & RuneScape”, multiplayer online team based games like “League of Legends”, to NES/SNES classics like “final fantasy & Super Mario RPG”.  Are all very different games I enjoy.

I really want to get experience working in this genre but for it I may have to sacrifice some level of originality, of course I plan to add plenty of my own twists game mechanics and theme wise. But I am usually used thinking more out of the box with my ideas so most people could notice the unique twist from a one sentence description, a borrowed example being “instead of being able to jump you just always fall and the jump button just flips the screen upside down”.

I would want to make a NES/SNES classic RPG but even for 1 person it seems like a lot of work so I was thinking of cutting the 2 main aspects of an RPG in half and working on one of those aspects.

I was wondering if you would recommend one of these 2 projects after reading each description or at least what’s highlighted in red.

For simplicity’s sake I will use the original Pokémon games and cut one of them into 2 games.

Game 1 – RPG Combat System

The turn based combat system of Pokémon lets the player select an option from a series of menus once per turn (for example this turn the player might want to select Fight followed by Water Gun this turn) and without going into too much detail it’s essentially a really complex game of rock paper scissors.

I could make a combat system like this as a project where my primary focus would be getting the options I can choose from a menu to interact with my opponent and my opponents options to interact with me (game could be 1 or 2 player, 2 player is possibly better for time constraints so I don’t have to make an automated response).
If you are going to release these games for sale you would have to balance the numbers so that a certain strategy, move or combination wouldn’t be overpowered, but since this is my first shot the main importance is getting these options to display a result or show the user feedback for what they have done before I think about balancing.

If I were to do this I would make a barebones Overworld that is basically just a still image with options to select from a menu that should lead to combat and possibly some other things that can be added after the combat system has been sorted such as a shop, tavern to rest and heal your character & equipment screen.

(Choice in both the combat system and town could be made from click or the arrow keys backspace and enter.)

Example from “Reccetear an item shop’s tale”

Long story short it’s a somewhat complex RPG combat system with a very basic overworld.

Game 2 - Overworld adventure game.

Pokémon is basically just Zelda with a different and more complex combat system.

Let’s compare Game 2 to Zelda with its hack and slash combat system instead.

Example from “The Legend of Zelda”

If enemies have 3 health it will take 3 swings of your sword (which will swing 1 or 2 grids in front of your character) to destroy that enemy.

Be careful to dodge enemy attacks so you don’t deplete your own health and die.

There’s not much to say here, Zelda is a game with very simple tools but with such detailed and expansive level design using implementation of those tools. And the sprite and background design is very good.

Long story short it’s a somewhat complex RPG overworld with a very basic combat system.

PROS & CONS of each

Game 1

·         Great combat system and use of variables weak Overworld and Level Design.

·         Very good for displaying programming skills and interactions between stats and numbers.

·         The AI might be hard to make a correct strategic decision.

·         If it’s just a beta test for the early levels the combat shouldn’t be so complex for it to choose the right decision however.

·         I don’t have to bother making AI if I make it multiplayer.

·         A lot of time spent programming to get it to work.

Game 2

·         Great Overworld and Level design/Sprites but simplistic combat system.

·         Very good for displaying design skills.

·         The AI is easier to develop for a single player game.

·         Is limited to single player.

·         These games are fun to develop because less time is spent on programming objects and more time is spent using your objects in interesting ways to design levels, basically like playing around with a level editor in one of your favourite games, except that you made the tools on the editor and can add more. (For example a wall can be used on almost every screen of a game with some tweaks to the sprite for the theme of the area, it’s pretty quick to make a single screen in this type of game once you have the tools and can easily make more).

The enemy design for both games could be quite complex

·         For game 1 it would be based on a strategic choice of option for the turn based on the strength of your character and weakness of your opponent.

·         For game 2 it would be more timing based, about the speed of your opponent and what types of attacks they have compared to yours like fast melee vs. slow ranged you could dodge the projectiles and rush the enemy because their mobility is weak.