Jamie Renfrey @jamierenfrey - Tumblr Blog

TextBook Readings: Chapter 9

Playtesting

“Playtesting is the single most important activity a designer engages in, and ironically, it is often the one that designers typically understand the least about.” (page 277, Fullerton, T., 2018)

This entry to the chapter was interesting to read, being that IGB220 has a major emphasis on playtesting. After reading through the section I discovered that its not just the process of playing and taking feedback but how you prepare for the session and the reasons why you do things in certain ways. So recruitment of playtesters, specifically your target market, the actual focals of the playtesting session - what we want feedback on, specific prompts to fish for open ended responses directed by the playtest manager.

On page 278, the graph outlines perfectly the process of iterative game design, over four stages - concept, preproduction, production and QA - where the flow from generate ideas to formulate, test and evaluate to then revise - this process I felt explained the process very well that revision and repair shouldnt be for the end of the project but a constant throughout.

Acknowledgement

Fullerton, Tracy. Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition, CRC Press LLC, 2018. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/qut/detail.action?docID=5477698.

#qut #gamedevelopment

TextBook Readings: Chapter 8

Digital Prototyping

As I mentioned in the previous post, creating a basic guide to follow helped to streamline my digitised prototype as I had already hashed out multiple ideas and set forth a main goal.

Chapter 8 outlines that digital prototyping isn’t necessarily a finished product, but a basic model that can be fleshed out further but with just enough done to get a feel for the game itself. This process I did in my first design sprint, as I was fresh to GDevelop I was learning as I was creating, so my intention was to create as basic a level as possible to playtest then I returned to the game after the playtesting period and fleshed out the game further to a more solid completion state. Aesthetically, it was dull at first, as well as the mechanics weren’t 100% where they needed to be, but after advancing my own skills with Gdevelop, I found it not too difficult to finalise my original idea.

Acknowledgement

#qut #gamedevelopment

TextBook Readings: Chapter 7

Prototyping

“Prototyping is the creation of a working model of your idea that allows you to test its feasability and make improvements to it.” (page 203, Fullerton, T., 2018)

This chapter was an interesting read - in that prototyping is performed in many ways, such as pen and paper before even moving into a digital medium.

Chaim Gingolds story in the textbook (page 210, Gingold., C., 2018). Mentions about working economically, basically, working small to work fast, taking on too much can hinder a project and create countles sproblems over development.

This is something I encountered in my thrid design sprint, I added and added and added to the point I created soo many problems, and two weeks became an unrealistic timeframe for what I had set out to accomplish, I did it, but in the process I created far more bugs than I had solved.

One thing I did attempt during prototyping was to draw my ideas before virtually designing them. i find that by having visuals, it was a lot easier to create a digital version because I had outlined what I was trying to accomplish first with diagrams, basic drawings etc.

Acknowledgement

#qut #gamedevelopment

TextBook Readings: Chapter 6

Conceptualization

This chapter covered key elements of ideas and how to refine them.

Personally, I struggle with taking ideas and fleshing them out into a realistic project. The phrase ‘less is more’ is an approach I try to follow, but I find myself always over doing every little thing I set myself on task to do. The problem with this approach is that the quality of the idea suffers as I overflesh it out.

In chapter 6, Fullerton explains that no creative process is the same for everyone and won’t necessarily be on a linear path. Ideas should be brainstormed and expanded upon, then hashing out the most realistic outcome for the projects overall goal.

Interestingly enough, I have countless notepads of ideas for games, every now and again I return to these and storyboard them into a more understandable concept. I used this method with some of my design sprints, the problems I encountered however were that I didnt slash a lot of my ideas, instead, I continued to add to them.

So, following Fullertons method of brainstorming over a set period of time without going too long might play a part in my design thinking moving forward - so that I can stick to realistic ideations of future projects.

Acknowledgement

TextBook Readings: Chapter 5

Working with System Dynamics

“A system is defined as a set of interacting elements that form an integrated whole with a common goal or purpose.” (page 129, Fullerton, T., 2018)

I read this chapter on systems as being the structure of games as a combination of previously discussed elements such as rules, objectives, goals and rewards to name a few.

I considered how I approached systems for my design sprints and their respective genres. I think I focused more on the limitations and rules, for example, for the platformer design sprint, I didnt want to make the game too easy or blow the mechanics too far out of proportion, like jumping. So my main focus with that sprint was to withhold ‘hacking’ the game, ensuring obstacles couldnt hhave the player go outside the games bounds, or have the player get stuck at any point. That was my systematic approach to that title.

