next »

[Robo_Chiz]

'Untitled GB Game' is my attempt at a platforming metroid-vania.
The player is tasked with defeating four bosses, unlocking abilities to aid exploration.

I've been working on this project casually for just under a year. I've spent the majority of that time developing a framework using SDL and OpenGL, and have only recently started working on the game itself. I'm hoping to use this Devlog as a way of recording the game's development as well as discussing my ideas about coding and game design. The art I'm using currently is temporary, and I'm hoping that over time the game's art style will become more concrete.

I'd appreciate any feedback during development.
I'll be posting regular progress GIFs on my Twitter!

Contents
2019
Inital Development
Milestone #1 - Engine Revamp
Milestone #2 - Map Screens, Game Jams & Level Progression

[mystic_swamp]

Interested to see where this goes <3

[Ishi]

Good luck, looking forward to following the devlog!

[Robo_Chiz]

Initial Development

Seeing as the end of 2019 is nearly upon us, I figured my first devlog should discuss some of the ideas, and mechanics I have implemented so far. The initial pitch for the project was based on my desire to not actually make a game at all. Originally I was more focused on implementing a game engine. When making games, I tend to have a million and one ideas, and it's quite easy for me to lose focus when a new idea hits. When I started in January, I hadn't actually stayed committed to a project for more than a few weeks. The last time I'd stuck with something was a fan game that I'd shelved last year. My general consensus was that the design of a game engine is already fairly established, meaning I could work on it without being distracted. It seems to have worked out.

Now, let's get some gifs going.

Why Gameboy?

So it should be fairly obvious by now, which limitations I've put on myself. Primarily I chose this style in attempt to make development easier for myself. I'm not really artistic, so by limiting myself to 4 colours and small sprites I'm hoping to avoid spending large amounts of time creating artwork.

I've also given myself the restriction of the Game-boy's resolution of 160 by 144 pixels. This isn't a huge amount of space, and it's why I will try and design most level elements to be 8 by 8.  Generally I want to have most (if not all) level elements as some variation of a square or rectangle. By keeping the building blocks of a level small, I will be able to create more complex and spacious levels. I want to avoid the problems that I see in games such as 'Super Mario Land 2' or 'Sonic Triple Trouble' where it's quite hard to see upcoming obstacles.

This philosophy also applies to the game's protagonist. The design is likely to change over time, but his current form is intended to give him a smaller presence on the screen. A challenge when designing him was portraying different movements, given the limited space. I gave him a large flat body, so that his limbs would always stand out against it. I'm planning to only use the brightest and darkest shades for the backgrounds, and so I've tried to avoid using them too much on him.

Level Creation
So far, I've spent the longest amount of time creating an in-game editor so that I can quickly prototype and test levels. I've been playing alot of Super Mario Maker 2 this year, and I really enjoyed the ease that comes with switching between gameplay and editing at the press of a button.

The current version of my editor is quite simple. I added mouse support fairly early on, as trying to place blocks using my keyboard was really slow and tedious. I've added a few different items to place down being: Blocks, Coins, Platforms, and Fake Blocks.

I hope that they're all fairly self explanatory. I'm hoping to use the fake blocks in some clever ways to allow players to reach certain areas quicker or out of order. The coins currently have no real purpose. I'm considering adding a shop similar to 'Hollow Knight', where the player could buy items to aid them during the game.

You may have noticed some dotted lines in the level-edit view. These represent the boundaries of the game's camera. The idea is based off a similar system found in 'Super Mario Maker 2', by placing a wall of blocks across the screen, you are able to stop the camera from panning past it. I really like this from a level design perspective, as it provides a nice 'end' to a section. My implementation is based on rectangles defined in the level, the camera is able to freely move around these areas, trying to keep the player in the center of the screen. It is also possible to overlap these boundaries. When the player is inside of an overlapped area, the camera will try to conform to the most appropriate region. This can be seen in the GIF above. I designed it so that when it transitions between areas we never show anything outside of the regions. This should hopefully mean that the player will never see anything that they're not suppose to, and also means I don't have to fill these areas with extra blocks.

And that's some of the work I've done so far! I'm really looking forward to properly working on the game itself in 2020.
I hope everyone has a great Christmas and a fantastic new year!

[The Armorman]

