PlanetSwitch Planet3DS PlanetVita PlanetiPhone Classics Forum

PGN-ID:[?] (Nicht eingeloggt)
PlanetDS PlanetGameboy


Sonstiges: Developer Diary - The Creation of a Switch Game

Michael Grönert, am 26.12.2016, Seite 16 von 25

Artikel mögen: Weitersagen:

BadToxic Discord Server | GameMaster Discord Server | BadToxic on Twitter
BadToxic on Instagram | BadToxic's Dev Instagram | BadToxic on YouTube

2016- Part 1: Welcome to the world of video game development!
2017- Part 2: It all begins with a first idea
- Part 3: The requirements
- Part 4: Final preparations
- Part 5: Ready to go
- Part 6: GONG! The first mini game
- Part 7: The Inventory
- Part 8: Saving & Loading
- Part 9: Skill tree & Menus
- Part 10: Achievements & Notifications
2018- Part 11: Day and weather change
- Part 12: Network Gaming
- Part 13: Companion Pet
- Part 14: Support for Android and iOS
- Part 15: Pairs - Find matching cards
- Part 16: Integrating Pairs into GameMaster
2019- Part 17: Statistics
- Part 18: Fizhy
- Part 19: Porting Fizhy over to GameMaster & AI
- Part 20: Creating a Community
- Part 21: Shaders and Particles
2020- Part 22: Overworld Landscaping
- Part 23: 3D manga-style characters
- Part 24: "Cooking" hamburgers together
- Part 25: Character Individualization

Part 16: Integrating Pairs into GameMaster
Last time, we implemented a new game where you have to find pairs of cards. We built it as an independent project and published it as a separate game. Now we want to add this to our GameMaster project as a second mini game. Unfortunately, it is not enough to copy all files into the target project - there are a lot of necessary adjustments to be done and of course we want more new features.

Local game with four players and 20 cards

The necessary adjustments
Luckily we have planned to integrate the new game into our project from the beginning and built it up accordingly. There is a controller object that is needed for all logic as well as a player object. These two can inherit from the corresponding equivalents in GameMaster and thereby automatically take over a number of required properties, making it possible to start and end the game from the outside, for example. Other objects such as the play card can be adopted with almost no change while the inheriting still need some adjustments.

Like our previous mini game "Gong" we want to allow up to four players, both locally and in network games, instead of the two players from the previous stand-alone game. We also want to add the ability to level up and develop the game which is the basic feature of a mini game in our project. We therefore have to determine which actions yield how many experience points and what functions you can unlock with it. Only a local human player should get experience when competing against CPU players. The higher the level of difficulty, the more points you should receive. Each found pair should give a small amount and winning much more. It would also be nice if you could get experience in a game against humans but it would also make it very easy to cheat. In order to prevent a player from deliberately losing to give the other more experience, he should lose experience in return. But even then, the other player could simply reload his save game after his experience has dropped. To counteract this, one would have to manage the save game for an online game on the server which unfortunately I can not currently offer. In addition, this would be impossible in local offline games.

Developing new options
In order to turn the earned experience into improvements, "Pairs" also needs a skill tree. This is implemented similar to that of "Gong". You have the opportunity to "learn" the difficulty levels and a higher number of players. Great for this type of game is the ability to have nicer cards - such as pictures instead of patterns - and a higher number of cards to uncover which should lead to a higher experience payout. From that, different types of cards must be drawn or created and the number of cards must be changeable. For a long time I was not sure if such learnable options, for example the higher number of cards, should be adjustable or mandatory when learned. In the end, I have implemented an additional options menu for such things, which can be found in the main menu of a mini game once you have access to at least one option. However, this is not very user-friendly and I thought about including this in the menu where you can choose the number of players. Then again, this player menu already uses up all the space on the screen on a 3DS which is why another solution would be necessary - multiple tabs or scrolling. Another alternative would be the ability to activate and deactivate the skill directly in the skill tree. While this would be intuitive and compact, it would still require some sort of navigation to this menu that is otherwise unnecessary. In the end, as I said, I implemented the variant with the options menu in which two settings can already be found, provided that you have learned them. In addition to the option of selecting a card set from the initially available patterns and photos, you can increase the number of cards from 12 to 20.

Develop options to use more graphics and more cards at once

"Pairs" offers a card collection - a menu item under which you can see which cards you have already revealed as a pair. This had to be incorporated into the menu structure of our mini games in a way that can easily be reused by other games. Previously, these collected cards were stored in a text file and loaded from there. In order to comply with our GameMaster saving principle, this has been completely replaced. Only one bitmap is saved, that is a single number in binary notation that assigns a one for each collected card and otherwise a zero. The image files of the cards all end with a number (such as card0.png to card42.png) which can be uniquely assigned to the positions of these bits. Instead of a text file with up to 42 lines of text, this results in a number with a maximum of 42 digits (binary). This of course saves space and is also stored and loaded faster.

A few of the patterns and photos that can be collected

Always the biggest problem - network games
The biggest challenge is once again the network mode. Up to this point, we just synced players' positions and orientations, something that does not really help us with a card game. Instead there are completely new commands that are probably not suitable for reuse in other games. The host of the network game sends all participants unique identification numbers of the covered cards in the order in which they are created. So you can make sure that all players play with the same cards. In addition, it must be ensured that only the player of the current move can turn over cards that. We can take over how the points are counted from Gong. For the existing functions it doesn’t matter whether it's about "scored goals" or revealed matching cards.

Of course this diary entry only scratched the surface of the tasks and problems again but this should suffice for an impression. Next time, we will look at "statistics" - remembering various values such as the playing time or number of games won, why it is needed and what it can be useful for. Until next time!

Do you prefer to read this diary in the developer's mother tongue? Then click here to read this diary entry in the original German language!

Gehe zu Seite:
Vorherige Seite | Nächste Seite

Kommentare verstecken

- Kommentare

- Noch keine Kommentare vorhanden -

Um Kommentare zu schreiben, bitte oben einloggen oder jetzt Registrieren!