Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1377712 Posts in 65443 Topics- by 57755 Members - Latest Member: LeoSax

June 01, 2020, 11:00:58 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsUntitled GB Game
Pages: [1]
Print
Author Topic: Untitled GB Game  (Read 496 times)
Robo_Chiz
Level 0
*

Dance all night


View Profile WWW
« on: December 23, 2019, 02:13:53 PM »



'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
« Last Edit: May 05, 2020, 09:30:04 AM by Robo_Chiz » Logged

mystic_swamp
Level 0
***


yoo doo right


View Profile WWW
« Reply #1 on: December 23, 2019, 03:58:48 PM »

Interested to see where this goes <3
Logged

Ishi
Pixelhead
Level 10
******


coffee&coding


View Profile WWW
« Reply #2 on: December 23, 2019, 04:49:56 PM »

Good luck, looking forward to following the devlog! Coffee
Logged

Robo_Chiz
Level 0
*

Dance all night


View Profile WWW
« Reply #3 on: December 24, 2019, 09:29:17 AM »

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!
« Last Edit: December 24, 2019, 10:09:02 AM by Robo_Chiz » Logged

The Armorman
Level 2
**



View Profile
« Reply #4 on: December 25, 2019, 05:55:22 PM »

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

BELOW FOR GOGNIOS

ABOVE, FOR GOGNIOS
Robo_Chiz
Level 0
*

Dance all night


View Profile WWW
« Reply #5 on: May 05, 2020, 09:28:59 AM »

Milestone #1 - Engine Revamp
Hello again! Coffee

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.
Coffee
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic