Design & Prototyping
Design is mainly having an eye to improve the game experience, in addition to constantly finding flaws that could bring a better impact the player, while keeping a balance to showcase the key areas which are noticeable to the players at certain moments. This is one of the reason games in general are known for (especially video games). The process is iterative- starting with discussions (initial ideas then gradually features), building prototypes, improving them, incorporating in the game and playtesting till it conveys the design goals. The two main design goals of my game are fast-paced gameplay and generating an interest about space. Components like analyzing interactivity, aesthetics, level design, game mechanics, character design have been core to the game for creating an experience. Using white boards and papers were key during discussions to convey our design goals. To build around aesthetics a theme was important for each level. Preparing the information about surfaces was a task in initial weeks and building them in game as prototype was important to represent the initial idea. .
Aesthetics as given in 'The Art of Game Design: A Book of Lenses' by Jesse Schell talks about many questions that are fundamental for building experiences and its significance to create memories that stay with the player. The book talks about examples like the famous space invaders, the spaceship looking character was made out of few pixels and felt personal to the players with the right fit of gameplay and player control. In those times, the hardware was not advanced compared to the current generation and resources were limited. The missile explosion attack on aliens were few pixels that looked like animation (transformed as sprites overtime for pixel art using GPUs). This was complimented with sound that provided as a feedback to the player and caused mainly- engagement with the character (spaceship) through interaction, gameplay and control of the device. In addition, the score and lives supported as layers to the overall theme of the game. In Space Ball Jump, a similar practice is made to convey the idea by having each level as a theme.
Design in another perspective is observation of our surroundings and tweaking them in game to create information as intended. In our game, upon discussion we came up with an idea to modify the transform of the actors based on the camera perspective during the gameplay. This way it would create an illusion of travelling around the planet and capture the scale (signifying the size of the planet compared to others and the Sun). Keeping in mind the camera system was decided to be kept as perspective, which would mean that the world would be viewable in 3/4 scene and the impact on the players was limited on time. It would also mean that other areas of the world would not be required as resources and they could be used for garbage collection (handled by destroying actors in UE4 C++) to optimize the game. Next step was to build around the theme of Mercury- knowing the history and building objective around it. Meteors being a probable cause of craters on the planet, the game features destroying them to unlock a collectible. We hope that it will generate a sense of achievement and satisfaction as seen from the common trends in video games to unlock extra content like collectibles, skins, characters etc., this would additionally improve player skills in unique and challenging ways.
Fig 1. Early design ideas to traverse around the planet.
Fig 2. Earlier level design versions of platforms- progressive patterns to increase difficulty of the level with taps.
Games (in general) could also be viewed as solving problems and binding with a sense of achievement. We train our brain (neurons) to achieve a task. For example, everyday jogging makes us better compete at marathon and it is a form of satisfaction to achieve a set target. It is very well discussed by the author --- in the book --- of chapter ----. In video games, the challenges are distributed through various components of the game like completing a task through set level design. To have an excitement, adaptation and training were crucial to our game and have been the key points for many games. It makes sense as a tutorial helps to familiarize with controls, keeping in consideration the interactivity of the user with the device. Tutorial is a step to build upon gameplay and extend the imagination of the player in the level. It depends on many ways to introduce a tutorial to the player, few of them are:
- A tutorial level. Considering the lapse time reduction of the player from start of the game to gameplay on mobile device for hyper-casual genre games is less.
- Another approach could be to introduce a text overlay during gameplay (Temple Run).
- Upon research games like God of War, Shadow of Mordor, Legend of Zelda: BOTW etc., use a different approach to tutorials by adding a moment of delay to capture and encourage the player in performing the command during gameplay while conveying the tutorial message. Additionally, saving resources.
The same study (point 1) also shows that tapping has better response than swipe commands on mobile devices. So, it would also mean that (as mention by author ----) tapping is essentially more effective to train our neurons and this would imply to train them much effectively, improving our skills to get better. This led us to lay the fundamentals in terms of level design for the game. Games like Ball Jump on Android & iOS deliver a similar strategy as a hyper-casual game by having probably a procedural generated algorithm to place the tiles. On the other hand games like Terraria, Minecraft etc., on Android hold a theme which is much deeper compared to the styles in hyper-casual genre, that uses a randomly generated algorithm to add uniqueness to the gameplay of the level. If the player knows where the assets are placed then the neurons would get trained to anticipate the next move, which would void the idea of unique gameplay. To add random generator to the platforms it was important to establish few scenarios where we could extend the gameplay difficulty for the player through level design (Fig. 2) and build upon the theme of exploring space (Fig. 1). Next step was to analyze the areas where player had to make a particular decision and act accordingly. For example, jump to a higher elevation would sometimes require double jump and that would cause the player to make two subsequent taps. So, it would also mean focusing the energy of the player where it would be worth as an achievement. Some of the instances where a player could consider to make decisions (Fig. 2) are:
(1) Single jump to jump on the subsequent platform. This would be considered a semi-medium difficulty mechanic.
(2) Double jump to land on a higher platform. It could also be a single jump to reach a higher platform and gravity could in a greater influence.
(3) No jump. Players land on the platform which is placed below and it would not require any action from the player. This approach could cause an important decision making where players would tap and not realize that they were not supposed to. The intent is not to jump (or jump in some cases if the platform below is not feasible to land) and the player would improvise their tap skills with every subsequent retry.
(4) It is a hybrid of second and third point. This approach would provide the player with two options that is thought to be challenging as it will be a momentarily decision.
(5) Starting from this point, the difficulty gets harder by making the player have less space to relax. The first action would make the player tap once and the second action in time-frame of milliseconds would have the player tap the second time to reach the third platform, which could be either of the three options- a hybrid of first, second and third points.
(6) This step would allow the player to make decisions when the platforms are not in view. The approach would be unpredictable until the platform before it is reached by the player. It would be in that split second, the collision box would trigger the subsequent platform to move in view with a smooth and blended motion.
(7) The approach is a hybrid of sixth and fifth points. It would provide the players to make repetitive tapping decisions without the platforms in view causing them not to anticipate their next move until they reach the platform placed before the next one.
(8) The pattern would trigger the forthcoming platforms that are placed contiguously on the same coordinate axis, the key is that the player might expect few of the platform to appear over a certain distance but they will be placed in a contiguous manner. The instance would expect the player to not jump.
(9) Expanding on the fundamentals to convey elements of the planet with a theme has been considered as a pivotal design pillar and the approach with this point is considered to introduce some of them through as a game mechanic. The elements could be placed as hybrid of above points except the platforms which are right below the player for the player to not jump (as in the case with point (3)).
(10) While many of the above patterns were in place, the idea to expand the levels with shapes would make more sense if the player would have a prediction of which side to choose to follow the shape. Eventually, either of the directions would lead to a common platform. One possible way to showcase the patterns could be through an introductory sequence when the player starts the game.
Alongside discussions for design on paper prototypes were created, building and prototyping the assets was crucial at an early stage for optimization. Having taken courses under expert guidance of few faculties at RIT, GDD, the knowledge helped practice the requirements to create assets for the game. The assets were mainly divided in categories like textures (size?), materials (some through textures and some using built-in functions of Unreal shader system), models (verts and triangles? ideally it would not be more than 200 verts which are at a further distance depending on the asset) and the tools required to construct. The external team comprised of two people who took excellent care of the platform models for the first two levels (Mercury and Venus) and materials individually. Some of the assets used in the game are also supported by creators through Epic Marketplace (mainly UI and few sprite textures from Infinity Blade pack for Android). The early prototypes made for the game are shared in (Fig 3, Fig 4), that were incorporated to bring a look and feel of the environment. Additionally, web platforms such as NASA helped provide textures for the surface and create materials that are part of the level. The websites have also provided us information to the ideas that the game have been trying to achieve- expanding as an insightful reference to level design- platforms, objectives, collectibles, currency and extra methods that have information about space. The tools that are used to build the project are:
- Unreal Engine 4. To convey the imagination of exploring space and generating an interest by pushing the graphics on mobile platforms. The idea to show the realism of space could only be achieved with the power of Unreal Engine 4.
- Maya (support with UE4 Link is super helpful to edit assets on the go). The platforms were initially designed to represent the surface of each planet. In Fig. 3, the idea had been to showcase the platform models with lava materials (texture alpha blending, similar to planets materials), for planet Venus, as the planet Mercury is the first planet, early prototype versions included different version testing of models and their size output on mobile devices.
- Substance Designer to create materials to be used on the models. While the models were created, use of substance designer helped create materials with base, normal and some metallic maps (skins). This was an added iterative process over model creation. Some of the instances could be faked using normal maps (based on light falling to the model), for example, craters could utilize more verts in Maya, while the same effect could be achieved using normal maps made using Substance Designer. The software utilizes a similar shader pattern as used in Unreal Engine and is used as an industry standard.
- Another great tool is Substance Painter that helped modify the exported maps to materials from the Substance Designer. A practice artwork could be noticed by unlocking the collectible of a comet in-game, that was created and edited with the help of the above software.
- Version control was supported using GitLFS and then switched over to Perforce (using free AWS server) for various reasons like compatibility with UE4 environment and file storage architecture. However, due to constraints like internet connectivity in some locations the project was gradually switched over to external physical hard drives and as the project is indie it was enough to not add extra work as a single person.
- Adobe Photoshop to create various sprite animations that are used for materials in UI and other levels. Additionally, it was used to create alpha blend PNG textures for materials on planets, UI related locations and font generation.
- Few Android devices which could be affordable for testing purpose. However, UE4 emulator for Android is sufficient enough to support the result of development.
- Visual Studio IDE for C++, Android related packages to run on the device, licensing on Google Playstore and data (using Google analytics) to improve the game.
(a) Adding meteors, revolving around the planet and testing platforms. In this one it was supposed to be see-through model for the platform used for planet Venus later.
(b) Initial version where the platform model is without materials and represent cold regions of Mercury.
Fig 3. (a) and (b) provide an insight into prototype version and the result from the above paper prototype versions of the game.
Fig 4. Various level design patterns in early prototype stage without optimization.
Soon limitations of the device became a big constraint and the need to support random generator was further made by an object pool. An object pool provided instances of the mesh objects when needed and when not needed. In addition, it acts as an independent system to accommodate resources as intended. For example, pickups and related elements like meteors are a part of the random generator that could be easily adjusted and modified as the algorithm gets complex. Additionally, incorporating more elements to the level design and creating further interesting moments in the gameplay was made convenient with the help of an object pool (supported by UE4 C++). The version in Fig 4., is an unoptimized version of early prototypes that were usually hard for a normal player to introduce as the first level. The prototypes were essentially used as a reference to create easier levels with less time for development. As seen in Fig 3, they are an improved and easier version as part of the first level. Few areas like building around a better theme by changing the object movement in the scene (create an effect of travelling around the planet and represent the surface), meaningful platforms, better objectives, optimization and easier gameplay.
The author of the book “Interactive Stories and Video Game Art : A Storytelling Framework for Game Design” talks about breaking down player’s emotions that are related with storytelling using basic shapes like circles, squares and triangles. The interaction with these shapes is universally accepted with a psychological behavior that could be inherent around us in everyday life. Shapes define an abstract form of emotions that our brain interprets and associates as feelings. A circle represents innocence, youth, energy, movement, positivity, freedom and relaxation. While square represents maturity, balance, stubbornness, strength, rest, restrain, rational, calm and conservative. Whereas, a triangle is effectively aggression, force, instability, pain, sorrow and tension. Simple shapes have also been universally accepted based on real-life experiences, and is an excellent example in our game. The planets and the Sun cover a large portion of the game world that the user would be able to notice- showcasing space as a design pillar. As these objects in real-life are almost a sphere (or oval in real-life, which is another version of a sphere) and create a theme together in each level, having a character that resembles close to the shape and theme of the levels was thought to create a certain effect. Highlighting the attributes mentioned above about the perseverance of a circle as a shape and while the universe is known to have mysteries- it made sense to have a sphere as a character and establish emotions that could be correlated as a common shape with other objects in the environment.
A character is the control given to the player through the device and player interacts is translated through gameplay. The control is fundamental to experience the design and world built by the team. As a sphere does not add extra expectations because of its form, the next step would be to translate a smooth experience on mobile devices especially as the gameplay is fast paced for hyper-casual games on mobile. The DPI touch response was noted for the Android devices, this needs to be prompt when the user taps on the device. This is also achieved with optimized gameplay in terms of level design (object pool).
Player movement and the response to camera system was important for traversal around the level and are further binded through player interaction with the device. Reflecting back to the fundamental design approach of progression for example as seen in games like Super Mario Run, Robot Unicorn II, Space Impact (Nokia), etc. had limited player control and provided short term experiences of being rewarded. The player movement was limited to one direction and this led us to build prototypes around the space idea with a background of exploring space. To make the level challenging it was important for the character to interact with different components to support the overall design. Few of those components are device input, camera system, objective elements (elements of the planet's surface like destroying the meteors), platform colliders, tutorial collider (slow-mo effect in beginning of the level), end level collider and other actors in the world that play an important role. Considering the gameplay approach led by the trends in the above games, the character's movement in Space Ball Jump is constrained to one direction and the player's only goal is supposed to focus on the timing of taps they make when the ball is in contact with the platforms and in the air (for double jump).
The idea of single jump was initially part of the design, after helpful playtest feedback a double jump provided a second chance to the player during the moment of reaching to the safe platform during game play. Additionally, a double jump keeps a balance in terms of difficulty and once the player has learned the mechanics by trying multiple times, they build a level of intuition that further causes anticipation to explore the level. A goal is the final destination while objectives are mini goals based off the main goal i.e. to complete the level. The main aim in Space Ball Jump is to complete the levels and objectives like meteors are mini goals. Connecting the point of having each level with a theme, the objectives revolve under the same idea based on the elements of the surface. While meteors are imagined to have an impact of blowing in space, the game mechanic of double jump links to conveying the idea and create an explosion when in contact with the meteor (Fig 3. (a)), the way it would have probably been years ago for Mercury. Another aspect in consideration is the visual feedback when they perform the action to double jump. As the action is a form of thrust given to the ball in one direction, one of the common effect is using smoke particles from the rear back of the character to generate a sense of push being given in space, and it is applicable as thrust is needed for engines to fly rockets out of the atmosphere- supporting the theme of the game. The trick was convenient with attachment of emitter actors to the character when it is used for double jump (communication between Unreal emitter system and character C++ class).
Currency in video games cause a sense of ownership given to the player (the way it would, with money) off which they could utilize to progress in the level, unlock extra content (aesthetics- skins, character), and other areas to support design. Mario is a great example to use coins as their currency- a trend used in many games. Similarly gems are also known to be used as a form of currency for example in BOTW- the sole purpose of using gems is to sell them and earn smaller gems (i.e. the real currency) which could be further used for different reasons (aesthetic and non-aesthetic purposes). A gem's appearance as an object that is worth collecting must appear like one too. From the main menu, the design of the gem was made to look attractive by adding a touch of gradient shadow falling on it from the Sun with sprite effect to show rotation animation. While in main level, the gems are represented with a 3D form and has a theme supported with particle effects that are triggered when the objects are placed in the scene and instance when player hits the collision component i.e. the gem. Many mobile games use a trend to provide free bonus currency points for starting the game, while Space Ball Jump tried to use a similar approach by rewarding players with fifty gems for opening the app for the first time. During the main level, player death is supported with the use of gems as each time ten of them are used to retry from the beginning. The penalty to withdraw their precious gems also means that they would have to improve their tap skill and not die! However, it would be hard not die without subsequent multiple tries and if in case the player has zero gems, then they could watch a reward ad and earn twenty gems along with retrying again the level. This technique is very common in many games like the famous Candy Crush Saga where the rewards are provided by watching an entire ad, which in turn helps the developers as well as the client advertising companies. While the instance where player could run out of the currency, it was necessary to provide them sufficient amount in the beginning of the level where the outcome is less likely that they will die. Additionally, looking back at the level design concepts- it was necessary to provide the player enough breathing room to have a first look at the level and introduce them to game mechanics. This led to the decision of landing the ball on simultaneous multiple safe platforms for longer duration of times. At the same time, the idea to combine a slow-motion tutorial with gems seemed logical as the player has more time to grasp the control and collect the gem at the same time. In another case, the player might choose to double jump over the gem and have no gems at all, which going back to the point of using ad made sense, although, one might question that if there is no internet connectivity then there is no way to earn gems? In that case, the player would have to choose the 'Home' option and load the level again. Although, the last case has less probability because the player would most likely collect in that moment, than run over it and lose all the gems to zero, in addition to having no internet to run the ad.
To extend the concept of currency with the player, customizing the character was essential to feel a personal relation by unlocking skins to the ball. As the concept's purpose is only meant for aesthetic on the PC, the part to lose the gems is significant to earn more gems and unlock more skins. This would also mean that the risk to earn them would hold more value to the player and it will also encourage the player to improve their skills through gameplay. It was important to have a nice and feel of the skin on the character and like in many (almost all Nintendo) games, there is a 3D representation of the object having the desired skin that represents the result. Similar results of representing objects in 3D space on mobile device provided a different perspective of interaction over the platform. This can also be seen through UI elements, as the theme to represent the solar system- planets and their surfaces were observed and a similar representation was attempted by rotating planet around the Sun. As a mobile screen ratio is relatively small, it is logical to represent the objects in UI vividly while covering all the regions of the object in that moment. For example, if the craters or shape of the comet are not represented then it would lose the concept of achievement (Fig. 5) (when the three meteors are destroyed in planet Mercury). At the same time, to establish a closer relation of the character with the player during gameplay it was important to show the reflection of their chosen skin in UI. This way it is hoped that player will anticipate an interest towards collecting more gems through gameplay and unlocking more content (Fig. 6). Additionally, the whole process of using currency as a tool would increase play time on the game and keeping the scope of the project small for a short experience, it was convenient to achieve within the system as an early access prototype version for Google PlayStore.
In addition to the collectible being informative, the skins menu has been designed with a theme of space in mind. The first layer consists of simple colors that could be applied to the ball. The second layer has been designed using Substance Painter with their UVs, with an idea to have AI in space. The third layer represents retro times of using the ball games like bounce, classic pinball etc., along with following the lines of representing space aesthetics through character in the gameplay. Analyzing the behavior of the player during the time of their on the game is crucial to improve the game. Players would usually jump directly into the gameplay or main level and focus their attention on the ball. To facilitate the concept of representing the ball as skins, the focus remains on the the ball through UI and provides a closer look following the same pattern of keeping ball as the main player character focus in terms of visual attention. Additionally, the interest to know about space could be overshadowed during the main level as the player's eyes would be focused towards the ball, while collecting gems and collecting elements of the space. Main menu in the initial concept stages was designed around representing the solar system as buttons on planets. As a result of camera panning towards the planet as a cinematic effect of zoom. The concept to select a planet was supported based on the same mechanic- player selects the planet and it pans bigger and closer to it, it is the camera that moves closer to the planet in 3D scene while representing the same in 2D UI space. This could be controlling the time it takes to travel to the destination and returning back when the player touches the 'Back' button. Representing Mercury's atmosphere and environment was relatively easier as it barely has one, however, for other planets, it became important to showcase the details and nuances of their surfaces in order to signify their value in the solar system orbiting around the Sun. The technical aspect to represent the planet's details was supported by alpha blending generated using tools such as Adobe Photoshop to generate the pair of texture maps and swap them using controlled parameters in Unreal shader system. Another important aspect had been to keep the texture of relatively lower resolution (about 512x512px max) as the shader would have to compile them as materials in 3D space on the models. The design system also supports switching cameras and focusing on the objects (skins and collectibles) while changing UI menu systems to represent the entity. The first level or main level consists of objects in space with a 2D cinematic camera traversing over planets and representing a closer look in UI (as mentioned above for Mercury). This would also mean that moderate use of UI elements was important to showcase as the renderer could only support a limited number of resources until they are sent for unload and more resources could use the memory space. A design approach could be to have multiple UI systems containing their own behavior (like buttons, animations etc.) and using them overtime when necessary according to their usage keeping the resources feasible for the system. Upon prototyping, it was realized that objects (planets) with default scale at a certain distance from the UI camera were projected differently in 2D UI. While reflecting back to the point of interaction for Android devices, setting an estimated DPI scale helped represent the modified scale of planets. The reason to place the objects over a certain distance from the 2D UI camera is because it would represent the size of the planets in relation to the Sun. As the idea to represent the sunlight (the Sun being at left-extreme to show the bigger scale compared to planets) falling on the planets was supported by using a directional light in the 3D scene and the planet's scale and location were adjusted accordingly (Fig. 9). While Unreal's documentation specifies the constraint of using one moving directional light in the scene for Android devices, the gameplay level's one directional light (attached to the planet actor) is rotated as the Sun moves away in the scene behind the player, representing the concept of sunlight falling on planet's surface while the player rotates around the planet. The same extend of effect could be seen on the platforms as the light falling on them changes overtime as the player character progress around through the level. However, as seen in Fig. 3, it was harder for players to notice the platforms when the planet was faced on the dark the side towards the player character. In that case, using a point light at certain instances and then iteratively analyzing precise moment during gameplay where there would be no use of point light and direction light would replace the need of sunlight falling on the platforms. The point lights functionality had been to highlight the bottom surface of the platform while the top surface transitions with directional light from the planet. It was crucial for the player to notice the transition over the platforms as the focus would remain on the ball and platforms.
Main menu holds a significance as it represents a coherent theme of space. While the idea to precisely represent the size, surface and order of the planets in presence of the Sun, it was important to highlight the significance of Sun by adding flares of lava splunging from its surface. Much like using materials for other purposes, a similar approach could be used for UI materials as well. One approach to achieve flare effect is by using a flipbook (sprite transition) in UI widget as a material that could be overlaid on top of the Sun image. Another idea to capture the flares on the regions of surface (image) where sunspots were prominent is by creating an overlay of flare materials on those areas bringing a subtle effect of flumes splunging from the spots. As the space is silent but also violent at times, Sun flares provide a fast-paced effect and Sun’s outreach compared to other bodies in space, while planets add a calm effect by rotating their materials slowly on the mesh and representing their surface behaviours. Additionally, as space comprises shooting stars, the initial concept involved having a dynamic background on which all other elements like planets, Sun, buttons etc would be an overlay on top of it. To achieve the effect, textures are panned overtime (loop) in the UI material that results in highlighting regions of the textures in diagonal direction. At the same time it was important to quickly start the level and dive into gameplay for the players on mobile devices. The key had been to keep it simple while representing the theme and reducing the steps it would take for the player to start the gameplay and access other menus. Beginning with the first screen of main menu, the player would tap 'Play' which would lead to 'Select a planet' and on selection, the camera would transition closer to the planet and have a bigger focus (representing the atmosphere and surface). The next step is 'Tap to start' on the selected planet. In the process, selecting the planet and focusing on the details of them was important to support representing space when the player starts the level in a small amount of time. If the player decides to go back to the previous screen ('Select a planet'), in that case previous UI elements are returned and the camera moves back to its original position (representing other planets). Else if the player stays on the page then they could read objective of the level and have a look at the state of the collectible (locked or unlocked). To show the other side of the solar system, the player would have to tap the 'next' button in 'Select a planet' screen and camera rotates towards the other side of the world screen space, while returns to the initial setting if the player would like to return back to the previous planets. In the meanwhile, providing a background music would enhance the experience in terms of aesthetics and the supported theme to represent space. The main menu was thought to be made as mysterious sounding with similar effects (using reverb and delay) creating a notion of surprise in further levels. The anticipation and excitement was supported largely by background music to generate an interest about space.