this looks like the makings for a great videogame if you need assistance, please reach out to Me, signed, youres truely.

[Robo_Chiz]

Milestone #1 - Engine Revamp
Hello again!

It's been just over 4 months since my last post and you may be interested to see how far the game has come in that time. It's a bit of a mixed bag. Gameplay wise, very little has changed. I've instead spent most of my time behind the scenes implementing new systems in my engine. I'd like to look at a few of them today.

Post Processing!

One of the first changes I implemented this year was a post processing or screen effects pipeline. Originally I had set up a basic system which took the final game render (at the Game-boy resolution of 160 by 144 pixels) and scaled it up to fit the size of the game's window.This was accomplished with some render buffers inside of OpenGL, and rendering a quad with a generic shader.

The new system builds upon this allowing multiple shaders to be passed over the render before it is presented in the final window. It might not be initially obvious where this is used. When loading into a level, I now perform a fun little screen transition. It appears as if light is entering the level spreading from top to bottom. This is accomplished using the gradient texture shown below, as well as a bit of shader trickery.

My new shader is aware of my 4 colour pallete, and has stored the colours in order of brightness. When it receives the final render, it re-colours each pixel based on a texture provided to it. If the sampled colour from the texture is white, then no change is made. As the colour approaches black, the shader swaps each colour for a darker one. When the sampled colour is black, then all colours will be shown as the darkest shade. By moving the texture over time, we get this fun little effect which is effective for introducing levels.

You may also of noticed that the fade works in all four directions. As well as going to darker shades, it is possible to do the reverse. Such as the example below, where we start on the brightest shade and return to normal.

XML Parsing!

The other main change (and one that has taken up most of my time) is the introduction / streamlining of an XML parsing system. I was originally using this as a way of storing level data. Each XML contained a list of resources, and entities (game objects) for a scene. Each Entity has a list of components (game code) that are associated with it. I decided it would be useful for development for me to pass data into components from my level XML. So for example, I could change the player's spawn position, and test the game without having to rebuild my code. I implemented a basic version of this where each components had access to their respective chunk of XML, and would have a unique method to parse it. This would work perfectly fine, however I quickly realised that it didn't scale particularly well and I would end up having to write hundreds of unique parsers that were would only perform simple actions such as converting strings to floats.

The new system is slightly complicated, but works perfectly for my needs. I'll try to explain it briefly, but will happily go into more detail if there's interest. Essentially my system is aware of a bunch of types (i.e. String, Float, Int, Vectors). For each type, I have provided a method that parses from a string, and return a string from a value of that type. When a new class that uses this system (called a ParameterOwner) is created, it registers a map of void pointers. The key of the map is a string which we use to find the XML attribute we care about. The value of the map is a void pointer representing a variable on the object. This was done so that the map could hold data of different (and unrelated) types. Some additional data is stored such as the type of the object. When the new class is told to load an XML, it traverses the map using the key to pull out a string from the XML. It then grabs the type from the map, and uses the provided parse method of that type to put the converted data directly into a variable in that new class.

I hope that makes some sense. Using this implementation means that I can hypothetically set any piece of data in a class without rebuilding the game's code. The system covers most plain old data types, and well as my resource types. This means that components can also now request textures, shaders, audio from the resource manager straight from XML.

I've also introduced the concepts of prefabs, and packages using this system. Prefabs are basically entities that will never perform any logic, an entity can be created by coping the components and children of a prefab. A package is a group of Parameter Owners (i.e. resources, prefabs) grouped by type. I'm using them to store resources that may be used by multiple scenes such as the Player, Camera and some level elements.

Thanks for reading. I apologise for the lack of gifs in the latter half.
Hopefully I'll have some more gameplay related updates soon.

[Robo_Chiz]

Milestone #2 - Map Screens, Game Jams & Level Progression
Hello again!

I've managed to trim my updates down from four months to two. Hopefully one of the new ways I'll be mixing up development this year. For Milestone #2, my goal was to focus more on the game side of the project by implementing one large feature, and several smaller ones. I did also end up doing some engine work which we'll get to shortly.

Unique Level Spawns

One of the features I implemented in Milestone #1 was the neat wipe transition as the player went between levels. I followed this up by setting up unique spawn points in each level, meaning that the player can walk between rooms and return where you would logically expect them to.

