ZwodahS

LudumDare 48H #30

Another ludum dare is here and this time I decided not to post about participating until I actually completed it. Since I completed it, I shall write the post mortem for it.

First of all, the game can be found at the ludum dare page or at github.

Upon knowing the theme, I kind of immediately had the concept of objects passing from one world to another. Initially I wanted to do a match 3 style game. It was the first thing that came to mind. I didn’t immediately start coding; instead I take my time to have my lunch and think about the idea.

I settled on a tile game where you connect the line to move the objects to the next area. This appears in the last world in the final game. By the end of the first day, I finished setting up the basic architecture of the game, with basic collision and pushing of blocks. The matching is also completed. It seems like I was really closed to finishing so I decided to take the time to set up my XCode to export the game.

On the second day however, I had a sudden change of idea. I thought, what if each world have something different from the others.

I took the entire day (and night) to finish the ambition goal to change requirement at the last minute. I did managed to finish the game at around 3am (submission at 9am).

So what went right :

  • Using a framework I am really familiar with.
  • Using a graphic style that really do not need me to draw.
  • Trying to set up XCode early.
  • Setting up the architecture of the game properly.

I was toying around the idea of creating a SFML library that (almost) mimics what ncurses has about 2 weeks before Ludumdare. I am really glad that I managed to finish that code just before Ludum Dare and using it really saved me a lot of time. You can find it in my github inside zframework. Because of that code, I also ended up using a character-style graphics instead of nice sprites. That really saved me a lot of time, which is then used to create the gameplay.

On the first day, I actually spend a lot of time setting up the game architecture, which I thought was a bad idea initially. The effort did pay off when the requirements of the game changes and the architecture was ready to adapt to the new idea.

So what went wrong :

  • Not testing compilation of code on Windows prior to LD.

That is pretty much what went wrong. I spend a few hours trying to compile it on Windows, with errors that I had never see before. I did manage to get it working eventually today, 1 day after the submission. Other than that, this ludum dare couldn’t have gone better.

This time round I really enjoy the process and manage to make the game that I had in mind on the second day. I hope that the next will be the same =).

Let me know how you feel about the game by tweeting me.

!Hack

I decided that since I will not be working on this full time, I should at least write about it.

I have been working on a project after the previous maze idea didn’t turn out as fun as I thought. I wanted to continue the idea of computer hacking using mazes as the core gameplay.

The Name (!Hack)

The name of the game is call “Not hack” or “!Hack”. The reason for the name is due to the misconception that “hacking” is the act of breaking into computers and stealing information, which is not true. The act is call “Cracking”. Initially the game is call crackNotHack, but it is too long, so !hack is good enough.

Gameplay

The basic gameplay involve you exploring a maze. Unlike normal mazes, the maze that you explore will be heavily connected. When traversing a maze, you will automatically move to the next junctions or until you reach a point of interest. This gives rise with many limitation, like not knowing what is around the corner or unable to avoid collision with other objects.

The objective of the game is to steal information like email address, credit card information or login credentials from other computers in order to pay your debt. These information comes in the form of data that can be found in various computers. Data could also contains other stuffs like location of important computers, programs that you can use or even access key to specific network/computers.

The program that you use to navigate the network is call the Navigator. Your Navigator can be attached with various other programs that allow you to perform various functionality in the network. Some examples include scanning the topology, installing backdoor or the basic downloading of data. Each program that you installed increases the size of your Navigator. Navigator size affect how fast your presence is felt in the network and presence affect how fast you get traced by security software. Once you are traced, you loses the game.

There are various type of objects that will block your way in the network or security software that will trace you faster. This makes navigating secured network harder and requires more powerful exploits/programs that can shutdown the entire security. Those do not come without a price. Once you use certain programs, especially those that are exceptionally harmful, more computers will fix those exploits and your programs will become useless. Don’t worry though, since new exploits will be found and new programs will be created; You will just need to find them again.

Last word

I am not sure when this will ever be ready but since it is a roguelike that is built using Ncurses, I don’t think it will take too long. I kind of want to make sure that it is ready and the code is clean before I open-source it.

New Game Idea

So I thought maze deduction game is fun … and I made this, or github. I made it with python/flask, hosted it on heroku and it is working, just not what I expect it to be.

The initial idea is to try to make a maze game, where the players enter a series of command, like “move”, “turn left” and deduce the structure of the maze. The additional catch to it is that in order for your “program” to give you feedback, you need to return to the starting point.

First let me show you the maze. When the game starts, you will not see the visual representation of the maze, since that is what you have to deduce.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#####################
#             #     #
# ### ####### # ### #
# # #       # #   # #
# # ####### ### ### #
# #       # #   #   #
# ### # # # # ### # #
#   # # # #     # # #
### ### # ####### ###
# #     # #     #   #
# ####### #i### # # #
#     #   # # # # # #
# ### # ### # # # # #
#   #   #   #   # # #
######### ### ##### #
#   #     #   #     #
# # # ##### ##### ###
#   #   # #     #   #
# ##### # ##### ### #
#       #           #
#####################