For the ogres run game, my system was a little more refined, I aimed to use one map and have triggered events to establish races. Kind of how Need for Speed operates. It was a challenge to reset all elements back to their original settings prior to the race start but was effective.

Acknowledgement

#qut #gamedevelopment

TextBook Readings: Chapter 4

Working with Dramatic Elements

This chapter was exceptionally large also, but one area I have large interest in is world building and how it sets scenes, creates stories and establishes a games feel.

World Building

Fullerton compares digital games from their inspired sources of medias such as books and television shows.

“World building is the deep and intricate design of a fictional world, often beginning with maps and histories, but potentially including complete cultural studies of inhabitants, languages, mythologies, governments, politics, economies, etc.” (page 117, Fullerton, T., 2018)

This introductory to the section was interesting. I found I applied this thought process when designing my third sprint, Ogres Run. I created a store, a basic monetary system, a village, its inhabitants, its purpose, etc - for a small project like this, it wouldnt be necessary to delve too deep, especially for a two week sprint.

The Dramatic Arc

The ellaboration of using conflict within games to immerse players into the game experience emotionally was interesting and had me considering previous games where I found myself emotionally invested in a story or quest and would bget excited about getting home as soon as possible to continue playing. Capturing that feeling and thinking about how I can incorporate this into my own design thinking was a great section to read through.

Using tension to rise and fall as stories/quests progress over time from exposure to resolution of the tension was interesting. I viewed this on my own design sprints as being that near end to a level with very little remaining health and pushing through to the end while on the edge of your seat.

Acknowledgement

#qut #gamedevelopment

TextBook Readings: Chapter 3

Working With Formal Elements

This section of the textbook covered a lot of content. A few standouts of this chapter for me included the following;

Player Interactive Patterns

Player Vs Game - Single person playing a game independantly

Player Vs Player - Two persons playing a game against eachother until a victor is decided

Multilateral Competition - Individuals more than two playing a game against eachother until a victor

Team Competition - Teams of players versing other teams in co-operative play until a team victory is won

Multiple Individuals Vs Game - Players versing a game until one player wins

Unilateral Competition - Individuals more than two playing a game against one person until a victor

Cooperative Play - a group of individuals playing against a game collectively

Objectives

“Objectives give your players something to strive for.” (Page 68, Fullerton, T., 2018)

In this section, Fullerton covers some general questions to ask ourselves when designing game objectives and also briefly states that objectives can have an integral part in player enjoyability.

During the group design sprint, while playtesting I found that players when given tasks and goals to accomplish were more focused on their play than they were when left to freely play. So re-reading this section of the textbook reminded me of moments where it applied in my projects.

Conclusion

Though this chapter covered a lot of content, the above were really the standouts. I didn’t realise there were specific terms for types of playability and the objectives I found interesting when putting it into practice during playtesting - actually being able to see the results of the process, of which I found beneficial.

Acknowledgement

#qut #gamedevelopment

TextBook Readings: Chapter 2

The Structure of Games

This chapter identifies the differences between game styles, such as boardgames, digital games and card games while analogically comparing them to the differences between players.

Players

Players think, feel and do differently to other players playing the same game. This section of the book had me contemplating the differecnes between people and how to accomodate for them when creating games. In previous design sprint posts I mentioned that from playtesting, some of the feedback received was to cater for different keyboard playstyles. I attempted different styles in each sprint but by the final group design sprint I was still met with using a different style to play the same game. Re-reading through the textbook and this section specifically had me re-think my process for ideation and to again, consider the differences in players as the forefront to my design thinking.

Objectives

“In games, the objective is a key element without which the experience loses much of its structure, and our desire to work toward the objective is a measure of our involvement in the game.” (page 34 , Fullerton, T., 2018)

Like all things, structure is required to keep people interested in what theyre presently doing. Sport without goals could’nt possibly be enjoyed as well when objectives aren’t set for the players and same to exists for games.

Rules

Like objectives, rules play an integral part of any game of any medium. In chapter 2, Fullerton exlains the purposes of both objectives and rules, which had me thinking back on the set restrictions I added to my previous design sprints, such as health bars, scene timers, scoreboards, obstacles, etc to name a few.

Rules can often be perceived as intrinsic methods that players agree to while playing games, for without followwing these set rules, players aren’t technically playing the game.

