SyntaxBomb - Indie Coders

QuoteI've been having issues with my collision detection, trying to get it perfect but think I'll have to call it good enough or the rest of the game will not get finished! 

Lol, yup, been having that fight too. Because my main character is bigger than my tiles I've been deciding a happy medium between what I allow as an overlap and what I don't.

p.s. nice work on the sky dithering shading.

Quoteok back on track.

Good good. Just make sure the pepper spray collision is enough to engulf the rage of "I HIT HIM!!! I HIT HIM!!!"

QuoteCan you tell what it is yet?

A retro console? - I have no idea with these puzzle things

QuoteEveryone else stuff looks mighty fine

There is some mighty fine looking stuff, can't wait to have a play. I've avoided posting any "spoilers" but I'm quite tempted to join the trend and may post a teaser video next week.

Here's the sound and keyboard binding screen with debug grid layout shown:

Quote
Good good. Just make sure the pepper spray collision is enough to engulf the rage of "I HIT HIM!!! I HIT HIM!!!"

I always thought more along the lines of I WAS ON THAT LADDER!!  MOVE DOWN DAMN YOU!! 

Quote
There is some mighty fine looking stuff, can't wait to have a play. I've avoided posting any "spoilers"

Yep, sure is.  Yeah, I've only posted an early WIP, and no more.

At the moment the bats (Captain Caverns arch enemy) needs hitting square in the teeth to blow up. Need to work on some explosion gfx though....

Quote* You can now "pickup" hostages and drop them off at the HQ

Choplifter ... love it! (looks awesome)

QuoteI always thought more along the lines of I WAS ON THAT LADDER!!  MOVE DOWN DAMN YOU!!

Donkey Kong! lol (or Rodland! )

QuoteNeed to work on some explosion gfx though....

Me too

I have not even started on collisions and my missile(s) or explosion(s)

Still working on drawing my cheesy background graphics, and man oh man are they looking bad. (my cars will definitely get a laugh) 

Currently working on mouse controls for menus, plus keyboard support. NASTY!

More time spent with UI stuff than the actual game, Design, placement, interaction and more 

speaking about controls :
an important thing which has not been mentioned, is that, when you play some games, the controls are setup for a qwerty keyboard and therefore it is difficult to move forward/backward/left/right or up/down/left/right, if the keys are not positioned as they are supposed to (for example with a azerty keyboard)

So guys, please include at least a config text file, that we can edit to change the keys to be able to play without difficulties. Thanks !

Quotespeaking about controls :
an important thing which has not been mentioned, is that, when you play some games, the controls are setup for a qwerty keyboard and therefore it is difficult to move forward/backward/left/right or up/down/left/right, if the keys are not positioned as they are supposed to (for example with a azerty keyboard)

So guys, please include at least a config text file, that we can edit to change the keys to be able to play without difficulties. Thanks !

I was planning on use W-A-S-D for the movement, and it appears that the QWERTZ and QWERTY will have no problem being compatible with those.

The AZERTY will need a minor adjustment, having the Z replacing the W, and the Q replacing the A, so I will just try to make W or Z for up, and Q or A for left, with the S and D remaining the same.

That way the French should be able to play without needing a config file for input.

I guess letting them choose their own keys for key mapping would be best though, but I would rather code it for them to choose with the UI rather than have them manually changing a config file.

Quote from: iWasAdam on December 29, 2017, 11:30:47
Currently working on mouse controls for menus, plus keyboard support. NASTY!

More time spent with UI stuff than the actual game, Design, placement, interaction and more 

Can't agree more - it's a real chore.  Fortunately I'm almost finished the UI - just need to make mini versions of the tracks for the track select menu and I can move on to a bit of polishing and bug fixing

 

 

 

I see your Options allow for a 640 x 480 screen resolution.

Isn't that a rule violation of the 320x200 requirement?

And on a side note:
I guess I think of Arcade Machines when I think of retro games, so fancy menus for player options were not in my original plan.

Quote from: Conjured Entertainment on December 29, 2017, 17:45:32
I see your Options allow for a 640 x 480 screen resolution.

Isn't that a rule violation of the 320x200 requirement?

And on a side note:
I guess I think of Arcade Machines when I think of retro games, so fancy menus for player options were not in my original plan.

