SyntaxBomb - Indie Coders

Very impressive!

@Qube>>what happens if several participants have the same number of votes ?

On the old blitzbasic french forum, when this happened, there was a new vote for the participants having the same number of votes, but this can quickly becomes complicated when members which have voted, then disappear...
Well, nothing is perfect i suppose

Quote from: Conjured Entertainment on January 02, 2018, 13:57:05
I would do some of that fancy shading if I were creating mine in a paint program rather than code, but the deadline and my late start forces me to stick to basics.

I really like the style your in-code art looks, I remember doing that back in the day on the Amstrad and I also did that at college using Turbo Pascal.

It takes me ages to get the images looking right and animated, that little UFO took me over an hour to draw and animate! I couldnt get the rotating lights looking correct and I'm a bit OCD on those kind of things!

Nice UFO 

Quote@Qube>>what happens if several participants have the same number of votes ?

If it comes to that then we could :

1.. Share the prize fund ( has the down side that the winner gets less than 2nd place )
2.. Based off date of submission ( could be controversial )
3.. Redo voting ( but as you said, it could get messy )

Thanks for the compliments guys.

AGK makes it easy. 

QuoteI'm a bit OCD on those kind of things!

Yeah, I have OCD, and ADD.

So, everything has to be perfect, just not for long. 

Quote@Qube>>what happens if several participants have the same number of votes ?

If it comes to that then we could :

1.. Share the prize fund ( has the down side that the winner gets less than 2nd place )
2.. Based off date of submission ( could be controversial )
3.. Redo voting ( but as you said, it could get messy )

Not that my opinion matters, but I would opt for #1 out of those options.

Seems the fairest, and the least controversial, not to mention the odds of it happening are slim anyway.

To avoid the problem of them getting less, you could combine 1st and 2nd, or 2nd and 3rd depending on tie for 1st or tie for second, then split.

Since there are two of them in first, that seems to be for the top two slots anyway being two people.

Second place being 3rd from the top in votes would be bumped to 3rd place, and 3rd would be bumped to 4th since they had the fourth highest number of votes.

Just my two cents, if it makes any sense. 

So,
1) 250
2) 150
3) 100
4) 0

would become

1)200
1)200
3)100
4) 0

if tie for first

or
1)250
2)125
2)125
4) 0

if tie for second

or if tie for third then
1) 250
2) 150
3) 50
3) 50

Still the top 3 number of votes would be getting the prizes, with a additional winner if 3rd has to split.
Ties get equal amounts without getting less than the guy with less votes below them.

QuoteNot that my opinion matters

Of course it does

I'm sure we'll sort something out if we end up getting multiple entries tying for a place - Worst case scenario I'll chuck some more money in

if our opinion matters, i suggest to not allow a participant to vote for himself... This would better distribute the votes...

Quote from: RemiD on January 03, 2018, 07:11:06
if our opinion matters, i suggest to not allow a participant to vote for himself... This would better distribute the votes...

Sounds good to me

testing, debugging, testing, fixing, debugging, playing, debugging, playing, testing, testing, testing.....

oh and youtube, pandas... testing

Quote from: iWasAdam on January 04, 2018, 08:07:19
testing, debugging, testing, fixing, debugging, playing, debugging, playing, testing, testing, testing.....

That is one fantastic example of a hobby game coders experience - Except a few expletives and the obligatory mouse and keyboard violence should be thrown in for authenticity

Quoteoh and youtube, pandas... testing

Yup, I've done the "I'm talking a break and going on a Youtube ride"

On my side, i have managed to add the gameplay elements that i wanted, however since one of the gameplay element relies on positionning items (buried in the ground) using a "number of walking steps" * a "walking step distance" (distance traveled during an animation of a walking step), it will work only if the FPS is high enough (around 30fps), so i take the bet that it will work on most computers which are recent enough, since the graphics are basic.  (but i am not sure ^_^)
Not idea how i can do it another way...
The method i currently use is that i have a premade animation of walking steps (left/right), and in order to have the movement and animation speed appear constant, i multiply these speeds (movement and animation) by a "speedcoeff" which is calculated depending on the time it takes to go through a mainloop ( SpeedCoeff = Float(30) / 1000 * MainLoopMilliTime ) . So the movements/animations are done depending on the time, which is good and works well.
However, since the speedcoeff is variable, the distance traveled during a walking step is also variable, and since i use an average distance traveled during a walking step (at around 30fps) to position the items (buried in the ground), the positions will be messed up if the fps is too low (not around 30fps), but it should work on most computers which are recent enough