Engaging The Player

This section covers a multitude of elements within games, some key areas I found interesting and tried to apply to my design sprints were;

Challenge

Conflict plays a part in any game, and creates challenge for the player. Fullerton explains that there must be a balance between challenge and difficulty as rising senses of tension and frustration can alter a players engagement with a game. Making objectives too easy can have players feeling like they have accomplished the game and move on quickly whereas making things too difficult can have players give up. Balance of challenge is key to engagement.

Play

Play can be related to freedoms within a game. Balancing player freedoms and game restrictions can provide opportunities for players to become imaginitave within the game. Too many restrictions and players can lose interest.

Conclusion

I found this chapter interesting as at its core it outlined areas of focus when thinking about design work for games.

Acknowledgement

TextBook Readings: Chapter 1

The Role of Game Designers

In this section of the Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition textbook, Tracy Fullerton writes about what is required in thinking like a game designer and the iterative process behind designing games.

An Advocate For The Player

“The role of the game designer is, first and foremost, to be an advocate for the player.” (page 3, Fullerton, T., 2018)

My understanding of this is that aside from creating games we as designers want to, but to create games with elements that players want to see. Seperating our own goals to the desires of players.

Playtesting

This section goes on to discuss that in the early ideations of game development processes, developers and players ideas are on similar planes, but as the development carries out, these similarities fork into different directions. In which case, this is where playtesting plays a huge part of aligning these goals together as it gives players a chance to provide feedback on early versions of the game, thus bringing the project goals between developers and players back to the same path.

Playtesters are vital to the ongoing success of development, in many cases, playtesting is done toward the end of development. Fullerton explains that this methodology may not provide the best results and that to instead focus on consistant playtesting throughout development. This way problem areas can be identified as development is occuring and can easily be fixed along the way. Whereas leaving playtesting until the end of the project may result in sacrficing meaningfull changes due to time constraints at the end of the project.

During playtesting its mentioned that the process should be treated like a party, wherby the developers host the players and guage reactions from them as they play along, jotting down as much information from the process as possible while not guiding them on how to play, instead how they play.

Passion and Skills

“A great game designer is someone who loves to create playful situations” (page 6 , Fullerton, T., 2018)

This part of chapter one stuck out to me as being a trained chef of over 10 years I lived by a similar mantra just with taste of food for guests. This section goes on to discuss that consistent internal playtesting can become incredibly mundane and more choreish than playful, but as deisgners we need to remain dedicated to the project and passionate in its success.

Communication

Communication is key to the success of any industry and profession, so it was no surprise to see this translated to the video games industry. It continues reading that as designers, we need to sell our ideas over and over to as many people as possible in clear and succinct ways. It also mentions that collaboration is key to a projects success, understanding peoples input and accepting their may be improved ways to accomplish our ideas in differing ways and directions and sometimes compromise can lead to new and exciting ideas.

A Playcentric Design Approach

This area introduces the iterative design process. Brainstorming, Physical Prototype, Presentation, Software Prototype, Design Documentation, Production and Quality Assurance, are the 7 main steps to the early ideation and production stages of design thinking.

Over the weeks of this subject, IGB220, we have had a number of projects that we needed to ‘Sell’ with a simple elevator pitch. Though we did not have to go fully in depth with the iterative design process, we did do very rough sales pitches during the workshops where we sold our ideas, gained feedback and improved the ‘Drawing Board’, so to speak, before moving into the production process.I have outlined in my elevator pitch posts the details of each project.

Conclusion

As a final point of this chapter, I found Peter Molyneux’s brief very interesting as I have followed his design journey from the early stages of Fable when he co-founded Lionhead Studios.

Acknowledgement

#qut #gamedevelopment

Week 13 - Final Thoughts

This semester was incredibly challenging for me, many obstacles prevented me from working to the best of my ability throughout the semester but overall it has been incredibly fun.

I’ve learnt more about the GDevelop engine than I previously anticipated at the beginning of the semester, I’ve designed 3 seperate games in short design sprint blocks, learnt how to use tumblr (insert laugh), exposed myself to a group design project as the project manager (a role I really enjoy doing) and have met more people in the course and have formed many new relationships with my peers.

It has been a great semester overall, regardless of the challenges, I feel I am walking away with a bredth of knowledge I didn’t have walking into the semester.

Only a few more loose ends to tie up and it’ll be the end of year break, over which time I intend on revising the semesters works accorss all subjects so that the information sticks a bit better without pressures of timelines and constant new information being thrown in our direction.

David was instrumental in my knowledge of the 220 subject and I am incredibly thankful for the tutors in this particular subjects support throughout this subject and the year in general.

All the best!

#qut #gamedevelopment

Week 12 - Project Post Mortem

Overview

We have finally reached the end of the game development for Unicorns Rage!

Upon reflection, I am very pleased with a number of areas and changes that were made on a simple game idea I had in week 4 of the semester. I really enjoyed this project, again, I was surprised others were interested in expanding upon this game beyond my two week design sprint earlier in the semester. To have Josh and Patrick build upon this game and fix the problems I was short timed on previously was a great and seemless process, they really amplified the development process.

What I’ve Learnt

How to create an inverse player control system

How to use cursor hover and selections

How to conduct official playtesting

Working as part of a team to complete a game project

The Ins and Outs of GDevelop

How I took Feedback From Playtesting

Being that I had feedback from the early version of Unicorns Rage playtesting in the semester, I already had a rough idea of objectives for this project. Like every feedback session in the past, my main focus was to eliminate as many potential comments and find the feedback I couldnt identify myself.

I strongly feel this was accomplished this time as many problems were outlined that we didn’t have on our end prior to exporting the project. Some of these issues included bouncing outside of the game border while recharging mana, the adopted move in Level 2 didn’t work at all and players identified that they were uncertain on the mushroom objects purpose (even though the on screen hints prompted this) meaning additional work was required.

One stand out I found interesting from one playtester was that they wished to have the ability to use their mouse to move the player. If you recall from prior blog posts, this has been an ongoing problem I encountered accross all design sprints, at first, for mutant kitty, I used WASD keys for movement, unicorns rage version 1 I used arrow keys, for Ogres run I used WASD keys and for this design project we gave the option to choose between both as feedback each time relating to movement was opposing to the opposite key system that was implemented. To now, being mentioned that a third movement system is preferred was a moment of ‘oh damn’, thinking you covered all bases but you dont anticipate option C - this was insightful and definitely noted for future works, do all possible movements.

Overall from the playtesting, there was a lot of enjoyment from the play testers and I’m glad the game was a success in this regard.

We compiled the areas for our report in this table below;

General

Bugs

Group Contributions

Between Patrick, Josh and myself I felt the team dynamic went well. From the start of the project until the end of the project I am confident the work made from each member was fair and identifiable.

Josh did great work on the GUI elements, large sections of the coding for control systems and the video for the playthrough while also being the event logger for the playtest sessions and completing the questionnaire.

Patrick was instrumental in our level design, consolidating the code for the player selections so that scenes could be reduced, while also note taking for the playtest sessions and the graphical findings from the surveys and questionnaires.

We started this project well ahead of schedule and I found that the timeline of events was the right approach to this project in comparison to the Ganntt approach and after querying other development teams about how their schedule was being upheld, many said that they weren’t up to the projected daily task outlined on their Ganntt. So I’m pleased our wekly timeline was simplistic, to the point, not blown out of proportion and unrealistic to accomplish.

In Conclusion

The project was a great success, both in development and in playtesting. My personal goals were met with identifying problems I couldnt find myslef and the development went off without any major hitches or setbacks.

This was an exciting undertaking and a great way to complete the IGB220 unit. I had a lot of fun and am looking forward to the adventures of year 2 in the following year!

Final Version

If you wish to play the final version of the game, follow the link below!

https://games.gdevelop-app.com/game-c32e0ea3-3a95-474c-8eb4-45102d900fa4/index.html

#qut #gamedevelopment #postmortem #unicornsrage

Week 11 - Project Playtesting

Overview

This week our team intended to do the playtesting for our Unicorns Rage prototype.

After weeks of work on this game it was exciting to share the game with people and gage their reactions. For our playtest, we were required to create a script, survey and questionnaire (pre and post playtest).

Our intention for the playtest was to identify a fe core elements of the game;

Bugs

Ease of play

Overall enjoyability

For the playtests, my role was the playtest manager, responsible for the flow of the sessions and ensuring each session was run the exact same way and prompting the testers for consistant information, what they’re doing, pressing and thinking. Josh and Patricks roles were to take notes during the session with focus on the occurances during the session. Patrick also recorded each session for us to use at a later stage and refer back to.

Script

As the playtest manager I was tasked with creating a speal that would be read to each playtester, so that each person would receive the same information during their session;

