itch.io

Nice progress!

Heck yes, look at that dedication! Awesome work!

Right now, Processing. I probably won't get a chance to move it to anything else during the jam, but it's a good way to prototype. And yeah, that's the idea!

Thanks! Yeah, I didn't explain it very well, but basically you can 'shoot' your puck in a direction or assume a defensive stance (aka, your mass is temporarily infinite so the other player's puck will just bounce off). Trick is, you can't shoot again until you've stopped,  and recovering from a defensive stance takes some time as well, so there's a risk/reward for your actions. To score, you have to knock either your or your opponent's puck into your opponent's goal! Of course, these mechanics are subject to change via playtesting, but that's the idea anyway.

Alright, update time. Good news and bad news.

Bad news is, my weekend is basically shot - I spent almost the whole time writing, then rewriting a player-to-player collision detection system that already worked well enough because of a situation that will probably never happen.

Good news? It works.

First, I'll explain how the first version of the collision detection worked so that I can explain the problem situation and the resulting new collision detection system. Initially, I detected collisions between two pucks based on the distance between the center of the pucks at the positions they'll be on the next update (based on velocity). If the positions were less than the summed radii of the pucks, boom collision! ... well, MOST of the time...

The problem that I'd theoretically run into if the pucks sizes were small enough relative to their velocity is: What if the pucks had sufficient speed to cross each other's paths so fast, that on the next update, they're already past each other? This may be easier to visualize if, say, you shot a bullet at a wall. At a given frame N, the bullet is ALMOST touching the wall. At frame N+1, the bullet's velocity is SO FAST that the bullet's updated position is on the other side of the wall! Technically, they never collided because there was no validation between updates! With my old system, this situation COULD POSSIBLY MAYBE occur.

The new system meant to alleviate this issue, was found in Mathematics for 3D Game Programming and Computer Graphics, Third Ed. by Eric Lengyel, chapter 12 section 4. I don't want to bore you (any more than I have already) with details, but basically, given initial position and velocity, you can know when two objects on a collision course are going to hit. Given this impact time, you then have the positions of the objects at that time, and can then do your impulse resolution to 'bounce' get the objects to get them to move away from each other. SO this new method of collision detection doesn't have any holes!

The aforementioned impulse resolution was next. I found the solution to this in an article written by Randy Gaul - How to Create a Custom 2D Physics Engine: The Basics and Impulse Resolution. Now my two pucks bounce off each other in a realistic fashion and I'm guaranteed not to miss any possible collisions!

Why, you ask, did I spend practically my entire weekend doing this? Well, 1) Math is hard. I don't remember much from college, so just figuring out what was going on at first took most of my time. 2) I didn't plan on it taking this long. I definitely thought about just using the 'good enough' system. However, I thought about future-proofing: What if I add some super-speed power-up? Or I have to limit the simulation clock for performance-sake? 3) I learned a lot, which is part of the reason I'm participating in the jam!

The rest of my weekend was setting up a version control repository for myself, but also for my friend/roommate/co-worker who's agreed to help me out! He spent some time looking at and integrating a controller library for Processing called Game Control Plus. Right now it just detects different controllers, but it's a great start. Having controller support is practically essential because analog control gives you finer-tuned controls over angles AND I'd like this game to be local multiplayer at some point. Having a teammate will definitely help this project along faster!

Hey, good job so far! I remember one of my first games in C++ and SDL 1.1 way back in the day and it was tough, so mad respect!

A couple of suggestions if I may:

1) Have you thought about using a 2 dimensional array for your tile layout? I think it would be helpful since you'll be able to directly address any tile with that quick math you already figured out.
For example, since each tile is 64x64 and you know the absolute position of the player, you can find out the tile the player is in like:

tile = tiles[(int)playerX/64][(int)playerY/64]

So if the player is at x = 139, y = 73, the current tile is [2][1] or the third tile to the right and two down. Now, you only have to check 8 tiles to see if they're walk-able or not, and each of those are directly address-able as well! Of course, since you're allowing free movement it's not quite that simple since you could be on the border of two tiles, as you've discovered...

2) How deep is the 'interact' mode? Is it an actual state the player can enter? If so, can your player just not accept new velocity info while in this mode? Having not seen the code I'm sure the problem is tougher than this, but if you want some help debugging, I wouldn't mind looking at any code snippets you like to give!

PS