In this case, the “i” symbol is the starting point and you always start facing NORTH

To start, you can always enter an empty instruction. It will just make your program go into the maze and exit. Since you didn’t move, you are guaranteed to be at the exit.

1
2
3
4
5
6
7
8
[Begin - ]
[    Front is passable]
[    Back is passable]
[    Left is not passable]
[    Right is not passable]
[    At entrance]
[End - ]
    Successfully exit

So from the logs that your program gives you, you know that FRONT and BACK is passable, which can be seen from the visualization.

So let us try to move front and turn “BACK” and move front. The instruction will be “mbm”, which is equal to “MOVE, TURN BACK, MOVE”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[Begin - ]
[    Front is passable]
[    Back is passable]
[    Left is not passable]
[    Right is not passable]
[    At entrance]
[Executing Move Instruction] Move
Move terminates after 11 cpu-cycle.
[    Front is not passable]
[    Back is passable]
[    Left is passable]
[    Right is passable]
[Executing Turn Instruction] Turn BACK
[    Front is passable]
[    Back is not passable]
[    Left is passable]
[    Right is passable]
[Executing Move Instruction] Move
Move terminates after 11 cpu-cycle.
[    Front is passable]
[    Back is passable]
[    Left is not passable]
[    Right is not passable]
[    At entrance]
[End - ]
    Successfully exit

Let us focus on the MOVE instruction. In the logs it says it terminates after 11 cycles, but from the maze above, we can see that after moving front one space, it should have hit a wall. Move instruction isn’t really just a MOVE. It is an instruction to move until a decision point. A decision point is a junction where the program don’t know where to go or something of interest, like “entrance” or “doors”

So after a single MOVE, you will be at

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#####################
#             #     #
# ### ####### # ### #
# # #       # #   # #
# # ####### ### ### #
# #       # #   #   #
# ### # # # # ### # #
#   # # # #     # # #
### ### # ####### ###
# #     # #xxxxx#   #
# ####### #o###x# # #
#     #   # # #x# # #
# ### # ### # #x# # #
#   #   #   #ixx# # #
######### ### ##### #
#   #     #   #     #
# # # ##### ##### ###
#   #   # #     #   #
# ##### # ##### ### #
#       #           #
#####################

The ‘o’ represents the original position, and the ‘i’ represents the new position, and the value “11” is equals to the number of “x” + “i”. So it takes 11 step to get to the next decision point.

After that, we turn back and move back to the entrance.

I can go on to show more commands, but it is really pointless.

So the problem :

Firstly, it is really hard to try to deduce the graph at the current form. The main reason is that there is only one known position, which is the entrance. I thought about labeling each junction so that the player can know that he/she has enter the same junction twice and from there, deduce the maze. It is not a bad idea if not for the second problem.

There is no point in deducing the structure of the maze since you could technically draw the maze as a graph. Using a graph, getting from one point to another point is kind of no-brainer.

I thought about implementing doors as well, which will open/close when the player touches a switch. However, that would mean that after the switch is touched, the maze is in a completely different structure and thus cannot guaranteed the program can get to the start point again. In a way, after you touch a switch, you are technically in a different maze.

Another problem is that as a player, I have to mirror my moves every single time to get back to the start point. For example, the instruction always looks like “XXXXXXXbYYYYYYY” such that X is the reverse of y, like the instruction above, mbm. This is pretty stupid and I should remove it, or just remove the need to return to start point.

Lastly, I realized this is a problem of traversing unknown graphs, except that in this case, you can only remember certain vertexes. Not sure how I feel about it.

Solution ? Hmmmm not sure, but I will leave it at this for now.

New Direction

It has been a while since I update my blog. I have been working on another project since the last update. From the project I have learn 2 new things; ncurses and lua.

I have decided to write a small lua tutorial, focused on how to put lua into C++ projects. It will probably not be something lengthy since I already have a few examples up at my github. I want to write a tutorial, at least for myself, in case I forget it in the future.

It is also obvious that I probably wouldn’t finish the roguelike tutorial. I think I have tried to achieve too much in a tutorial. I might rewrite the tutorial using ncurses, since it will be easier that way and I can focus on writing the game and not spend so much time on the ui and stuffs.

So for now, let me write the lua tutorial while it is still fresh in my head.

Post Mortems

This is kind of a weird post to be writing since I didnt really finish any game. I have been working on a few projects on mobile after Tap the numbers was released. I was kind of addicted to implementing game on mobile. However, most of them failed my test at the prototype stage.

Destroy The Blocks (1 Week)

I wrote in the last post, I started working on an idea call Drop the blocks(DTB). The half-baked product is currently sitting in my dropbox. I can’t find the fun factor for DTB after 1 week of testing. So until I can find a fun factor for it, or have new ideas for it, it will be hibernated.

