Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

Dogurai

Dogurai is a 2D platformer packed with fast-paced action, dogs, robots and pure retro goodness. · By HungryBear

Devlog #2

A topic by HungryBear created Jun 24, 2018 Views: 57
Viewing posts 1 to 1
Developer

Today`s devlog will be about the inconsistent style of technology used on level creation (or rather how the tools evolved over time

As i said in the last devlog, the game itself was a learning experience. During its creation time, we were constantly learning something new. Because of that, every new level, every new feature meant a new tool or resource we could use or do something in a better way. If someone ever does any data mining in the game and gets access to the game assets, they will know what I am talking about.

It started back in 2014, during the Game Dev class at the University of Brasilia, Thiago and I made a small rogue-like game and a level editor for it. Since the course demanded the use of C++ as the programming language, I made the skeleton of the actual frameowrk back then. Once the Jam began the editor was adapted to make a 2D plataforming game.

Only in 2016, when we decided to work seriously on the game, we had to change some things. The first level to be made, rather the Sewer one, was the Desert. Back then, the level was only tiles, collision blocks, monster spawn pointns, health items and plataforms (also 2 more blocks to spawn the player and the boss, respectively). Since this level had the bike gimmick I created a block called QuickTimeEventBlock.


So far so good, the editor had an option to add a text or a number up to 255 times per block so it was something like: add the block and set a text named “bike”. In the game code, a few functions were used to determine the behavior of the block. Then the third level was being made, the water one (blue). In this level you encounter moving plataforms, pistons and conveyor belts. These gimmicks couldn’t be made as quick time events, since those blocks would interact and all… they just wouldn’t fit. So a new type was created, the SpecialBlocks. That would help in creating any game objects and things out there that had some other interaction with the player.

By that time, I did not think about unifying everything in a single block type, mostly so I wouldn’t have to remake the levels that were already stable.

Then, came the Lua interface in the game. The Lua block was created. During the developement of the interface, the fire level was being created, so only a few things in there are in Lua. When I was about to finish it, the ice level was almost finished. The ice blowers in the level are in Lua.

Now the level 6 is a mix of all of those before. No more words.

And level 7 is… what can I say… pretty. 95% Lua, including its unique monsters and its boss.

I could remake everything now, right? Yeah. Nowdays, I could completely delete the QuickTimeEventBlock so I would have to remake only a few things in the desert level, but that doesn’t mean I’m going to. The game is already far more delayed than we planned to go back and remake mechanics from previous levels that were already tested a billion times, working just fine… it’s not a option.