Questionnaire

Josh was tasked with creating a questionnaire to obtain data on our playtesters, based around their gaming dynamics;

Survey

Patrick was responsible for the Survey which is the post playtest questionnaire gaging basic information from the playtesters session. From this information we can identify the problem areas and rank them on severity of the issue for future version fixes.

Findings

In this section I will outline the results of the playtests as well as the survey and questionnaire.

Questionnaire Findings

The results of the questionnaire outline the demographics of our playtesters. These results showed slight variety in players and was conducted prior to the playtest session. Patrick compiled the results into graphs for simple reading of information;

Survey Findings

The surveys were conducted post playtest and help to identify areas requiring work and players overall enjoyability, Patrick compiled the results into graphs for simple reading of information;

Identified Bugs

The playtesters provided a decent amount of information without guidance, and on occassion I did need to prompt for more information. However, some very valid points were made and we quickly compiled a recommended patch list;

General:

Bugs:

Playtest Recordings

Due to doing the playtests digitally, we recorded our sessions for later refferal if required;

In Conclusion

Playtesting was a great success, discorvering areas of improvement from the perspective of prospective players gave greater understanding to develop the project further.

Until the next time!

Playtest Prototype Link

If you wish to try the game version that was used for the playtest, follow this link;

https://games.gdevelop-app.com/game-c32e0ea3-3a95-474c-8eb4-45102d900fa4/index.html

#qut #gamedevelopment #playtesting #unicornsrage

Week 10 - Project Development

Overview

This week I plan on outlining the current progress of Unicorns Rage.

Interesting turn of events for this weeks check in, we anticipated compiling our sections of work on GDevelop and transferring the file to myself to bring the works together. However, this was no easy feat as two projects could not be open at the same time and code could not be copied from one project and pasted into another. This created a larger task ahead as everything needed to be input manually.

I also discovered that transfership of files did not always update filepaths for certain objects or sound bites/music etc as they were set to a filepath in my OneDrive. I rectified this problem by reassigning every single asset into new root folders within the project file on my desktop.

I’ll break up the development progress below to show the changes from the prototype version I made weeks ago, to the current version which will be used for playtesting next week after a few more kinks are tidied up.

Player Sprites

One of my tasks was to fix the object sprites players could use as their main character;

Originally, I went through around 82 frames for each coloured character and mass edited their colour using piskel paint all functions. Due to time constraints previously, this task was never fully finished;

Version 1 - White Player

Version 2 - White Player

Version 1 - Blue Player

Version 2 - Blue Player

Version 1 - Green Player

Version 2 - Green Player

Version 1 - Pink Player

Version 2 - Pink Player

Version 1 - Red Player

Version 2 - Red Player

Version 1 - Yellow Player

Version 2 - Yellow Player

In total, Each player had 80 frames for one sided animation, 80 frames for other sided animation and 2 frames for top down view, making a total per player of 162 frames. In total player framework comes to 972 frames.

This was a big task, so the simplest way to tackle this was to do one player colour correctly first, then duplicate the file and paint bucket all to the new version colour theme (pastel neon). This reduced the length of time it took to accomplish this task.

GUI

Josh was tasked with creating a more vibrant GUI and this really set the ground work for the new colour scheme of the game. New buttons were created, with cursor hover effects.

Once I received the file from Josh and input his works into the main game file I was inspired to create more within the game to visually improve the overall experience.

New interactive buttons and health/mana bars

The GUI screens were drastically improved as well;

Title Screen Changes

High Score Screen Changes

Level GUI Screen Changes

Level End Screen Changes

Game End Screen Changes

These changes above may seem minor, but add some great visual beauty, and as stated above, they really set the theme for the game.

Interactive Pause Menu

From the new set theme Josh set, I was inspired to create an equally appealing pause screen menu which outlined what should appear when controls are pressed, etc.

I considered the controller scheme and adjusted the coding to reflect the players preffered layout choice;

New Pause Menu

Code and Scene Consolidation

The previous code was a mess - though readable - Patrick was tasked with consolidating individual scenes into a smaller file, from previous posts I mentioned that character choice was added later into development and due to time constraints it seemed easier to duplicate scenes than to add code allowing those scenes to one scene.

Patrick consolidated this code and once his file came through, I manually input hes additions/changes as well as add comment lines for ease of access throughout the development process;

Old Code - No Definitive Structure

New Code - Commented and Structured

