Tech Guides - 2D Game Development

We have moved lightyears away from the the handheld gaming days. The good old Tetris and Mario games were easy to use, low on graphics, super difficult to program in-spite of their apparent simpler appearance. Although it’s difficult to trace back to the language in which all of these games were written, many of them were written in the C family of languages, which contributed to the difficulty in programming them. Rust has been touted as one of the successors of C. Which in-turn brings the question back - if C was difficult for coding, then how exactly is Rust going to be different? The answer of this question lies in the approach of Rust. Rust was designed primarily as a systems programming language by the Mozilla Foundation. The primary game development language over the past 20 years have been C/C++ majorly. Rust brings a fresh change in approach - from Object Oriented to Data Oriented. The problem with object oriented programming was summarized nicely by Catherine West from Chucklefish. According to her, treating game elements like NPC, game worlds, as Objects might work well at a small level. But when you are trying to create your own game engine, then treating game elements as Objects will imply creating a lot of super sized objects with complex layers of dependencies. The Rust approach, on the other hand, is data oriented. This implies that every element is treated as data. This simplifies the process of creating midsized game engines a lot. Chucklefish being a significant name in 2D game development, this statement from Catherine West comes as a major boost for developers who want to use Rust for developing 2D games. She has although expressed her doubts on using Rust for 3D game development. Another important personality who has recently come out in support of Rust is Andrea Pessino -  CTO of Ready at Dawn. Ready at Dawn is a well established game studio known for games such as The Order: 1886, Daxter and various God of War titles. His tweet read like this. This is another feather in Rust’s cap for game development. The present state of game development in Rust is quite encouraging. There are quite a few low level graphical libraries like GFX.  GFX is a low-level abstraction layer over platform specific graphical interfaces (OpenGL, Metal, Vulkan). It offers some handy wrapper over windows backend (glutin the Rust one, or wrapper around Vulkan system, GLFW and more). GFX is still at a very early stage of development with the present version being 0.17. Although major game engines like Unity, and Unreal are yet to support Rust for game development, there exist a few complete game engines which allow you to create complete games with Rust using their framework. The first one is Piston. It is the oldest game engine for Rust. It is also the most stable and one with great documentation. However, many people find Piston confusing and hard to use as it is super-modular by design. Sometimes it is even hard to understand which module to load for achieving a certain goal or build a certain component of a game. Amethyst is a more recent game engine/framework inspired by commercial monolithic game engines. It comes with all the necessary dependencies in its package. However it is evolving quickly and hence the present documentation is already outdated. However there is a vibrant community which is looking to include more and more developers into its foray. Hence this gives an opportunity to new developers to get into game development with Rust and get involved with a game engine also. GGEZ is a simple 2D game engine inspired by the LÖVE engine. This library is more suited at creating simple 2D games for hobbyists. GGEZ is also very new and changes quickly. The design simplicity is an incentive for indie developers and hobbyists to start creating games with it. Some other popular libraries include: noise-rs / a noise generator rlua / High level bindings between Rust and Lua sfxr / Reimplementation of DrPetter’s “sfxr” sound effect generator as a Rust library The conclusion that we can draw from here is that Rust has a lot of promise when it comes to game development. With the data oriented approach, easy memory management and access to low level performance enhancement techniques, Rust can become a full fledged game development language in the near future. Best game engines for Artificial Intelligence game development Implementing Unity game engine and assets for 2D game development How to use arrays, lists, and dictionaries in Unity for 3D game development

