Sudokil Devlog #4 – A problem with perspective

I was supposed to release a new build of Sudokil with the released art this week, but a problem with the art perspective has ended up halting development somewhat. Right now we are using an orthogonal 3/4 camera perspective. Trying to figure out a perspective that both looks good and is as functional as possible is hard. My art requirements are that it should look good, and CLEARLY show ALL entities and objects on map in order not to obstruct puzzle solving. Here is a screenshot of the game:

We’ve gone for the perspective where the upper wall just takes up 1 tile, while the lower wall starts a bit higher and overlaps the lower floor a little bit. The art works quite well in the case of having a square room. However an issue arises when trying to design some rooms with one thick walls, and having overlapping walls. This is my attempt at it.

While it looks alright, there are definitely some issues with the 1 thick walls because they don’t look like they are indeed 1 thick. Also, once we start putting walls into the actual level area as opposed to the outside, we place them slightly differently as to not obstruct entity movement and such, but this creates inconsistencies. Another issue is that we are trying to make doors that span over multiple tiles and having a lot of trouble with the current perspective. I’ve looked to some other games for solutions and found a few.

Halfway. Here the one thick pillars take up physical space in the tile above them.

Pros:

  • Nothing blocked/obstructed
  • Looks like it is in perspective
  • Looks good in general

Cons:

  • The minimum height for a wall/pillar is 2 tall instead of 1 (restricts level design)
  • When being physically obstructed by the upper half of the pillar, perspective looks off
  • Lack of any overlap does not help perspective when above wall

Steam Marines. Here, all walls stick to their own tile.

Pros:

  • Nothing blocked/obstructed
  • Very clear which tile entities and walls are in
  • Level creation will be much less labour intensive

Cons:

  • Tiles look strange in some places (such as vertical doors)
  • Height of walls might not match entities
  • Perspective less realistic

Nuclear Throne. Here all the wall tiles overlap the tile above them slightly.

Pros:

  • Perspective works
  • Kind of what we are currently doing, but our walls are a different height

Cons:

  • Entities sometimes obstructed and less clear
  • Obstruction may limit level design for objects that might be covered
  • Height of walls might not match entities

This is our previous placeholder art. It uses a more true top down perspective.

Pros:

  • Nothing obstructed
  • Entity position very clear
  • Cheap art

Cons:

  • Looks kinda shit

And finally here are some images of playing around with perspectives

While that middle island wall pillar thing looks great in terms of the perspective (where the perspective overlaps half the tile above it), it does present the problem of blocking entities. The robot works fine because it is tall, but once you start using small objects such as crates, it is hidden behind the wall.

Just some playing around with cheap and dirty “3d models” I made out of paper. Helped a little bit when trying to go for realism, but does not help much in the gameplay practicality as it isn’t always tied to realism.

If anybody has anything at all to contribute, feel free to share! Should I stick to the current style or try for another? Would love to hear ideas on the current options, proposing new options, or any games with perspectives that might be interesting to look at and consider. Thanks!

The Well (Day 4 devlog)

Nearly done now! Today wasn’t as productive as it could have been, I spent way too much time looking around for royalty free songs and sound effects, and didn’t really come out with anything good. What I did accomplish today was adding some new textures such as the spikes, though I had to do it myself since the person who offered to help dropped out. I also added sounds into the game, and a menu screen to pop up before and after the game. I am quite happy with how the game has turned out, though I will have to do a lot of level design and art tomorrow to release this game in a reasonable state.

The way I did sounds was to have a central sound manager with a hashmap of all the sounds I need. When I want to play a sound like the player running, I set the player’s sound to the sound I want, and call this sound manager to play it in a loop. The other method I use for one time sounds such as the thud from falling or the sound effect when you die is to simple directly ask the sound manager to play the sound once.

the well menu screen

Starting splash screen

The spikes I did for today don’t really match the overall style of the game, however, I don’t really have time or skill to improve them at this point. From now, I need to focus my time into level development, and other high priority tasks such as the game over screen. I also did the art for my menu screen which isn’t amazing, but I am happy with it. I realise I won’t have a lot of time tomorrow, but it will be my absolute last chance to release this game within the next few weeks so I have to power through, and if it isn’t as complete as I would like it to be, then so be it. I am optimistic about it though, as I coded it quite flexibly, which means if I want to make a better game at a later time, I really only need to do the assets and level and not too much coding.

The challenge I faced today was using my time wisely. I spent far too long looking up sounds, and didn’t end up with many at all. I am not fully happy with the sounds I have right now, but I doubt I will have time to change it.

The Well (Day 2 devlog)

