itch.io

Vampire Survivors is a non-turn-based rework of at least one much older turn-based game that's otherwise exactly the same, so you've actually taken it back to its roots! ;)

Unfortunately, I haven't been able to find that old game yet; I found this page while hunting for it. I had it almost three decades ago on Mac in the Performa days.

I'd further point out that "required" isn't really a productive way to look at this jam or anything about it; if you think of it that way and miss an update, you can start to feel like you've somehow failed.

Like you said, it's a good way to motivate yourself -- and, if you miss one, taking a more positive angle, like "well, better have a good one for tomorrow," can help avoid turning updates into some sort of slog or a source of anxiety.

For me, having a set of goals and then continually breaking each one down into tasks until any given task should take less than a day to accomplish helps avoid days where there's just nothing to talk about. It may not be much, but "my little dude/chick/alien/hamburger now actually faces in the direction it's moving" is progress, and progress is progress.

I'll second not being a fan of this kind of post, but after checking them out... I went ahead and picked up the lot. Looking forward to working with these. :)

For example, spacewalks are very much outdoors.

That's an interesting idea. I'm usually not a fan of quick time events, but for something like "flip the switches right when the engineer tells you to or you'll fail to repair the oxygen tank," that might be one of a few minigame formats you could use as gameplay-varied reasons for spacewalks.

Because I noticed there were dupes and some formatting oddities, I felt like this was necessary...

http://peppers.ifsh.be/ad-hoc/normalized-band-names.txt

Translating a game with  “google translate” is a bad idea.

It's certainly not ideal, but if it's a choice between some "what... oh, haha, that's not quite right" moments and "oh, I can't even begin to read that; on to the next game," the compromise seems pretty good.

If you prepare language support and open source your game, others can add that later.

Are you seriously suggesting this as advice for a game jam?

Wow, high praise for half a game! ;) Thank you very much!

Ha, yeah, it does need a tutorial. Unfortunately, like the sound, it's something I just didn't end up getting to.

Regarding the graphics, since it looks like I haven't mentioned it in the comments for this submission, the sprites are from Henry Software.

The idea was that it'd be a strategy consideration where you'd choose between units that could potentially counter what your opponent had played, with the fact that you couldn't explicitly pick actions being a major part of gameplay. Unfortunately, it didn't get that far, so the intent doesn't really come through.

Yeah, without some explanation up front, I can definitely see it being confusing. It also didn't end up rendering quite the way I expected, so it's even less clear what's going on in the WebGL build than in the Godot editor.

The cards do have different atk, def, and HP values, but yeah, there's too much randomness and not really any meaningful strategy. It pretty much just got to the point of "you can technically do the important stuff" without any nuance or interesting mechanics.

Well, I don't think I'm going to get audio in, but I've put up the game such as it is.

https://internationalfish.itch.io/magic-the-derezzing

The core loop is there, so it's at least playable; didn't get as much done as I wanted, but I'm glad I got it to the point of being submittable.

Thanks! Wish I could take credit, but they're from this asset pack:

https://henrysoftware.itch.io/pixel-mob

The artist has some other really great stuff as well.

Almost to the point of playability. It might actually get there today, depending on how much work gets in the way... pretty much all of the transitions are in, deck and hand management are in, and combat works (as above).

If I can get the last few bits there worked out, it's really just down to win/lose UI and then audio. With interview prep to do tonight and the interview itself tomorrow, though, all the nice extras are out the window. Ah well, par for the course. :)

Looking great!

I'm also getting a glitch where the boss stops creating it's hitboxes if you restart the game a few times. 

Impossible to say for sure, but this suggests to me that either the boss itself is not being destroyed and reinstantiated or something to do with the hitboxes is being stored in a place that isn't being cleared out before each fight. Generally, I'd expect this to be the result of stale state.

Good luck, keep it up!

Awesome! I love clickers, glad to see someone doing one for this jam! Your gif looks great, can't wait to check this one out.