Imagine a watch without a watch face to indicate the time. An interface provides important information to us, such as time, so that we can make informed decisions. For example, whether we have enough time to get ice cream before the movie starts. When it comes to games, the User Interface (UI) plays a vital role in how information is conveyed to a player during gameplay. The implementation of a UI is one of the main ways to exchange information with the player about moment-to-moment interactions and their consequences (for example, taking damage). However, UIs are not just about the exchange of information, they are also about how information is provided to a player and when. This can range from the subtle glow of a health bar as it depletes, to dirt covering the screen as you drive a high-speed vehicle through the desert. There are four main ways that UIs are provided to players within a game, which we will discuss shortly. The purpose of this article is to prime you with the fundamentals of UIs so that you not only know how to implement them within Unity but also how they relate to a player's experience. Toward the end, we will see how Unity handles UIs, and we will implement a UI for our first game. In fact, we will insert a scoring system as well as a Game Over Screen. There will be some additional considerations that you can experiment with in terms of adding additional UI elements that you can try implementing on your own. This article is a part of the book titled "Unity 2017 2D Game Development Projects" written by Lauren S. Ferro & Francesco Sapio. Designing the user interface Think about reading a book, is the text or images in the center of the page, where is the page number located, and are the pages numbered consecutively? Typically, such things are pretty straightforward and follow conventions. Therefore, to some extent, we begin to expect things to be the same, especially if they are located in the same place, such as page numbers or even the next button. In the context of games, players also expect the same kinds of interactions, not only with gameplay but also with other on-screen elements, such as the UI. For example, if most games show health in a rectangular bar or with hearts, then that's something that players will be looking for when they want to know whether or not they are in danger. The design of a UI needs to consider a number of things. For example, the limitations of the platform that you are designing for, such as screen size, and the types of interaction that it can afford (does it use touch input or a mouse pointer?). Physiological reactions that the interface might give to the player need to be considered since they will be the final consumer. In fact, another thing to keep in mind is that some people read from right to left in their native languages, and the UI should reflect this as well. Players or users of applications are used to certain conventions and formats. For example, a house icon usually indicates home or the main screen, an email icon usually indicates contact, and an arrow pointing to the right usually indicates that it will continue to the next item in the list or the next question, and so on. Therefore, to improve ease of use and navigation, it is ideal to stick to these or to at least to keep these in mind during the design process. In addition to this, how the user navigates through the application is important. If there is only one way to get from the home screen to an option, and it's via a lot of screens, the whole experience is going to be tiresome. Therefore, make sure that you create navigation maps early on to determine the route for each part of the experience. If a user has to navigate through six screens before they can reach a certain page, then they won't be doing it for very long! In saying all of this, don't let the design overtake the practicality of the user's experience. For example, you may have a beautiful UI but if it makes it really hard to play the game or it causes too much confusion, then it is pretty much useless. Particularly during fast-paced gameplay, you don't want the player to have to sift through 20 different on-screen elements to find what they are looking for. You want the level mastery to be focused on the gameplay rather than understanding the UI. Another way to limit the number of UI elements presented to the player (at any one time) is to have sliding windows or pop-up windows that have other UI elements present. For example, if your player has the option to unlock many different types of ability but can only use one or two of them at any single moment during gameplay, there is no point in displaying them all. Therefore, having a UI element for them to click that then displays all of the other abilities, which they can swap for the existing ones, is one way to minimize the UI design. Of course, you don't want to have multiple pop-up windows, otherwise, it becomes a quest in itself to change in-game settings. Programming the user interface As we have seen in the previous section, designing the UI can be tough and requires experience to get into, especially if you take into consideration all the elements you should, such as the psychology of your audience. However, this is just halfway through. In fact, designing is one thing; making it work is another. Usually, in large teams, there are artists who design the UI and programmers who implement it, based on the artists' graphics. Is UI programming that different? Well, the answer is no, programming is still programming; however, it's quite an interesting branch of the field of programming. If you are building your game engine from scratch, implementing an entire system that handles input is not something you can create with just a couple of hours of work. Catching all the events that the player performs in the game and in the UI is not easy to implement, and requires a lot of practice. Luckily, in the context of Unity, most of this backend for UIs is already done. Unity also provides a solid framework on the frontend for UIs. This framework includes different components that can be easily used without knowing anything about programming. But if we are really interested in unlocking the potential of the Unity framework for UIs, we need to both understand and program within it. Even with a solid framework, such as the one in Unity, UI programming still needs to take into consideration many factors, enough to have a specific role for this in large teams. Achieving exactly what designers have in mind, and is possible without impacting the performance of the game too much, is most of the job of a UI programmer (at least using Unity). Four types of UI Before, moving on, I just want to point out a technical term about UIs, since it also appears in the official documentation of Unity. Some UIs are not fixed on the screen, but actually, have a physical space within the game environment. In saying this, the four types of interfaces are diegetic, non-diegetic, meta, and spatial. Each of these has its own specific use and effect when it comes to the player's experience and some are implicit (for example, static graphics) while others are explicit (blood and dirt on the screen). However, these types can be intermixed to create some interesting interfaces and player experiences. For Angel Cakes, we will implement a simple non-diegetic UI, which will show all of the information the player needs to play the game. Diegetic Diegetic UIs differ from to non-diegetic UIs because they exist in the game world instead of being on top of it and/or completely removed from the game's fiction. Diegetic UIs within the game world can be seen and heard by other players. Some examples of diegetic UI include the screens on computers, ticking clocks, remaining ammunition, and countdowns. To illustrate this, if you have a look at the following image from the Tribes Ascend game, you can see the amount of ammunition remaining: Non-diegetic Non-diegetic interfaces are ones that are rendered outside of the game world and are only visible to the player. They are your typical game UIs that overlay on top of the game. They are completely removed from the game's fiction. Some common uses of non-diegetic UIs can represent health and mana via a colored bar. Non-diegetic UIs are normally represented in 2D, like in the following screenshot of Star Trek Online: Spatial Spatial UI elements are physically presented in the game's space. These types of UIs may or not may be visible to the other players within the game space. This is something that is particularly featured in Virtual Reality (VR) experiences. Spatial UIs are effective when you want to guide players through a level or to indicate points of interest. The following example is from Army of Two. On the ground, you can see arrows directing the player where to go next. You can find out more about implementing Spatial UIs, like the one in the following screenshot, in Unity by visiting the link to the official documentation at: Meta Lastly, Meta UIs can exist in the game world but aren't necessarily visualized like they would be as Spatial UIs. This means that they may not be represented within the 3D Space. In most cases, Meta UIs represent an effect of various actions such as getting shot or requiring more oxygen. As you can see in the following image of Metro 2033, when the player is in an area that is not suitable for them, the view through the mask begins to get hazy. When they get shot or engage in combat, their mask also receives damage. You can see this through the cracks that appear on the edges of the mask: To summarize, we saw the importance of UI in game development and what are the different types of UI available. To know more, check out this book Unity 2017 2D Game Development Projects written by Lauren S. Ferro & Francesco Sapio. Google Cloud collaborates with Unity 3D; a connected gaming experience is here! Working with Unity Variables to script powerful Unity 2017 games How to use arrays, lists, and dictionaries in Unity for 3D game development