Sunday, March 15, 2015

2015 7DRL - Day 8

Failure is an option

On the morning of day 6 I had to do some soul searching. I needed to decide whether to alter my plan to make a more generic game or keep working toward the design I set out to make. I knew it was a high risk for failure if I kept working on my plan. However, I decided that it was better to put my efforts into making a game I was excited about that felt unique to me. The 7DRL challenge is to make a game but to me it is also to learn, challenge yourself and to have a fun. I did not alter my game design significantly.

I struggled a lot on Monday with the AI for the 4 competitors you race in the game. I am not an experienced game programmer so I was going about it the wrong way. I did find an approach later in the week that I thought would work better. That encouraged me to keep trying. I had a lot of fun on Friday going back to the AI and getting it to race. It was looking pretty good by the end of the day. I felt good about my progress and what I learned.

On Saturday morning I worked on the game menu screens. I tried stealing code from last year but it wasn't working so I threw it out and make new menu screens. Later I felt like I was stalling in finishing up my dungeon generation because I wasn't sure how to go about it. I started taking my random elements and made themed rooms. I had a factory theme with conveyor belts and smashers. I made a laser chicane room where you have to either take the long way around lasers or eat the damage and rush through. I made a spike room with either spikes on the walls or in the middle. I also had a random room that could throw together different elements. I put chances for many different configurations, enemies and decorations. This resulted in a large variety of rooms.

It was getting near the end of the day and I was still building my game. I saw the writing on the wall. I thought maybe if I kept pushing I could get it all wrapped up. Never mind that thorough testing was impossible at this point. I tweaked the UI quite a bit. Then I added a scoring system and a finishing condition. Yes, I was that far behind. It was approaching midnight and the game was playable but still in an alpha state. I would not have felt good about trying to cram it all together to call it a success.

Here is a picture of where it ended up:


I got a lot done and feel great about my experience participating in the challenge. I will continue to work on it but without the drive of the challenge it is hard to say how long it will take. I had a lot more features in mind that I threw out for the sake of deadline. Now I am free to add them back but don't have time set aside to work on it.

There are many reasons I enjoy the 7DRL. It gives you motivation to act in a way that conforms to the parameters of the challenge. Because of the time constraints you just try to get things done knowing that coming up with amazing architecture and a grand long term vision isn't needed. It also forces you to set aside time to focus on your idea. I would normally not have this much time to spend on any single endeavor. I am already looking forward to next year!

The other thing I am excited about is seeing all the other games that were made. I caught glimpses of them through the week in spare moments but now I can play some of them. It looks like there are some fun ones!

Friday, March 13, 2015

2015 7DRL - Day 5

Days 4 and 5 I had only a few hours total to work on my 7DRL. At the end of Day 3 I saw a big performance problem when I added lots of entities. On Day 4 I figured out that it was just taking time to go through them all since they all we part of the Turn System. I changed it to only include entities when the player gets near them. On Day 5 I added a couple of environment hazards - spikes and smashers. That was all I had time for those two days.

It is the start of Day 6 now so I am concerned about making the deadline. The goal today is to have a game. Just like last year I have a collection of parts of a game on Day 6. I was hoping to be further along this time. I am still figuring out if I need to take a slight direction change but I am thinking of going toward a more traditional Roguelike of going through levels deeper and deeper to the end. I am likely to bail on the racing concept at this point.

Tuesday, March 10, 2015

2015 7DRL - Day 3

Slow going so far...

I am making progress but things are not going as well as expected. I am running into a lot of issues that I spend time on instead of working on features. It seems like a lot of them are due to using the Entity system. I thought I had gotten enough experience with it to have it work fine. That isn't panning out. I have had a lot of game breaking bugs.

I spent several hours on day 2 trying to get AI working how I want it to but ultimately having to bail on the idea that the AI programs its instructions in advance like the player. It wasn't smart enough to plan five moves ahead. I had more ideas today about how to do it so maybe I will come back to it. I am very new to AI, path finding, etc. so I am learning many things which is fun!

I do have a working dungeon where you can move around. There is a basic enemy that you can bump to kill. I have some lasers that damage and conveyor belts that push. I can fill all my rooms with the above. I have a UI that allows you to see your instructions as you program them. I guess those are the blessings that I can count for now.

I am trying to decide if I stick to the racing motif or move another direction. My best alternative idea so far (to me) is to go toward a dungeon crawl where you program your robot in advance but you can predict most of how the environment responds. You are relatively weak so its essential to use the dangerous environment to fight enemies. This keeps with the main idea of having to plan multiple moves ahead.

Day 3:

Day 1:

Sunday, March 8, 2015

2015 7DRL Day 0

Robot Arena

This morning I am starting my 2015 7DRL project. The working title is Robot Arena. I thought for sure I would have a better name by now but we will see if something comes while working on it.

My concept is to make a game where you have to provide multiple moves at once and watch them play out. I gravitated toward the robot theme because of the idea of programming your instructions in advance. I have been debating about whether you are competing with other opponents (AI) or just working your way through a dungeon.