As part of this, I split the player platforming script into two parts. The 'Platforming Component' which handles the actual movement and physics of the player, and a 'Player Input Component', which is responsible for getting player inputs and passing them through to the 'Platforming Component'. I did this so I could also create a third 'Auto Input Component', which can be used for cut scene behaviour. You can see it for the small walk the player does from off screen as they enter a level. After a second we return control to the player. This was done primarily to stop the player from accidentally catching the level exit trigger and returning to the previous room.

In implementing this new functionality I also introduced a new piece of engine functionality I called 'Scene Load Parameters', essentially allowing me to pass in any type of data (using the XML system I created in Milestone #1), and have specific components check for that data on a level load. In this example, I pass in the spawn point I want the player to start at.

Screen Shake

Another small feature I implemented was a screen shake component. In this example I've mapped it to the jump button. I'm not 100% sure how I'll use it in the finished game, but I think it'll be useful in adding some visual flair.

Map Screen

The big gameplay feature for this milestone was the map screen. As the size of the game world increases I think it will become a useful tool. This feature was split into 3 main sections:

First, I wanted to create a tool to automatically map out the levels for me.

Second, I wanted a visual indicator that showed which parts of a level the player had been to. I was fascinated with the idea of the map filling in, with my hope being that player will be encouraged to revisit areas where their map has got obvious gaps.

Third, I needed to render all this information during gameplay, and add some visual polish.

This first screenshot shows my initial implementation of the map. I'd decided early on that I wanted a tool to map out the levels for me. This was so I could make quick changes to levels through out development and not have to worry about updating a map texture. I used the 'Scene Load Parameters' feature mentioned above to regenerate the map when I used the game's debug level select. In essence, the tool checks all the collision data for the level and stores it in a grid dependent on object type. As the game is grid based, each cell in the grid will only ever contain one type of object.

Next I scan the empty space in the level, starting from each player spawn point. I do this so I can map the 'player accessible' parts of the level, this is the data I will use to fill in the map later. This is done with some simple recursion checks on a grid cell, followed by it's neighbors, stopping if I hit a solid object (i.e. a wall). Once I have the data for the map, I trim the edges so that the grid only contains areas the camera will see. There's a lot of off screen walls / objects that I don't want to the map to show but need to be there to stop of the player going out of bounds .etc. The map data can then be saved.

I created a series of "Box Tools" that I use for map compression. Given a series of box, the tools are designed to produce the smallest amount of boxes that fill the same space. For example, if I have eight 1x1 boxes sat next to each other, the tool will generate a single 1x8 box instead. For map generation, I run this tool over the entire map grid, crunching down each individual grid cell into a larger box depending on it's type (i.e. Solid, Player Accessible .etc). This can then be saved out to a resource file, which will be loaded into the game on startup.

An example of how the box tool works can be seen above. This is a debug view of my map filling idea. For this, I pass in a box the size of the camera's view, every time the camera moves. You can see how the tool tries to compress the odd shapes I am able to make, with each coloured box representing the largest shape that would fill that space. I was really happy with how this turned out.

Once I was happy that the tool worked, I started to assemble the final render. I implemented some quality of life features, such as having the player's position be rendered, as well as having the map recenter on the player when you open it. I also added the ability to move the map by pressing a button. Finally I added a percentage in the corner of the screen which will tell the player how much of the current level they have visited. As someone who enjoys 100% completing games, I felt this feature would be appreciated.

For some visual police, I added an icon which changes colour depending on whether you are moving the map or the player, and a glitch effect which I feel gives the map a bit of life when it is on screen. The current version of the map unlocks areas as you enter it however I may introduce the ability to unlock areas of the map early by finding collectibles.

After completing the map screen, I took a small creative break from the game to enter the GMTK 2020 Game Jam. The theme was 'Out Of Control', so I made a game called Riotous Railway. I figured the jam would be a good way to test the versatility of my engine, and I was pleasantly surprised how easy it was to prototype gameplay features. You can play the game here: https://robo_chiz.itch.io/riotous-railway. For Milestone #3, my plan is to do a mixture of engine and gameplay features and I also plan to update this devlog more frequently. I'm hoping that doing this will be easier than trying to do a big summary at the end of each milestone.

Thanks for reading.