I didn’t learn much lesson for game design while working on DTB. However, I did learn how to use state pattern in DTB which is then applied in the next project. In that sense, I think the time isn’t really wasted.

Block Alchemy (2 Weeks)

After DTB’s prototype fail, I started working on an alchemy idea, similar to all the alchemy game in the market. However, instead of just giving you everything, I laid all the resources out in the grid manner and only allow you to combine adjacent elements. This allow for interesting mechanics and I had fun implementing it. As I was about to go all out to finish the game, I watched one of my friend played it and I realized a fundamental flaw in the game. I then stop and hibernate it as well.

So what was the problem that I saw ? In the original alchemy game, like the one on littlealchemy.com, or games like doodle god, you are given all the resources. The primary focus of the game is just plain exploration.

In BlockAlchemy however, i envision it to an part exploration, part resource management game. I wanted it to be too much. In BlockAlchemy, different blocks serve different purpose. Some allows you to move blocks around; some allows you to transfer elements, create elements or even change elements from one to another. It was refreshing when I first played it myself.

After playing for a while on my own, I realized that I have the curse of knowledge. I couldn’t experience the exploration part myself, since I already know how to get certain things. I assumed that players will learn how to create things or at least try to experiment with it. I hide many secrets to allow players to stumble upon them.

But when I watched one of my friend play the game, I realized all my assumption is wrong.

The first problem I had was that the players doesn’t know what is possible. The secret I made will not be explored by players because of this.

The second problem I had has to do with the focus of the game. Exploration is the key part of the game, not the resource management. No one care about the resource management. What is fun is finding out what A + B is, and clearly, my resource limitation is getting in the way. There is this saying that, the best game is not when there are nothing to add, but nothing to take away. So in my case, I should just remove the resource management part of the game and make it just pure exploration, and the game is just a clone of any Alchemy game. This is not my purpose, which is why BlockAlchemy is currently hibernated.

ZeroTen (2 hours)

The game I made after hibernating Alchemy, is a simple game call ZeroTen. The idea is you are given a 6 by 6 boards with numbers from 1 to 9. Then you are given another number, from -4 to +4. You then choose a row/column to apply the additiona/subtraction to. As the name suggest, your objective is to get to 0 or 10.

The idea is pretty simple, but the game is pretty hard, and random. I haven’t really fully hibernated this game, since there seems to be something to explore here. I will think about it more though =).

Not much more for me to write here, just a minor update and logging down my process.

Delayed Postings

Roguelike tutorial

I haven’t been updating my roguelike tutorial in a while. I have rewritten quite a bit of stuffs except that they aren’t live yet. I am kind of in the middle of rewriting the whole thing and use a new architecture to do things. I want to finalize them before I add anything to the blog.

I have also changed the goal of the tutorial. Initially I wanted to just create a roguelike and write a tutorial along the way. However, as I write the tutorial, I realized I want to use it to satisfy my urge to over-generalize. This makes making progress hard as I usually think about the implementation of a small feature for days.

Tap the Numbers

Of course, I still want to get things done. I recently published my first game on play store =D. The link to the playstore can be found here. It is just a simple game that train your memory. Although there isn’t much downloads at the moment, it has helped me get into Libgdx again and made me want to make more games for it.

This brings me to my next update. I am making another game for android =D.

Drop the blocks

The idea initially was to make destroy the brick with libgdx. Destroy the brick was a game I made in flash a long time ago, and ported it to sfml with some modification. As I was preparing for it, I explored a few ideas and decided to stick with an idea that is similar to match3 + puzzle fighter + various other things.

I made a version for SFML as a 1D1G project. Although it is not really done, I might still add it to the project listing in the future.

Challenges

I have been struggling about what to write for my first post for this blog and I thought the best way to start the blog is with a bang.

1 Day 1 Game

Initially the idea is to make 5 games in a week, which translate to 1 day 1 game. This motivation started because I managed to make memory square in 6 hours. However, I struggled to think of 5 games to make in 5 days. Instead, whenever I feel like doing so, I will make a game in a day. Instead of making very small games, I want to challenge myself to see how big of a game I can make in a day. All the games I made in 1D1G challenge will be listed here

Roguelike tutorial

Recently I got hooked to Roguelike(again), namely Brogue and Cataclysm. I found Brogue through Pixel Dungeon(Android) about a month ago. After playing Brogue for a week, I started to miss Cataclysm DDA. I started playing it again and it got me thinking, perhaps I should make a rougelike.

I initially found out that there is a challenge call the 7 Days roguelike, which involve making a rougelike in 7 days. However, just making it isn’t really fun, and there is nothing to blog about.

So I thought, perhaps I can write a tutorial-like log while making the game. This can served as a tutorial for people who are interested in making roguelikes. Because of this, I probably need a slightly longer period.

Because that it is meant to be a tutorial, I will try my best to make the code as clean as possible. I will also justify all the design decisions I made and not just try to get it to work. When all is done, the tutorial can be found here