With a more readable code and far less scenes- this aided in swiftly identifying problem areas to report upon. It is obviously the amount of time Patrick invested in consolidating the scenes as well, previously 38, now just 12.

Character Selection Screen

As well as the basic sprites, it was important to me to showcase a character selection screen that would wow people. This took a lot of tinkering but was quite easy to achieve. Instead of using a blocky sprite, I decided to create a block like particle effect over each character as they are selected;

Old Character Selection Screen

New Character Selection Screen

This is a simple layout with basic animations, cursor hovers and hide/show coding.

Controller Choice

The next process was challenging. Josh was tasked with creating inverse controls from two seperate keyboard layouts. Because this was done seperately from the main file and again seperately to Patricks file, it was challenging for me to add their codes to the new file as I had to cross referrence between three seperate projects and ensure each area was input correctly - as well as each of playtest through each selectable character and test each bit of functionality accross all levels.

Our goal from previous feedback was to have the ability to use WASD for movement OR The ARROW keys as movement, with the alternate being for attacks.

It wasn’t only the keyboard keys that were affected. It was also the pause screen which indicated which key to press for which abaility and each levels task bar at the bottom of the GUI.

It took a bit of time but was accomplished;

Control Choice Screen

It was important to showcase where the cursor was on the screen so players knew which selection they were at before choosing, again, just simple particle effects.

In Closing

There are a lot more functions and features within the game that I have covered in previous posts.

Overall, I am incredibly happy with our progress and we are sitting 1 week ahead of schedule. Many minor bug fixes along the way, the above is the more major inclusions/changes to the project. The team has made incredible development of a small game idea I had for a point of difference asteroids game!

Until the next post!

Playable Game Link

If you wish to have a try at our current developed game, please follow this link and let us know what you think!

https://games.gdevelop-app.com/game-c32e0ea3-3a95-474c-8eb4-45102d900fa4/index.html

Acknowledgements

The gifs made for this post were done using ezgif.com! Very fast and effective gif maker/editor

Another quick thankyou to 2dsprites.com and freepix.net for their open asset bundles

#qut #unicornsrage #gamedevelopment

Week 9 - Group Development

We have now reached the period of the semester where we move onto assignment 3. For this assessment we had to establish a project team and decide upon one team members game idea compiled in Assignment 2.

After presenting my idea for Unicorns Rage (Content in prior posts), I had captured the interest of Josh and Patrick for the further development of Unicorns Rage.

Our first task was to have Patrick and Josh get a feel for the game and assess areas of potential improvements. While this was occuring I established a number of resources for the team to utilise during the course of the project;

Journal - Using Google Docs for online joint editing access as a journal

Project Timeline - Using Google Sheets for a simplified project timeline of tasks

Group Chat - Using Discord

Once the team had a feel for the game we established our roles for development. I took the helm as project manager, Josh the programmer and patrick the designer. As we weren’t artistically versed, we opted to do small artistic sections each and use the existing sprites from the draft version of the game.

With the roles established and the familiarity of the game underway, I began work on the project management timeline. For a small project, I felt using the Gantt structure was a little unnecessary - mainly because tasks wouldn’t be completed on a day by day basis, instead our process would be set weekly tasks with report ins twice weekly, Monday and Friday.

By holding twice weekly scrums we would be able to consistently update our progress with the rest of the team and also report upon any issues faced for collaborative discussions on how to help fix them.

Our First Template also contains a progress column to indicate when tasks are completed or in progress;

Our next course of action was to take our internal playtest data and compile our notes, general and technical bug reporting, as to improve upon the game concept ready for its playtesting in the coming weeks;

Lastly, submission requirements were factored to aid in the dispersion of tasks as to keep things equal and fair in workload, simply section by section of the report;

For now, we’re all hard at work getting the testable prototype together for a first version playtest.

The original idea can be playtested here;

https://games.gdevelop-app.com/game-de5f335c-4ad8-4256-ad78-03999ce704c7/index.html

Until the next post!

#qut #gamedevelopment #designsprint #unicornsrage

Week 8b - One Page: Unicorns Rage

The Second Half of Assignment 2 was to create a One Page for the same game as the Sell Sheet.

The purpose of a One Page is to simply outline core details of the game with enough whitespace for expansions and developer additions along the path of development.

Some of the key focuses for a successful One Page include;

The Game title

Date

Game Version

Design Team Contact Info

Whitespace - For inclusions at later dates

