For the 2019 GMTK Game Jam, a couple of friends and I produced Greedy Pirates: a short whimsical puzzley platformer revolving around the idea that there is "only one" pirate.
By the completion of development, this concept has manifested itself in two distinct ways:
You can download the game from our website or play it directly in the browser from the Greedy Pirates game page. (It's free.)
In my younger years, I played a lot of flash games online. Looking back, I'm guessing most of those games were pretty low quality games that I wouldn't be bothered to play through now. As time goes on, I feel that I am slowly learning more and more the value of putting a game down.
One example of a game I put down recently is Secret of Mana. After I got a Super Nintendo Classic, I took it upon myself to try out some of the classic games I had heretofore missed. But Secret of Mana just really didn't stick with me. I had a poor first impression of the menuing, the slow start of the story, and the finnicky action battle mechanics. I really don't doubt that there are things about the game that make it great, but for me I feel it was valuable to put down the game when I didn't have enough interest in playing it.
But this past week, I put down a game for a different reason: conscience.
It's been more than a month since Part 3 in our 2.5D game blog series adventure, but I left us on a big cliff hanger! In this post, we'll walk through the core elements of how we designed our game engine to satisfy our 2.5D needs.
Over the course of this blog series, I have danced around three axes of consideration for engine implementation: 1) 3D physics, 2) rendering order, and 3) level editing. These three are not intended to be comprehensive, but they will help us organize our thinking about design of this engine.
I want to note that the traditional layer-based 2D engine generally nails two of these three. (2) Layer-based 2D engines don't have difficulty with rendering order because layers can be rendered in order and sprites can easily be sorted on the same plane. (We talked about this some in our bonus round post early in the series.) (3) Level editing is natural because the 2D plane of the game world maps directly to the 2D plane of developer's computer screen. (And to manage the complexity of multiple layers, individual layers' visibility can be toggled to only show a subset of all layers at once.)
Part 2 of the series left us with the urge to pursue a 3D engine, but what can we do to get out of 2D land? In this post, we'll look at some of the options we considered to fulfill our 3D dreams.
Truthfully, we didn't look at that many options to satisfy 3D requirements; so I have once again proven that my series outline from Part 1 was not well thought out, but here we go anyway!
As soon as I start talking about 3D games, the variety that inevitably comes to mind is what I'm going to call that of a "full" 3D game. In a full 3D game, the engine handles 3D physics and 3D rendering via 3D models. Most triple-A games in the current video game industry are full 3D games.
Interestingly enough, the direct successors to both 2.5D inspiration games cited in Part 1 appear to be full 3D games, despite having gameplay that is nearly identical to their true 2D heritage. I think that a lot of game developers wind up going this route because of already-built game engine support.
My trajectory was explosive for parts 1 and 1B of this series, but this post has been a bit harder to put together because my outline was apparently terrible. Despite that, I'm going to try to stick it out.
It seems that a much larger percentage of games are 3D than was the situation in the past, but a 3D game is by no means necessarily better than 2D. I brought up in Part 1 of the series that one of the driving motivators for 3D in Maven was the jump mechanic. Jumping is a pretty good representative of the primary class of 3D features that we care about; so I'm going to try to visit the questions posed at the end of Part 1: "How might an engine fake jumping in a layer-based 2.5D game?" and "Why is jumping important?" (I know, I know. I changed the questions a little bit; so those aren't exact quotes. But if I'm quoting myself...)
In the old Maven demo, we tried to produce a jump mechanic that would allow the player to jump over things or jump up to higher areas. This visual should give an idea of what we are talking about with the jumping-over-things part, and we'll touch on the jumping up part later.
Up to this point, our development had consisted in layer-based 2.5D game engine land; so we had to consider how to accomplish this feat while always keeping the player on some layer.
I got a little bit ahead of myself in the last blog post and missed talking about a key area of technical discussion: what we did with a third dimension in An Altered Course. In this post, I would like to talk a little bit about some very specific ways we used the third dimension in An Altered Course and how we achieved those features from a technical perspective.
As discussed in the last post, AAC was developed with RPGToolkit and its layer-based 2D game engine. With this system, all components of the game are subdivided into discrete layers for independent handling of physics and rendering.
Although I described RPGToolkit as splitting the game into layers for rendering, I didn't particularly note that on each layer the engine will render first the background image and then the "item" and "player" sprites in y-axis order (as discussed in some length in an older post about layering). This is one of the features that using an engine like RPGToolkit buys developers so that they don't have to implement the feature themselves. As you will see in some of the screenshot examples, this engine also adds a fancy feature of re-rendering important sprites like the player again at less-than-100% opacity so that it still shows when it is behind something else. However, RPGToolkit does not know how to render sprites across multiple layers; so we had to do some extra work in level design to make tall object render properly.
In this first shot, you can see an example of these tall trees that were present all over the place in AAC. The player renders properly in front of the tree, and one tree renders properly in front of another tree. So far, this capability could be accomplished simply by making the trees "items" on the same layer as the player.
But in order to generalize this concept to work when there are more layers involved, our solution was to split the tree sprites across multiple layers. Generally, we would split these large trees into three different layers so that the trunk was put on layer 1, the middle section on layer 2, and the top part on layer 3.
Although we have a lot to make up for, some recent developments may provide just the content we need to generate more posts. One of the ideas that has been percolating in my mind since Maven's inception is the idea of allowing the player to jump. But 2D games make it difficult to enable such an action. So here is the bottom-line: Maven is going 3D. In this post, I would like to talk a little bit about 1) where we came from, 2) why we wanted new features, 3) what options we considered, and 4) how we implemented our system. However, writing this blog post has shown that this outline will need to span multiple posts.
When I decided to get into game development, I had no idea what kind of games were even possible to make, since I had no experience with programming at the time. Fortunately, I did not try to go the route of full 3D game development, because that would have been difficult. So instead, I wound up pursuing 2D game development.
Obligations have cleared up recently in a significant way to allow development on Maven. We're looking at having something new presentable by the time CGDC rolls around.
In the meantime, check out this trippy shot of soldiers with Flash-like symptoms in the middle of some timing refactors.
After a long period of not posting, I've decided to have a change of pace and write about some other games I've played outside of the work we are doing at SoloVid. (Maven hasn't moved much in the last year, but we're still hoping to see it come!)
I'm not much of a gamer, but I do enjoy games. I particularly enjoy the fascinating things I learn about game design from other games. So today I'm going to talk a little bit about Rakuen, a storiented game by Laura Shigihara. The game very much takes queues from Kan Gao's To the Moon, but there are some things Rakuen has to add to the genre.
You may notice that the website looks a little different. We have just migrated from using Weebly to a custom PHP website. Weebly worked really well, but using the free version did not allow great file management, and custom HTML was a little onerous to manage.
Shout out to Weebly RSS feed Generator web app which made the migration process a little easier.
With that item off the checklist, hopefully you will start seeing some more updates soon!