Well, here you go: Automated combat between the player's units (lower left) and the computer's (upper right). This part happens with Highly Advanced AI, which is to say the units pick a random unit on the other team to attack. It's kind of hard to see the effects, even though I turned the capture rate up... ah well. The numbers are their levels, current all 4. 4 is a good number.

This one has a lower capture rate, but shows a little more combat (the pause in the middle is me manually starting a second round). Since it's so exciting and unpredictable!

For now they're battling their little hearts/pebbles/lobes out on a boring field of brown construction paper, so that obviously needs some work. And the whole UI thing, since someone is supposed to actually play these things. But it's some fun progress.

Coming back after quite a while for a pretty good update.

• The above click-and-draggable container is working really well after some tweaking, and the library should have just relatively minor tweaks before it's usable.
• Battlefield rendering is working well, including:
  • Graying out units via shader so the attacking/defending units stand out
  • Flashing the attacking unit old-school FF style
  • Shaking the attacked unit
  • Level display per unit

It's not amazing, but I'm pretty pleased. Despite all the time I've been wasting on Diablo 3 for the last week, I think I should manage to get this to a playable state by the deadline! Lots of tying things together to start doing.

Pretty fun to see you taking the series in an entirely different visual direction. Good luck, looking forward to playing it!

Nice progress! Ridiculous as it is to say so early, it gives me sort of a Flashback vibe, at least based on the environment and your description of powering on doors to advance.

Despite some arbitrary ugliness with event handling, I managed to get a click-and-draggable list working in Godot... I was so frustrated yesterday that I didn't put the project into version control, so I can't integrate this code yet, but when I get home it should be easy enough.

It's pretty much the opposite order I'd intended on doing this in, but hey, no time to complain!

Wow, and I thought Unity was bad... the main reason I was open to actually switching to Godot right at the beginning of this jam was because the Unity 2018.2 release on Linux is unusable, and because VS Code in Windows is inexplicably stupid compared to its Linux release, which is really, really good.

Now... I don't know. I'm finding myself absolutely hating GDScript, which is a sad excuse for a scripting language, and people are absolutely right about the state of documentation for Godot. It's abysmal. And the node types... just... ugh. They seem really great! Seem. Trying to actually get them to work as advertised, though? Think a ScrollContainer should be a container that scrolls with its contents? It seems to think so, too, but it's idiotically difficult to get that to work. And it seems not to allow removal of the scroll bar... or to support mouse click-and-drag... in many or most common scenarios.

I think I'm going to see if I can implement that behavior in a reasonable amount of time using signals, but if not... screw it. I'll just go back to a version of Unity that works for more than five minutes at a time in Linux and give up on actual pixel perfection.

Thanks! Yeah, I'm hoping to just get the basics in, that's really all that matters. Get the thing playable.

I switched to Godot because fighting with Unity is all I ever do with Unity... so now I'm fighting with Godot.

...and it turns out Unity 2018.2 for Linux is an absolute trash fire. Everything from rendering failures to UI crashes. Great... time to boot into Windows.

For my second serious jam attempt, I'm attempting not to fail to make a really simple deck builder. Basically: You start with a few cards in your deck and an empty library, and you fight a really stupid AI with a similar deck. If you win, you get a leveled up version of one of his cards. Playing a card (usually, and to start with, only) spawns a unit that will fight the AI player's units automatically, so all you do is pick which card to play at the beginning of each round.

I like to divide work up into phases, so here are the ones I'm starting with this time.

1. Initial setup
   1. Cards
      1. Define and implement Card data structure(s)
      2. Define and implement Unit type
   2. Battlefield
      1. Piece together background sprite
      2. Create battlefield scene
         4 rows, 4 cols, 0px borders: 16x16px cells
      3. Basic battlefield manager script
         1. Start with placeholder static player/enemy Decks; only attack-type Units, no Instants
         2. Shuffle Decks
   3. Rendering
      1. UI corner card rendering with deck count
      2. Player hand overlay of top three Cards
      3. Sprite rendering of Unit on battlefield