Oh yeah, your earlier issue with framerates and animation speed is exactly why a lot of old games are unplayable today because the simulation running on modern computers is so fast. You're right in that games today typically separate the simulation speed (or 'tick rate' in a multiplayer server) from the render loop. :)

Haha, I definitely didn't explain it very well, but hopefully it'll all make sense once I make some more progress!

Oh yeah, I'd love to do local multiplayer but I'd need good analog controls so you can get the angle just right for that perfect shot. Processing just has M+K support, but there's a library I'm considering implementing that will give me controller support, so hopefully I can make this happen! Thanks for the words of encouragement!

Wow, I'm late posting this, but here it goes.

Hi, I'm JeevesPleez. I've been a 'professional' programmer for 6 years now, but haven't dabbled in making games since 2010ish. I've been getting back into it recently because my work projects just aren't as interesting as they used to be and I hope this will help me remember why I became a programmer in the first place...

My idea for this game, which I've had for a little, while is (tentatively called) Mockey, or Mock-Hockey, a 1 on 1 game where you're the player AND the puck. The idea is to balance your risk vs reward by knowing when to play defensively or take a shot at the goal. It doesn't fit the theme of the jam, really, but when I was growing up I always DREAMED of being a video game programmer, so that's my excuse!

The prototype is written in Processing, a handy java-based shortcut for a lot of grunt work on getting pixels to the screen. It's far from an engine, however, which gives me a little freedom, but doesn't help much outside of drawing stuff. I like tinkering though so hopefully it works out...

I'm a few days behind, but I didn't get anything accomplished Monday or Tuesday because I came home from work drained and not entirely enthusiastic to continue programming, even on something way more interesting (database programming will do that to you...) so there's not much to catch up on.

Progress so far is a blank play area, player-controlled puck and an (EXTREMELY dumb) AI puck. Most of my work has been getting the physics set up and collision with the wall working correctly. I ditched getting explicit double-buffered rendering working, along with a good framerate cap and decoupled simulation/render cycles -  I decided it was a bit out of scope for now, and processing wasn't playing along nicely.

You can see me controlling the player puck with the mouse, testing a couple of the right and bottom bounds. Seems to work pretty well.

Tasks to-do are: 1) puck-puck collision  2) goals, and resetting the pucks after a score. Having an end-state would be nice too  3) actual controls, including blocking. The idea is to let the player be able to stretch into a defensive posture while stationary. 4) smarter AI  5) polish for that sweet, sweet, 'game feel.'

We'll see if it gets much farther than this prototype by the end of the jam, but I'd like to start leaning the D programming language and writing a software renderer from scratch. Doing this will help me learn a lot of graphics techniques that get taken for granted now-a-days. Like I said, though, it's probably way out of scope for the jam (yes, I know I said I'd do it in the initial survey, but I was drunk at the time. Oops).

Thanks for reading - good luck with your projects!

Good work! Especially for a self-proclaimed "complete beginner!"

Yeah, your 'left' and 'right' variables most likely override the default left and right variables (I'm not sure how Renpy works exactly). It's a concept in object-oriented programming in which an object can redefine functionality of a parent object. For example, you can define a car with a top speed of 100mph, but then you could define a sport car, which is a car, but it's top speed is 150mph. You should be able to call the overridden variables with super().left and super().right (not sure if it'll work like this in Renpy, but it should in python so ... maybe?). Honestly, defining your own like you said is probably your better option here. You could, say, define 'midleft' and still have the default left, then you could have two characters on the left side, one left and one midleft, without drawing completely new sprites! (good for the 'Hey, my friend here thinks you're cute' situation, maybe?). That's probably way more than you'd ever care to know about that, but hopefully it helps!

Again, great work! Hopefully you feel better too!

Hey, sorry to bring you back to three days ago, but I had a quick question regarding the collision and state machine system you have for your character's attacks - from what you described, it sounds like what you need for a successful kill is for the to be in attack mode, which is moving downward. If you collide with an enemy from the side while in kill mode, does it still kill the enemy? You may have to, once you know you've collided, check the positions (plus hitboxes) of each character to make sure the player is above the enemy. Obviously I can't see your code, and you probably thought of this already, but hopefully this helps?

Other than that, awesome job! You're making a lot of progress in such a short amount of time! Also, I like the FPS counter in the corner there - priorities, you know? Haha!

Wow! I remember making a shmup in C++ and SDL something like 7 or 8 years ago now and getting close to where you are now took me about a month! So, yeah, definitely don't feel pressured to work more than your recovery allows - it's looking great so far!