Day 2 of development for The Well has just finished. I didn’t get as much done today as I would have liked, and am falling behind. If I really want to finish in these 5 days, I am going to have to really focus on it and not get too caught up prematurely optimising things or getting too ambitious. With that said, there was some good progress today in terms of art and coding.

Coding wise, I have set up some world physics for the player. Every game tick (every time the physics up dates), I apply a set acceleration downward on all non fixed physics objects to represent gravity. At the moment, this is just the player but it will automatically be applied to any other objects I put in the world such as mobs or a box. When the player presses up, it gives a larger acceleration in the opposite direction for a fixed amount of time before gravity causes it to slow down and fall again. The difficulty I had was trying to make sure the player can only go upwards for a certain amount of time, and then make sure that they are touching the ground before they could jump again. The good thing about having this system set up was that it made it easier for me to set when what animations need to be played. Since I had all this information of when the player was touching the ground, when he was jumping and when he was falling, I then was able to easily tell it to play the desired animation.

The Well - Falling screenshot

Character with animations and physics

The animation system that I’ve set up took me awhile to figure out, but I managed to get it to work in the end. The way I set it up in the end is that each entity sprite has a list of animations, and each of these animations are made up of animation frames and some other data. Each frame is given a duration to be played, and each animation has a timer that counts how long the animation has gone on for. When the duration of a frame runs out, it then tells the sprite to display the image of the next frame. I had some other variables such as whether the animation loops, or whether it ends with a fixed image. This was used for things like the falling animation where the character raises his arms, and they stay raised until he hits the ground.

The Well - Walking screenshot

Character walking with an animation

The progress I made with art today was that I managed to get some animations for the player drawn. Each animation is just made up of a few different images (about 2-4), and so today I managed to draw the animations for running, jumping and falling. I am getting more used to doing pixel art, so hopefully by the time I get to doing the textures I would be able to do them quickly as they should be much easier than animations.

Challenges I had today was all the bugs I kept getting every time I tried to add something new such as the animation system or the physics. I think I really need to think clearly about what I want to implement and how I am going to do it before just writing a bunch of code that I later have to go through, fix and clean up. At least I managed to do better today on not prematurely optimising code as the systems I had to make today were pretty specific to this type of game.

Although this project is small, making all these little bits of it are making me see the potential of what kind of game I could accomplish if I wanted to designate the time. After I finish this project, I may try to use what I’ve learnt to implement a more complex version of it with better physics and more modular code.

The Well (Day 1 devlog)

I’ve decided to try to make my first video game this week, and I’ve given myself the restriction of five days to complete this project. The usual thing to do is to have 48 hours like the Ludum Dare, but since this is my first game I don’t want to rush or lose any sleep over it. The goal is to make a short 2d platformer about a boy who falls into a well, and has to try to find his way out. The reasoning behind the well is so that the game takes place in a cave setting, meaning less art will be needed. Due to my lack of creativity, the game is named “The Well”. The engine will be done in from scratch in Java, as that’s what I have the most experience with. I tried to learn to use some libraries like Slick2d, but it took too much time, so I’ve decided to just stick to what I know.

The Well - Demo Level

First day progress

Today, I’ve managed to get some of the foundation code set up. So far, the game loads a map and tilesheet (text files) and places a character for the player. So far, the player can move around, and collide with the walls of the level while the camera follows him around. I’ve decided to have three layers, a background layer, a collision layer, and a foreground layer. The reason there are three separate layers is to make the map editing more flexible, as there doesn’t need to be code for each type of tile possible. Another benefit of having separate layers is that each tile doesn’t have to be completely square. The collision layer and the foreground layer can have transparency without leaving holes in the level.

Demo level screenshot

Testing level

So far in terms of art, I am just using placeholder black and white tiles to show the background and the walls, but these will be replaced with proper tiles once I am done with them. I’ve also drawn a main character, but it is still a rough draft. For this project, the coding will probably be done first, with the art, music and level design done after all the main mechanics are in place.

The biggest challenge today was trying to structure my code. I spent so much time worrying about how object oriented the code is, and trying to make the engine really flexible. I realise now that it was premature optimisation that really isn’t needed for such a small project, so from now I am going to try to code quicker and just get as much content as I can done. Tomorrow I want to try to get done the coding for animations, some tight movement for the character, and a menu and options interface.

I’ll be making a blog post and video each day showing my progress and explaining a bit of my thought process behind my decisions. Overall, I think this project will be really helpful in terms of learning as I’ll have to use so many skills in such a condensed time frame. I am mainly a programmer, so naturally the coding is the most important part of the project to me, however making the entire game myself will force me to broaden my creativity. I’ll have to do all the drawing and music myself, and since I have very little experience in this I could really learn a lot from it. Another thing is that I am a terrible writer, I have always been terrible at English, so forcing myself to make these blog posts will hopefully help me work on that.