2. Punchline
   1. Play a card
      1. Implement Card click/touch in overlay
         1. Fade out overlay
         2. Remove Card from deck
         3. Instantiate and render Unit (fade in)
   2. AI intro
      1. On AI turn, play a Unit card if possible
      2. Instantiate, fade in Units same as player
   3. Initial round
      1. Implement 3 or 4 board positions for player and AI, if not already done
      2. Alternate player and AI playing Unit cards for 3 turns
      3. Third turn: Start enforcing must-play rule
         1. If no Units in deck, lose
         2. If Unit(s) in deck but none in hand, require discard until one is found
   4. Unit on Unit action
      1. On third turn completion, start fight/draw process
      2. In order played, Units select and attack enemy Unit
      3. Trigger next player, AI turns
   5. Win, Lose, or Draw
      1. Lose/Draw screen (same result for player)
      2. Win screen
         1. Show and award player one random card from opponent’s hand
            1. Level up this card to initially make winning useful
         2. Create dummy card management scene
         3. Redirect player to card management
3. Come with me if you want to… die
   1. Deck/library UI
      1. Two rows of tabs on top; horizontally scrolling card listing on bottom
      2. Implement live filtering for primary/secondary tabs
      3. Need UI element to enter fight
   2. Card click overlay
      1. Move card to the left and show buttons
      2. See pixel layout at bottom
      3. Deck add/remove, trash buttons
4. Heal/defense
   1. Add/implement this type of Unit
   2. Test with player deck
5. Instants
   1. Add Instant type cards and effects
   2. Implement in battle scene
6. Superficial Intelligence
   1. Teach AI to heal
   2. Teach AI to use instants

Here we go!

Love the creativity. 4x4 pixels is a ridiculously brutal constraint.

While that's an interesting idea... the resolution is kind of the entire point. I'd definitely be interested in a "you have this many pixels to work with in whatever configuration you want" premise, though; that could be a great jam by itself.

I love your work, and I've picked up this as well as several other assets here... but do you have any plans to put out a set of human/humanoid animations similar to this? I'm not a fan of the Hero, so I was wondering if another non-mob offering might be in the cards. Thanks!

For example; people using Unity, GameMaker, etc have very little prep as all the tools are integrated, compared to those not using IDEs who have to sort out all sorts of dependencies, libraries, build systems, etc. Things like that shouldn't have to be done to any specific jam time, if they was you'd pretty much end up doing the same thing again for every jam.

If you're doing the same jams all the time, yeah. I've personally never made a 64x64px game, and Unity doesn't exactly handle that perfectly out of the box, so that's something I've been looking into beforehand.

You can always technically start a game jam if there's no theme being held back... but it's against the spirit of the thing, and not how it's intended to be done. Kind of takes the fun out of it.

What you can and probably should do -- at least if I'm understanding right, and this is the same for a lot of other jams -- is start your planning now. I'm in the middle of defining my game loop, gathering assets, and laying out how I'll organize my UI and transitions. There are also likely to be details to work out specific to your development environment, depending on what you'll be using to write your game, and those are problems you can research without actually starting your project.

No code gets written that'll actually go into the game, but prep is important, particularly when you only get two weeks of actual implementation time.

