Welcome to my development diary! Here you can see weekly updates on the personal project I am currently working on. My current project is Pixel Fixer (working title), a puzzle game based around a pixel based crafting system.
Entry 08 – 18/03/20 – Test Reflections: The Good, the Bad and the Ugly
It has been a while since the last entry due to a range of factors including work, a wedding and the global health situation, however we have finally built and tested an example level to gauge the primary game loop. The level consisted of a three tasks where the player had to break down junk around the shop to fill in missing furniture before the time ran out. While the scoring wasn’t implemented the clue system was functional; giving players a riddle to solve (answered via text box) which would reveal the breakdown requirements for the puzzle. Due to the aforementioned issues testing was relatively unstructured with 13 tests across mobile and PC builds. The insights of this testing is discussed below.
The positives we found from testing is that the core concept of pixel based crafting is intuitive and engaging for players, and that the concept of a point-and-click puzzle adventure game on mobile is a promising concept. Furthermore players enjoyed the world concept and the narrative, although this was presented to them as a text opening to the test level.
Opportunities for improvement identified during testing included expanding the layout to include more objects to breakdown (without impacting screen density) and replacing the bar-based GUI with a menu based system supported by contextual elements. Players also indicated a desire for more interactivity with scene elements as well as a general increase in dynamics in the layout.
The primary lesson we learned from this process is that the riddle based clue system requires a major restructuring. The process of typing in answers was problematic and players weren’t typically motivated to engage with the system. Before expanding on peripheral mechanics and developing levels we will have to find a new method of players acquiring crafting recipes. The next entry will contain a more in depth discussion on this topic, however given the current situation for myself and Matt (my development partner on this project) we don’t currently have a solid structure of development milestones moving forward.
Entry 07 – 24/01/20 – Making a Test Level
A quick aside for last entry, where I was looking into potential GUI layouts. As previously mentioned priorities for the new layout will be to minimise occlusion of the scene that may prevent players from seeing things in complex/detailed backgrounds, or being unable to select them though touch interaction. The current placeholder system, pictured below, uses an information icon to expand the selection indicator and removes the need for a top bar. For the test level it is likely the lower bar will still remain to simplify testing however when the art style is finalised additional minimisation could be explored.
Now that players can break down and create items it was important to test the primary loop to see if this concept has potential, particularly when played on a mobile device. To do this we are going to produce a basic level which will then be sent around to some testers for initial feedback. The level will consist of some simple text boxes to open the narrative and context, and then three to five puzzles for the player to complete. As the riddle system is not yet implemented a scoring system will be manufactured by timing the player’s completion of tasks with penalties for any left over pixels in the player’s supply at the end. In terms of narrative structure we will most likely use the premise that the player has to clean up and prepare their lab before opening for business, cleaning up and replacing broken/missing items. This will make use of mostly test assets but some other speciality and periphery items will fill out the scene.
Due to the upcoming Global Game Jam and some other commitments we are aiming to have this done by mid-February (potentially a Valentine’s Day release). If you are interested in trying out the test level feel free to email me for details.
Entry 06 – 07/01/20 – New year, new GUI
Happy new year everybody and welcome to 2020. Now that the holidays are over I am getting back into the developmental swing. With the primary loop finalised we are now looking at nailing down some of the major questions identified in early development of the POC. The two main questions surround what kind of pixel art will be used (at least for the first test level) and what kind of GUI layout we want to employ.
In terms of testing the art-style the plan is to produce two similarly structured scenes in a range of pixel art styles, from here we will compare and contrast them to see which would be best to be employed. To streamline this process we’ll use some of the existing test art assets however others will require revision.
The current GUI being used, dubbed the cinematic style due to the use of black bars above and below the game scene, has been useful for initial testing but does not appear to be the best solution for a mobile platform. To maximise the limited rel estate on mobile screens the plan is to move to a temporary overlay triggered by a button in the corner of the screen. Some information will also be contextually depending on the phase of the primary loop the player is in. This coming week I will be looking into implementing some prototypes for different GUIs for comparison and refinement.
Entry 05 – 15/12/19 – Not much to report
This week as been a bit slow for Pixel Fixer on account of other commitments, including both Matt and I participating in the Yogscast Jingle Jam.
Most of the progress this week came from laying the ground work for the control functionality, including a side scrolling element which will allow us to present bigger and more substantial levels without overly dense layouts that would be difficult to navigate with touch control.
Entry 04 – 08/12/19 – Refining the primary loop
This week the focus of the project has been to refine the primary loop exhibited in the proof of concept build with placeholder assets. This is so that the implementation of other critical features, such as the riddle-based clue/hint system and the GUI layout.
While Matt is taking the lead on visual assets for this project, due to his prior commitments I produced a set of placeholder assets for the use of testing. These assets also serve a secondary purpose in testing the concern of my friend that 16 bit sprites would be a poor choice for depicting the fantasy aesthetic from the side-on perspective. This question is particularly important as the construction of the sprites is a fundamental element of game-play, as players need to understand how many pixels of each colour they will be receiving from breaking down that sprite.
The sprites made for this testing included a sword, jar, skull, helmet, forge and wall-mounted candle, in addition to three types of flower and potion vial.
Testing and discussion is still ongoing about the art style, however this build also features fixes to small issues such as the tracking of pixel supplies being bugged, the instantiation of new sprites returning the wrong prefab from the array and selection issues when clicking away from the game window.
Entry 03 – 01/12/19 – Defining the scope of the project
While developing the proof of concept build I spoke to a friend, Matt Burgess, about joining the project in an art and narrative design capacity. During our first meeting we began to nail down the scope of the project, from which we will derive key milestones and from those build a developmental objective tracker.
The idea would be a series narratives set in a fantasy with a consistent protagonist. The player would take the role of a wizard who is paid to make prophecies about customer’s futures. Unfortunately the wizard cannot predict the future and must then work behind the scenes to make his prophecies come true, and stay in business.
The game would be structured around these narratives, with a number of chapters divided into multi-objective puzzles that progressed the story. In each puzzle players would have to produce an item to solve the problem, the item (and pixel requirement) would be hidden behind a riddle that players can solve by typing in an answer. A time limit would be set for each puzzle and players would be scored on their time, and penalised for any extra pixels they have left over. The game would be developed for mobile, with game-play and progression would be designed to fit into mobile gaming behaviours (short play sessions, limited inputs).
Entry 02 – 24/11/19 – Proof of concept build
I developed a build to test the game-play feel of the pixel based crafting concept, and to see what kind of broader game play loop it would suit. I developed the concept in Unity 2D, testing with PC and iOS builds to gauge the best input medium. The initial test build consisted of a single pixel type, with a basic ‘world object’ cube in a scene with a button to create and a button to dismantle. Clicking on the object would highlight it for dismantling, a method that played particularly well on the iOS build.
No major issues were encountered during this build, as the concept is quite simple variable management and button management.
Testing this build gave me a better idea as to the broader game-play loop that could accommodate this mechanic. Rather than going down the typical open world survival loop I thought the system would work well as the basis of a point and click adventure game. Rather then using mini games or inventory puzzles the player would have to produce key items by breaking down items in the scene. Given the simplicity of this loop developing for mobile seemed the better route as it could easily be engaged with through that controller layout, and the low-poly pixel art style required by the central mechanic would be more forgiving on a smaller screen.
Entry 01 – 17/11/19 – Pixel based crafting
The idea for Pixel Fixer came from a conversation with a friend about crafting systems in survival games, specifically about how these systems often gradually become less logical as more complex items need to be developed. For example, crafting systems may start with a piece of wood and stone making a hammer but eventually progress to two screws, some scrap metal being used to make an assault rifle. From this idea I began to think about different ways of conceptualising a combat system, which led to a pixel based approach. The pixel based approach, as the name suggests, is based around items being constituted from the pixels that represent them. Players can break down items to collect their pixels, then use them to craft new items.
Since the concept seemed promising I decided to make a test build to see if it plays well, before thinking about a broader loop.
Andrew Stewart - Game Designer 