Code a game competition Nov-Jan 2018 - Minimum £500 prize fund

[Qube]

2 quick rules clarification please:

1. Is black a colour and does it count to one of the 16?
2. I like fading to black between sections (eg title screen to game screen), so I draw a black rectangle and tween its alpha until fully opaque - is this allowed as it may look like more colours are used?

Black would be counted as one of your 16 colour palette. If you alpha fade to black then your palette becomes 100's of colours and thus breaks the 16 colour rule.

[therevills]

Thought so, thanks for clarifying. 

I've got my simple tile map loader working :


It reads in the JSON from Pyxel Edit tile map exports 

Now collision detection!

[Derron]

looks good...and as said I am more and more of the opinion to not continue competition game development. No chance to win and already loosing interest in the original game idea - especially with the fans of my other game begging for a "big update to christmas" :-p




Stop doing so good looking things!


bye
Ron

[iWasAdam]

  Nooooooooooo

[RemiD]

reminder : if you use a 3d engine for your game, remember that the diffuse/ambient colors of a material can alter the colors of the pixels of the texture associated with it. (recently i wondered why a "rock" was grey and another "rock" was redish, even if the pixels of the texture were grey... Now you know why !)

[Qube]

looks good...and as said I am more and more of the opinion to not continue competition game development. No chance to win and already loosing interest in the original game idea - especially with the fans of my other game begging for a "big update to christmas" :-p

Stop doing so good looking things!

**SLAP!!** Get back to it and finish it off ( me great at motivational speeches )

Seriously though, don't fall into that defeatist trap. Besides you've not seen my laughable graphics yet and I've been struggling a whole heap to get something to look passable.

[Steve Elliott]

After realising I have to move 4 pixels per frame (because I'm up-scaling the native resolution by 4) this destroyed my smooth movement.

If I don't come up with a solution quick I'll be out too.  Currently the movement has gone from smooth to far too jerky and slow, or blurring and fast.

[Qube]

Currently the movement has gone from smooth to far too jerky and slow, or blurry and fast.

If you are moving 4 pixels every frame of even every other frame then it should still look smooth enough. Can you do a screen recording of the problem?

[RemiD]

Would this kind of render be ok ? (first person view, 320x200 resolution, 16colors max)

i am trying to create a graphics style similar to "Daggerfall" (simplified, with less colors, without lighting/shading)

[Qube]

Looks fine to me, RemiD

[GaborD]

Some of the games you guys are working on look great!
Now I kinda want to join the fun. Nothing done for it yet ofcourse. 

If you want to do a full on 3D game in a 320x200 res with 16 colours, then good luck.

That sounds like you issued an added challenge right there... hmm.

[Qube]

That sounds like you issued an added challenge right there... hmm.

Absolutely - If I knew shaders I would of been tempted to go for an index palette shader with full on 3D. But alas, I do not and thus it's been a mega cobweb blowing session off my ancient 2D pixel drawing of decades ago. The last time I did any mass pixel stuff for games it was all done on graph paper first and translated into hex for the TI-99/4A.

[therevills]

Collision detection is in for the player and the tile set. Using masking to work out the slopes, when loading in the tile set I creating a simple 2D array of the images and then work out the height on the player for the slope - PITA really! The slight delay you see when moving from the title screen to the game screen is the process of creating the masks... need to find a way to speed it up.

In the video, the orange rectangle is the 2D mask rendered and the tiles turn red when the player touches them - debugging as its best!

Also changed the screen fading to pixel filling 

@Derron - please dont give up - I like the look of your Christmas game

[Derron]

@ 4 Pixels
It is like moving 1 pixel in the native 320x200 resolution.

So when "magnifying" you still pass the very same background blocks (which are then 4x4px instead of 1x1px).


@ do not stop
Only were able to invest 5 minutes in another animation sprite until I got the new phone for  mother-in-law which needs upgrades, rooting, installation of all needed apps, cleaning of bloat ... and then the son always wants to sing songs - and a blink later its time for bed again :-). Not forgetting about real-life-work.


Seems I missed to place his "hat-bell" at the right spot. Glad I spotted it before you guys do.

I also planned to have some bullets (sugar candy canes ;-)) but  shooting in a rotating tower... means only be able to hit for 1-2 bricks. until rotation makes it "go off". I think I should do it similar to a hammer-projectile in Super Mario (so it has a low impact/velocity for a high gravity impact - and goes down pretty fast).


Biggest trouble for now was the "float to int"-thing. Dunno if it was better to have everything "int" and just store the small fractional part of the movement in another field (so what not fits inti "int" becomes a "remainer:float"-value). Else I always end up with problems (camera position is limited to player and defines how everything renders - and calculates rotation). Limiting some parts to "int(value +0.5)" everytime leads to jerky movement/jittering - or incorrect collisions. One sees that I have no experience with developing platformers (rather playing Super Mario (et. al) in my youth :-p).


At least a simple key press allows to switch from "rotating tower" to a simple "repeating 2d level"-type - now, after fiddling around with collision-detection on the "wrap around" coordinate (hint: split your collision-boxes into two - so it splits at the wrapping coordinate - and then check both for collisions) - and now it seems to work a bit better.
There is plenty to do and no actual gameplay in sight. I should really stop thinking "big" and doing little baby steps game-idea-wise as it else ends in a too hughe task to swallow.


bye
Ron

[Steve Elliott]

If you are moving 4 pixels every frame of even every other frame then it should still look smooth enough.

Maybe if you're not animating.  But I'm getting ghosting on fast updates, and jerky movement on slow ones.

I usually use time based movement - not pixel movement.

Code Select Expand


// AGK time based movement example

x# = 0.0
speed# = 40.0
lastFrame# = Timer()

do
    thisFrame#  = Timer()
    frameSpeed# = thisFrame# - lastFrame#
    lastFrame#  = thisFrame#

    KeyEsc = GetRawKeyState(27)
    If KeyEsc Then End

    x# = x# + speed# * frameSpeed#
    SetSpriteX(1, x#)

    Sync ( )
loop