Gameplay Design Illustrations (Focal)

Callouts for each feature in Illustrations

Feature Explanation Sidebar

Detailed X Statement Description

Additional Details (To communicate deeper understanding of the game)

Being that this is the starting point for design processes, it is important to allow room for project growth while maintaining succinct detail of the project on one A3 page.

I didnt itterate multiple versions for this project, I did however collaborate with colleagues and class mates for second, third, fourth and so on opinions of the document. To which I settled upon the following;

Final One Page Version

There were a number of features I wanted to communicate clearly with the One Page without over elaborating, such as;

Characters

6 Playable characters with defining colour features

Control Layout

An inverse control system whereby WASD and Arrow keys could be selected for movement and the other for attacks and vice versa

Player Attacks

4 distinct attacks and their purpose in the field

Level Design

Specific aesthetics for design to reflect a space feel

Enemies

Quantity of enemies, their mechanics and potential purpose

GUI

Basic visual requirements on screen, stat bars, tips, etc

Defining Features

Hilarious Sound bites, specific mana recharge mechanic

In Closing

For a first attempt at a One Page, I believe the core content was specified. Many game elements I had already introduced so the continuation or ‘upgrades’ of the game I was looking to see what the development team would add should this game be selected for development.

Until the next post

#qut #gamedevelopment #OnePage

Week 8a - Sell Sheet: Unicorns Rage

As part of assessment 2 for IGB220, we were required to select one of our three design sprint games and establish a potential sell sheet.

The purpose of the sell sheet is to be an informative single A4 poster, aimed at garnering potential developers in assisting to build the game.

Key elements of this document included;

The Game Title

X-Statement (Razor Statement and a Slogan)

Defining Details (Players, Genre, Platform)

Unique Selling Points

Game Art

Point of Contact (Email, Phone)

Game Description (Typically left out when X Statements are firm and precise)

Over the course of two weeks, a number of iterations and style peices were drawn together and after collaborative discussion amongst many of my classmates, Version 1.2 (Below) was the winner.

Version 1.0

Version 1.1

Version 1.2

Many other iterations and styles were developed prior to testing eye appeal with others, the above however were shared and expanded upon as completed copies.

In Closing

Overall I was quite impressed with the completed products above, I feel I included slight quirky humour to the design to attract eyes for a second glance.

#qut #gamedevelopment #SellSheet

Week 7c - Post Mortem: Ogres Run!

Final Report

A close to the development of Ogres Run.

This particular design sprint drew a variety of challenges, many of which were self created.

My main goal for this project was to accomplish a game that required one main scene for playthroughs. I added more and more tasks and challenges to test my knowledge of the GDevelopment Game Engine for the sake of my own education. This was very important during this sprint as the next sprint requires group work and I wanted a stronger understanding of how to accomplish different mechanics.

Though we only needed to create a game where obstacles were drawn from one directiona nd closer to the player, I chose to go beyond that brief and introduce multi driectional ‘racing’, from this, I feel I accomplished that.

From the playtesting, I strongly feel I hit many of the goals outlined, whereaas some went a little unnoticed.

What I’ve Learnt

How to create npc interactions

How to use one sole map with ‘events’ triggers

How to create a ‘shop’

Multi-directional animations

Improved character selections

How to use forces to steer npcs along paths

Keeping tidy readable ‘code’

Improved title screen with bouncing camera

Artists are still key to any project!!!

Global Variables

How I Took Feedback From Playtesting

Again, my goal over the course of each playtest is to not only take the feedback of the current sprint, but to incorporate previous comments into each descendant project.

Some areas of improvement are still required such as control layouts and general GUI improvements as well as testing absolutely every possible thing, no matter how small. Some areas overlooked where addressed which is really helpful for ongoing development, like pathway corner hitboxes and how npcs and players get caught.

The feedback I received this time around was far less then previously which indicates I have taken on many comments and improved them. Very happy with progress made.

Final Version

Due to time constraints, I am unable to continue this project in the near future, however I will update it when the semester ends.

The current version can be played here;

https://games.gdevelop-app.com/game-f625e2e8-3a15-47ca-bbd0-3ea2a32aecdf/index.html

In Conclusion

Development was challenging for one person, on top of time constraints, but this particular project I am very proud of the output and it is reflected in the project itself.

Until the next design sprint!

#qut #gamedevelopment #ogresrun #postmortem

Trending Blogs

Recently Viewed Blogs

Jamie Renfrey