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!

Sudokil Devlog #3 – It’s starting to come together!

Over the past month and a half, I’ve been working hard on getting some new features into the game and getting a new version of the demo out. One of the first things I worked on was adding a level loader so that you don’t have to start from the first level every time you close and open the game. Plus it is really helpful for testing since I can easily make playgrounds and add them to the game. In terms of gameplay features I added a new networking system, and started the works of a current system so that you can have things like pressure plates releasing a current that can open and close doors or fire bullets from a turret.

ctofmwkvyaasbmo

While the programmer art is still in, I’ve been working on getting the game looking a little bit better. The first thing I did was to update the UI a bit so that it is a more polished and consistent style. Next I added lighting into the game! It was a lot easier than expected since I just had to implement box 2d and use the library box2d lights. The only thing I had to add that was a little difficult was giving each entity a box2d body that the game updates as entities move.

As for content, I polished the first two levels and completely redesigned the second one. After that I added level 3, 4 and a few playground levels for testing. With the new level loader you can try any of these out.

cs5yan0uiaasuwm

On some non visible features that I’ve worked on to help develop the game better, I’ve been working a lot on how my level construction works. Previously I was constructing my entities by hand in json, which was great because I could make entities really flexible with my entity component system, but got tedious when it came to making levels with many entities. Now, I’ve added a parser to read object properties from the tiled editor so that I can construct the entity components from inside the map editor! It has been a massive help, and I’ve now updated all the previous levels to use this new system.

I have a few focuses for the next release that I would love to get done. I am planning to start putting out new releases at the end of each month.

  • get some better art into the game
  • add a new puzzle and level (probably to do with circuits)
  • polish the older levels and split up level 1 so it isn’t so long
  • polish up level 4
  • bug fixes

Sudokil Devlog #2 – Computer terminals!

I’ve spent a bit of time coding a system that allows you to connect to a different filestructure from your terminal window. This means that I can have different access terminals around the level that you have to send a robot to in order to use their devices. In this example, I use a robot to connect to the terminal in order to open a door blocking the path.

gif9

I am starting to get a clearer picture in my head as to how I want the gameplay to be. I think I might have wires going out from each computer terminal attaching itself onto different devices. This way the player has a clear idea as to what computer terminal can access what. All the different connected systems could be colour coded? Maybe there could be some kind of wifi system? I did say STARTING to get a clearer picture.

There is still a lot of foundation work to be done, for example code infrastructure wise, I would like to at least get started on an in game level editor,  and improve the command line interface code. I think I might put that off for awhile though, and focus instead on constructing a prototype level. This way I can get  a clearer picture of how I want to game to be, and whether I can actually make it fun or not. On a different design note, I’d love to talk to some people familiar with unix scripting, and get some feedback to redesign the command line interface structure. This project is starting to sound more serious than I originally intended, but I am really enjoying it so I am going to keep dev-ing!

Sudokil Devlog #1 – Playing with CLI mechanics

Here’s the first video showing off the work I started on a new project nicknamed Sudokil. The game revolves around having to use the command line interface to type commands into the game. Through the CLI, you are able to navigate a file system full of scripts and entities using UNIX like commands. Using the scripts, you can control various entities, devices and machines like robots, doors, cameras and computers.

I started making this game just as practice while warming up for LD30, but recently have picked it back up again because it was an interesting concept. The inspiration for using a command line interface to control a robot originally came from the game Duskers by MisfitsAttic (I AM SO EXCITED FOR THIS GAME). As I developed more and more though, I realised the potential of using the CLI for more things like possibly hacking into things. There are quite a few games that have the theme of hacking in them, but very few of them actually resemble hacking in any form at all (a few exceptions like Uplink). I am currently trying to build up my code base of things to use for future games (some boilerplate code for a level editor, main menu, game saves and game preferences) while also playing around with the command line mechanics to see how far I can take them. I usually swap around between working on the game mechanics and the code base I am building because it does get tedious focusing on one for too long.

gif4-480

Strangely enough, after making the video I stumbled upon Quadrilateral Cowboy by Blendo Games (I love his games, my favourite being Atom Zombie Smasher), and it seems to have a few similarities in terms of the CLI. Brendon is a god of game design though, so I might end up having to steal some of his ideas on how to implement the command line mechanic well. From what I have seen so far, the scripting in it seems fairly basic (though the rest of the game looks oh so beautiful), so maybe I can take that aspect a bit further. Unfortunately, focusing on the scripting might put off a lot of people (especially less tech savvy ones), but if I can make a short game that a few people enjoy, I’ll be a happy camper.

Aside from coding, I want to do more research on writing bash scripts and using the UNIX command line terminal. Hopefully I will have some cool new ideas next time, but feel free to give me any suggestions and feedback!