I also debated if your opponents program their moves or decide each turn what to do. If I can make it smart enough the first seems preferred. I am also figuring out if there are other mobs in the arena to battle. If that is the case then maybe the answer is both.

I would like to have fun items to use and obstacles to overcome. The other debate is if its more of a race or death match or both. I am leaning toward a race where its possible but not easy to take out opponents.

I had a bunch of notes/ideas I have been collecting working up to the challenge. I will post those below. I know I can't do all of them but it give me some things to draw upon. Last year I had so many more ideas than I had time to implement.

I am using the libgdx framework again this year and working in Java. I started with some code from another project I was experimenting with using a component entity system. I hope that does not limit me too much since I am just learning how thy work. It already has some of the basic tile drawing and moving around the screen bits but not much more. I am planning to use the Oryx lo fi tiles and make some if I need more.

Here is a drawing I did yesterday for the UI:

Here are my notes:

Program your moves 5-9 instructions at a time then executes in turns. Game over when you are destroyed.

The objective is to make it across the map to a finish area. Taking out opponents results in rewards and higher score. There are many special items and resources along the way but you are competing with others for them.

Design objectives: make the player feel the time pressure of the race (food clock of sorts), give them choices about how to get through the race and have a score to measure success. Design around score to make it a potential focus.

Player Choices -
  • Go all out and race - it is important that this cannot be a dominant strategy but should be an option
  • Objective to finish the race in first
  • Objective to take out other players and finish first
  • Objective to get highest score
  • Score - should reflect taking on additional challenges in the race

Resources - Damage and Battery

Damage system - damage works in the opposite way as health. The more damage you take, the higher the consequences. You can get repair kits to fix damage. Initial thought is to lose instructions but this might be a runaway leader problem if you are racing opposition.

Combat system - players can battle each other and take each other out of the game. Defeating a player earns you battery and maybe a special? Question: do new players get injected or once eliminated are they out? Maybe if its sufficiently difficult to kill them it wont be feasible or easy to get them all so it will balance because you would loose the race to try

Priority system - you have 1 point to allocate per turn in the round. If you don't assign points they are assigned 1 to each instruction. You can allocate more up front and zero later or any way you want. Turns then execute based on priority. First move is randomly picked among the 5 priority, then the 4, the 3 etc.

Map - space station/warehouse theme
There will ideally be multiple paths but the player doesnt know them in advance. Score bonus would be nice for area of map discovered and choosing difficult segments such as narrow bridges. Would be nice to have a variety of generators to create different types of maps - rings, point to point, maze

Game modes can vary? - not sure about this
Normal mode is race to the finish. You earn points for your placement. There could be other modes on different levels like king of the hill, capture the flag, a ball that scores bonus if you cross the finish holding it, key lock (each player finds their matching key)

Moves - 4 way movement
  • Move forward
  • Turn right
  • Turn left
  • Fire laser - is this a special or does it use battery?
  • Use special
  • Wait

Program all instructions in advance, assign priorities and watch the results.

Map is an arena with many features
  • pillars
  • multiple rooms
  • Walls
  • traps
  • Water (puts out fire or sinks)
  • Mashers
  • Lasers
  • Conveyor belts
  • Flame spouts
  • Warp points

Special powers
  • Stop time and inject code
  • Break - stops remaining turns
  • Cause players to lose turn
  • Gain health by powering down a turn
  • Rewind
  • Loop
  • Time warp
  • Teleport
  • Hack - change a players move

  • 360 aoe
  • Drop bomb
  • Drop trap
  • Oil slick
  • Fire trail
  • Mines
  • Laser
  • Smoke screen

  • Repair/health wrench
  • Teleporter

  • Items dropped around arena
  • Items added between rounds
  • Items are one use and you only carry one - mario cart style
  • Ways to attract people toward each other
  • Scoring system
  • More programming the deeper you get - maybe start at 3 commands to learn
  • Go with Mars rover theme over arena battle
  • Add hacking concepts to fight other robots - virus is DOT, etc
  • Announcer to MC the match

AI ideas
  • Random mobs
  • Predictable patterns

  • Are there mobs only, ai players only or both?
  • Should mobs have predictable patterns?
  • Does conflict give rewards/loot?
  • Could this be multiplayer?
  • Can you push stuff over cliffs? Would it die?
  • Hex, diag or cardinal?
  • Can you reasonably predict map elements?
  • What is win condition? Number of Levels? Last man standing? Modes? Score?
  • Do mobs/opponents program their moves in advance or decide each turn?
  • Should i use priority system and should it be tandom among people in a point tier or in a turn order?
  • the display could lay out the plans being programmed even if they aren't executed according to plan. Maybe its better not to so its harder to picture. That may be part of the fun.

  • Get character running around screen
  • Create map with random walls
  • Interface for programming turns
  • Basic AI that moves around
  • Start adding fun elements