ehgoodenough / papercut

A game about timeflux ninja combat.
5 stars 4 forks source link

Plan what to do next for Project Papercut #77

Open ehgoodenough opened 9 years ago

ehgoodenough commented 9 years ago

@skylarjhdownes @EdKerscher @eCorbeau, leave comments below. What should we try to target next with this project? At the moment, Skylar and I just fixing bugs here and there. What would you like to see come from this weekend prototype?

eCorbeau commented 9 years ago

From my perspective, it depends on whether or not I want to hop into learning Javascipt. If I do, then implementing a procedural level generation algorithm would be a simple way to learn the language. Otherwise, I do not have any substantial plans.

Also, ProcJam is coming up next month and I'm considering doing a game for it.

ehgoodenough commented 9 years ago

@eCorbeau, I'm still interested in what sort of level designs we could have. At the moment, we just have sets of monsters, but I'm interested in adding support for tilemaps, which would complicate the monster behaviors, not to mention procedural generation. Thoughts?

ehgoodenough commented 9 years ago
  1. I want to experiment with the flux. Maybe the ninja shouldn't slow down as much during flux, since some players expressed how frustrating it was to be unable to move during the slow parts. Or maybe the flux shouldn't be as frequent; the game is played in real-time for more than just a second before slowing down.
  2. I want better monster behaviors. I'm really happy with the archers, but the warlords need a lot of work. Their sword aoe should be clearly conveyed so the players know it's about to hit, and their shield block any attacks from the front. I'd also love to add some more monster behaviors.
  3. I want a better game flow. I don't want the game to reach that point where there are only a few monsters left on the screen, and it's just a chore to kill them. Should a level be beaten when all the monsters are dead, or just when most of the monsters are dead? Maybe they just have to survive a certain amount of time from waves upon waves of monsters?
eCorbeau commented 9 years ago

Re: procedural tile-based terrain maps: That's more of an AI issue than a map generation issue. Generating maps is something that I have plenty of experience tinkering with; the only reason I didn't go for it during the game jam is because I don't know javascript and other features were a bigger priority for the team members who do know javascript. If I'm implementing this feature as part of learning javascript though, then it's not a big problem to add basic terrain as part of level generation. It would be barely more complicated than adding an additional type of monster.

eCorbeau commented 9 years ago

Also, part of my issue with fixing some of the complaints about, or shortcomings of, the flux system is that I feel we begin to approach either Necrodancer or conventional bullet time. Which isn't a bad thing, but it isn't the concept that you originally wanted to play with. If it was just me, I'd almost certainly jump to either outright turn based gameplay or player-triggered fluxes.

skylarjhdownes commented 9 years ago

There's a mechanic in Asura's Wrath, and probably a lot of other games, where you fill a rage bar and fire a limit break to end the level. That's one possibility here. I like the idea of experimenting with longer periods of real-time. It might also help to have a more in-your-face way of indicating that you're in slow-time. Color shift or music or something. ProcJam sounds neat.

ehgoodenough commented 9 years ago

I'm going to take our current prototype and experiment with three different types of timeflux:

  1. Player Controlled Fluxtime; they hit a button to activate fluxtime.
  2. Imperfect Sinusoid Fluxtime; flux (as in our current prototype) happens automatically, but with significantly longer periods of realtime and fluxtime.
  3. Asymmetric Fluxtime; somewhat turnbased, so monsters move for a period, then ninja moves for a period.

I just want to see which is most engaging from a player perspective.