Brackeys Game Jam 2020.2 Day 2

2020-08-02 1005H EDT

I think I’m actually going to spend the time to put together a skeleton and some stories. I’d like to get a rough idea of the size of this project. I have a suspicion that it’s too big.

2020-08-02 1135H EDT

I built out a rough backlog, which made me make a couple of decisions.

  • I decided to use the URP template in Unity because it’s the easiest to use and I wanted to add a little juice with Shader and the Effects Graph.
  • I’m keeping the backlog in the docs folder. A simple to-do list is a fine Kanban board for a single developer in a game jam.
  • I decided what my minimum submission would have in it. It’s pretty scaled down, but I have myself completing that on Wednesday (day 5). We’ll see. Overall, I think it’s possible to complete the project which was the purpose of the backlog exercise.
  • I’m going to keep a log of my decisions in the devlog as opposed to a slightly more formal ADR type process. I think that’s fine for a solo game jam.
  • I’m going to have to compromise on the details to get to the submission line. I plan to go with the easy route, and if there’s time there are a lot of tricks I can use to add some polish to the game. What might suffer unfortunately, in addition to polish, are the variety of problems and the variance in the result phases (i.e., the different ways of dying). Up until the submission deadline, I’ll be trying to add different problems and results.
  • I’m going to use the dungeon and character assets I purchased from the Synty Store, because that alone sets this apart. It only adds a small amount of effort to make this 3D vs. a 2D top down (given that I already have the assets of course).

2020-08-02 1308H EDT

It just occurred to me that my original flat dungeon idea will result in dead-ends, and if I keep the no re-entry rule, that means the generation algorithm will produce impossible to solve dungeons. The solution would be to change the algorithm to a more classic Zelda like dungeon algorithm, but with no re-entry a similar problem occurs; you can essentially paint yourself into a corner and make an impossible to solve dungeon. I must have biased my paper prototype somehow to have missed this.

I could just cheese the algorithm and let you double-back into the same space, but with a new autogenerated room. For example, exiting North, West, South, and then East would put you in the same physical space as the starting room.

For the jam, I think the easiest thing is to keep the generate on the fly approach, but to be a little nicer. Every exit will be a stairway down. Essentially, every room is its own level in the dungeon. This has an added benefit that I can make the stairway a sort of loading screen if I need it to generate the next room. So you could end up in a physical space below your starting position, but you could never collide into a previous room. Also, because of the no re-entry rule, the exits not taken don’t generate anything. This is still a little cheesy, but a little nicer. You also get to see your character going down corridors, stairs.

2020-08-02 2315H EDT

It was a busy day, and I wasn’t able to complete the plan. We’ll see how much further I can make it tomorrow even though I work. The upside is that a lot of the remaining tasks are code. I’m a little nervous about finishing.

Today completed the basic UI structure and created the 9 directional rooms and the final reward room. I decided to create prefabs and join them together, versus completely procedurally generated rooms. It would have taken me a lot longer to build the rooms that way. The way I’m considering building a room now is almost like a pattern language approach. It should work out well. Variance is definitely something that’s going to suffer in the final product of the jam.