Distractions?

[Shane]

I'm getting a bit down on myself. I'm not really working at the moment because a lot of things I can't do, and a lot of my friends and family are busy with life. I'm thinking about just investing myself in something really time consuming, like game development.

 

[HyruleWarrior]

Yeah, software development is certainly a great way to immerse yourself into something if you've got alot of time to kill. I used to be a programmer myself (though not for games though unfortunately) -it was more office related PC software that I was doing, and I don't work in that field anymore. i did love it to bits though, and I miss it! My main problem now though is that as I do a totally different job now, I just don't have the time I used to for programming like I once did, and that can be a viscous cycle!) But being able to create your own stuff, while challenging at times, is definitely something that always feels very rewarding mentally. So if you're feeling down at the mo (while I'm sorry to hear that btw), I'd say that you've picked a good choice of something to get stuck into! (that being said though, with the Nintendo Switch coming out in a few weeks, you may find that the time on your hands that you once had, may not be a problem anymore!)

Have you done any game development before? Or is this going to be a totally new venture?

 

[Shane]

I've made small games like programming the following Windows PC game: https://gamejolt.com/games/chronicles-of-bats/176230

Do note that the collision detection of this game is a bit... off... at times. I never fixed it.

Also, I'm waiting until around Christmas to get a Nintendo Switch. I bought an NVIDIA Shield TV instead.

 

[HyruleWarrior]

Cool. What language did you program this one in?

 

[Shane]

I just used a program called Construct 2 which gets you up and running faster.

The algorithm I used for collision detection for jumping on an enemy's head was something along the lines of "bottom of sprite.y - 16" but it obviously wasn't good enough.

 

[HyruleWarrior]

Yeah, if the way the sprite's outer dimensions are being calculated using a set number, then I could see how that could happen, especially if the dimensions of the sprite change. The solution to that would be to get the sprites's outer dimensions to calculate dynamically in real-time based on its current size/state, which would allow for any changes (no matter what your sprite happens to be doing in the current animation sequence).
So instead of doing bottom_of_sprite.y - 16, you would essentially change it to something along the lines of bottom_of_sprite.y - height/width (the height/width part being whatever it was the 16 was meant to represent).

if that parameter didn't currently exist, you'd simply need to add a function so that it would calculate it and spit out the answer, so that you could use it in your collision detection algorithm.