The idea is that player must reach a specific area on the terrain with a given orientation (using a compass), given walking steps, far away marks to find (using a spyglass), then look for a shining effect and digg at this position... (and find the hidden item buried in the ground!)

Make sure it doesn't become a chore to complete if you can't figure out the 'right' way....

My recent addition is all about slippy bananas... NOT WORKING!!!!!

If you require FPS then you do something wrong.
Physics/Logic <> Rendering

Just split things apart and it will work however you want it - and if it is Singleplayer it should even work with "hickups" or 1 FPS and only 1 Physics Update per second - as you do not have to rely on the passed time but only on the processed time - which in the best case equals to the realtime (but also might run more often to catch up after a hickup).


For now I stopped dev of my compo game: the bigger project consumes way too much time and keeps me more motivated than doing a christmas game for 20th of january... I doubt that I continue doing so.

Saying this I want to give you some hints to use more colors: As some of you know C64 you might know games having 1-2 more colors. How do they do that? They just _flash_ with two colors. So odd frames get color 1 used, and even frames get color 2 used.
On a 60Hz display you will have some colors "flickering" more than others. On a 144Hz (and a 144fps rate) you wont have flickering at all.

So in my game I prepared my framework to split images into "palettes of 2". Each image was stored two times: one with the palette A and one time with palette B. All colors existing in my 16-color palette stood the same in both images. But if a color was not existing in the 16-colors-palette then the idea was to use the two allowed colors which created together ("overlayed"/mixed) the most similar color. The calculation was done using an algorithm far superior to simple RGB-distance calculation - it uses perceived color difference distance.

The computation is done during loading and could be processed easily as 16 colors * 16 colors isn't much to check for such pixels - and if you cache results you are even faster.


Next step was to extend my sprite class to automatically handle this issue: so a 16+color sprite was automatically "flashing" the alternating versions to _simulate_ more colors. If you took a screenshot of the game then you only have 16 colors - take it one frame later and the game uses other colors (still within the limited _static_ 16 color palette). Only during live view / video  you would see the correct colors.


I intended to use that thing for special effects which are not on screen everytime - like fire particles, snow, ... Also "glitter" of snow on tiles could have used that as a "flickering" would be still OK (snow glitters when walking by).


The source code of the game is available there:
Licence is libpng/zlib
https://github.com/GWRon/SantaGame
checkout "tests/tower_algorithm_ron.bmx" if you want to check the "tower" itself (sorry, this is prototype code there, so not everything is clean OOP or structured well).


https://github.com/GWRon/SantaGame/blob/master/source/game.gamecolors.bmx
https://github.com/GWRon/Dig/blob/master/base.util.color.bmx
contains the color-stuff I was talking about. Maybe this is of use for someone (C*IELab color distance).

I also prepared some Santa-animations but never finished nor uploaded them to github - sorry dudes.



A real pity you extended time frame so much: it pretty much destroyed every motivation to keep coding on it. At least I found some bugs in my framework by doing this prototype. Aside of that I think there are so much good looking projects presented there, I would not have had a chance to win more than a greeting card ;-)

bye
Ron

Quote
If you require FPS then you do something wrong.
Physics/Logic <> Rendering
Just split things apart and it will work however you want it

I have already read/heard about that, but never tried, can you give me more details, please ?

However even if i separate the logic/physics and the rendering, if the physics/logic takes too much time to calculate (which is not the case in my game), i suppose that the same problem will occur : the lowest the UPS (updates per second), the lowest the precision of movements/turns/animations, isn't it ?