The screenshots are 640 x 480 with letter-boxing of 40 pixels above and below.  The pixels are 2 x 2 and the movement is 2 x 2 so this is perfectly fine according to Qube.  I allow for a max of 1280 x 1024 which gives me 4 x 4 pixels and movement and a letterbox of 112 pixels above and below.

They're hardly fancy. I tried to copy the 'Upgrade' one from the Arcade Super Sprint .. which is pretty retro imho.

QuoteThe screenshots are 640 x 480 with letter-boxing of 40 pixels above and below.  The pixels are 2 x 2 and the movement is 2 x 2 so this is perfectly fine according to Qube.  I allow for a max of 1280 x 1024 which gives me 4 x 4 pixels and movement and a letterbox of 112 pixels above and below.

So, 320x200 virtual resolution does not refer to the size of the screen during game play?

So, we can use a 1280 x 800 resolution or other size, as long as it is a scale of 320x200?

I took the 320 x 200 as being the resolution for the game to be played in.  that changes everything

QuoteThey're hardly fancy. I tried to copy the 'Upgrade' one from the Arcade Super Sprint .. which is pretty retro imho.

Yeah, that's pretty retro (1986) even though it was released after the release of the third generation consoles like the NES in 1985.

It is also well after the arcade crash of 1983, so definitely not golden age arcade retro, but is it still very retro none the less being from the mid 1980's.

lol Any menu for player options is fancy to me when thinking retro. 

I think of games like Asteroids, Pac-Man, Donkey Kong, etc, where you insert your coin(s) and choose 1 player or 2 player start button then it starts the action. (even the 2 player was turn based)

Not saying that the menus are not found in retro and semi-retro games, just that it didn't come to mind when I thought retro.

Quote from: Conjured Entertainment on December 29, 2017, 17:59:54

QuoteThe screenshots are 640 x 480 with letter-boxing of 40 pixels above and below.  The pixels are 2 x 2 and the movement is 2 x 2 so this is perfectly fine according to Qube.  I allow for a max of 1280 x 1024 which gives me 4 x 4 pixels and movement and a letterbox of 112 pixels above and below.

So, 320x200 virtual resolution does not refer to the size of the screen during game play?

So, we can use a 1280 x 800 resolution or other size, as long as it is a scale of 320x200?

I took the 320 x 200 as being the resolution for the game to be played in.  that changes everything

Yes.  I plan to default to 1280x800/ full screen if the users machine allows.  You must ensure that there are only 320x200 pixels visible, however they are scaled, and movement must be scaled based on the 320x200 virtual resolution.  I added an option for per pixel movement which is turned off by default as against the rules as too smooth

QuoteYes.  I plan to default to 1280x800/ full screen if the users machine allows.  You must ensure that there are only 320x200 pixels visible, however they are scaled, and movement must be scaled based on the 320x200 virtual resolution.  I added an option for per pixel movement which is turned off by default as against the rules as too smooth

Had I know this before, then I would have structured my drawing a bit differently, or even opted for image based sprites instead.

If I change my screen size now trying to scale it, then I end up with missing lines in my images.

All of my lines drawn are 1 pixel since I was working with the small size of 320x200, so when scaling up they are still 1 pixel which is half of what they should be.

I would have to go back and rework all of my code, so like I said, had I known this before, then... (but I am stuck with 320x200 now)

Quote from: Conjured Entertainment on December 29, 2017, 18:22:47

QuoteYes.  I plan to default to 1280x800/ full screen if the users machine allows.  You must ensure that there are only 320x200 pixels visible, however they are scaled, and movement must be scaled based on the 320x200 virtual resolution.  I added an option for per pixel movement which is turned off by default as against the rules as too smooth

Had I know this before, then I would have structured my drawing a bit differently, or even opted for image based sprites instead.

If I change my screen size now trying to scale it, then I end up with missing lines in my images.

All of my lines drawn are 1 pixel since I was working with the small size of 320x200, so whn scaling up they are still 1 pixel which is half of what they should be.

I would have to go back and rework all of my code, so like I said, had I know this before, then... (but I am stuck with 320x200 now)

You could always write a simple line function which makes it thicker depending on resolution?

I wouldn't worry about it too much though.  Windowed 320x200 was my original default - just remind users to hit Windows Key + Up Arrow to make the window fill the desktop.