(...hile back that I'd like to use.)

Great, thanks!

I'm starting to feel like a broken record, because the answer is pretty much always yes... but the summary says "All assets and coding should be done in the time frame."

Is it fine to use either freely available graphics and sound, or graphics and sound we otherwise have the rights for? I have a couple sprite packs I bought a w

While I'd say your points are mostly... on... point, I'd disagree that pieces have different value in a concrete way.

Any piece's value at any given time is directly related to how much it contributes to protecting your king, attacking the opponent's king, or both. At the start, your pawns are worthless by this measure; however, further on in the game, they can be instrumental in limiting an opponent's movements and avoiding potential check situations. But that value, and all other pieces' value, are constantly in flux -- and your opponent's attempt to figure out which are the most valuable pieces to you is the process of trying to read a player's next few moves.

Which I think speaks to Greg Karber's opinion above: The king's importance creates the central goal and drama of the game.

If you want it to feel close to the original game, you could start with chess itself and do something that adds or removes restrictions to or from the core mechanics. Examples:

• Let players position their pieces before the match, possibly taking turns and being able to see each other's choices
  • Allow limited customization of how many of which piece a player can have
• Remove the restriction on pieces moving through each other
• Add something like the "king" mechanic in checkers to allow pieces to gain or change movement options
• Have board size variations to fundamentally change the game without changing the rules
• Instead of removing a piece from the board, switch its owner and put it where the piece that took it was

The zombie survival game? That was one of the first ones I did. I think some of it is a bit out of date and/or suboptimal, as it was done before the Tilemaps feature got added; I also found several places where the instructions were unclear and there were mistakes in the sample code. Honestly, those things weren't so bad they killed the experience, because they did force me to dig around and correct the issues myself. So while it's not bad, Tilemaps (and the poorly-documented ScriptableObject approach to overriding the Tile/TileBase classes to get your own tile behavior) are really valuable additional research items.

So far:

• You can move (yay!)
• Enemies can move (boo!)
  • Because I haven't bothered to fix the proximity test, every enemy on the entire map will always move towards you (serious boo!)
• You can attack (yay!)
• You can be attacked (boo!)
• You can kill enemies (yay!)
• Enemies can kill you (eh...)
  • Since there's no start or end screen yet, I decided to just decrease your opacity and your attack temporarily. So you become an impotent ghost that enemies still chase and attack but can't kill any further. Which, I'm not sure, I think I might like.
• Dungeons are randomly generated (well...)
  • I attempted to translate an algorithm that's hosted on RogueBasin from Python to C#; it... mostly worked, but there are still rooms that are disconnected, so you can get marooned. Which is probably not ideal.
• Items can be picked up and dropped or equipped
  • Equippable items can contribute to any, all, or no stats, based on how they're set up

I'm at the end of my time off, so from here on in it's just nights until next Saturday. Hopefully I can get some more work done on it, but it won't really take much more to make it a success, even if it's a marginal one. :)

Interesting! Could you expand on the gameplay a bit? A gameplay gif would probably clear things up, but that might be a bit premature. :)

This is my second (attempted) 7DRL; last time I tried a simple roguelike in Java for Android. I got randomized dungeon creation working, and movement... partially working... but my code at that point just wasn't going to be workable. So that was that.

This time I've been learning Unity, and one day in, I've managed to actually get the basics working -- movement, combat, and dungeon generation (well, it's just a square right now, but the plumbing is there to plug the algorithm into). So that's exciting!

Regarding the name, aside from the obvious but mostly irrelevant  nod, my intention is to make the game a really, really simple RL with a minor and not-particularly-compelling twist in that elemental item set bonuses will result in a secondary elemental attack and/or attack/defense bonuses based on elements. We'll see if I get that far, but at this point I'm pretty happy with the rate of progress, and I'm certainly learning, which is the point anyway.

I'm using Oryx' 16 bit fantasy sprites. Current status:

Here's the project page.

Good luck to all of us!

Wow, that's some serious progress! Loving the ScriptableObject potential, that's pretty exciting.

Yep, I'm using Unity. Thanks for the references! Unfortunately, I'm really stuck. I have two websites to transition to new servers by the end of the month (so... uh... tomorrow), and they haven't been tested nearly enough by the client. Even if they were rock solid, the transition is going to take all of my time for the next couple days; since they're not, it'll probably be more like the rest of the week plus the weekend.

I'll at least get a video of what I have before it hits the cutting room floor (there's really not much to play). Hoping this gig quiets down in time for me to take another shot at the 7DRL; got the planning for that in place before the excrement hit the wind machine.