Congratz on the release buddy!
Congratz on the release buddy!
Congrats, the game looks really well done!
Out of curiosity, how is the zooming handled in your project?
Thanks Klownzilla, you know it's been a bit of struggle (at times)
Thank you gkinfinity!
The zooming is achieved through scaling of all active objects inside the frame,
I basically applied the same qualifier to all "zoomable" objects,
and operated with their "real" (unzoomed) X,Y positions in their own alt. values
(I don't move X,Y of objects to make them slide around, but alter their alt. values)
then resultant "screen" X,Y positions are obtained by multiplying zoom_factor * values X,Y
and then each object X,Y scale IS "zoom_factor"
"zoom_factor" (and "camera position") changes dynamically mostly basing on speed of the sleigh,
as you see above camera gently zooms in when the player stops against the block
there have been some additional workings to make snow chunks (all the "bottom" white area you see above)
fit together seamlessly, because rounding sometimes caused noticeable 1px offsets (empty lines in the middle of snow)
so I had simply up-sized the chunks one pixel more, so that they fit perfectly OR overlap just by 1 px each other
There is no "default" collision detection either in the game,
or this would have been a big mess with scales changing continuously.
The sleigh slide movement itself is checked against an array holding all "snow chunks" height profiles.
Whoa, that's crazy! I've considered scaling individual objects to achieve a zoom effect before, but I definitely never thought it through all the way. It's even more complex than I thought. You definitely can't tell where the seems are between the snow chunks. Very nice job!
You should bring out a halloween version later this year, when it's dark it reminds me of the film 'The Nightmare Before Christmas'
That zoom system, once setup and running is very low hassle, and also quite short in code.
If you don't need default collisions and default movements, you're good to go.
Of course (and particularly on android) you can't have hundreds of objects processed this way in real time,
but Fusion does a really good job with scaled actives, you can have pretty "big" elements without too much impact.
@aenever: that's a cool idea, night time is a bit "Burton-esque" indeed (music also does its part in this)
love that movie, I always give it many plays on halloween times (alongside "Halloween" of course )
Halloween and Xmas have two of the most distinctive and inspiring imagery among holidays,
perfectly fitting for mobile games!
That's great to see you release a game! With you helping me and others out, how the hay did you have time to release a 4 player endless sleigher!?
A few questions and insights if you don't mind me sharing.
How did you achieve instant data transfer? I mean, the sleighs position has to be perfectly in time to race each other and with up to 4 players, that's sick. Is that just google having a solid server?
The zooming effect is just awesome. It makes the environment seem so huge when it zooms out. Very well done. It feels like the thrill of a huge roller coaster, especially when cruising down a big hill!
I'm so impressed with how functional the gui works. Man, you have achievements, leader boards, character selection, the whole nine yards. I know that's all part of a game, but I'm working on my first multiplayer and it's work to put all those elements together!
Great job man!
Thank you Emerson!
in fact it took me much more than planned, but it's been a reasonable time frame anyway,
and I think I'm going to use this "engine" for another (quite different) game too.
I don't want projects take too much time, or I know I will risk losing interest!
I won't lie: the data transfer is not that "instant"
but it's something that has to do with the architecture of realtime online multiplayer,
no data sync can be instant, there has to be some lag somewhere,
the point is how good you can "mask" it!
In The Christmas Sleigh the user input is quite simple: you can accelerate or not (forward or backward) by keep holding finger or not.
So each time somebody "starts" an acceleration, I send that data, and same when somebody "stops" accelerating.
This minimize the data transfer, so I don't flood the channel with data.
But data must get to other players, and as quick as it can be, it won't be instant, some hundreds of second will forcedly pass.
In gaming terms, particularly if you move fast, this means you can lose a wide amount of movement.
To be sure things don't go too wrong, on each specific time interval I also send across players their current X-Y positions,
if there's a gap between "real" sent position and "receiver's" calculated position,
I make the player accelerate (or decelerate) more, to reach the correct position.
But when lag goes too far (can also happen with missed messages) and the received position is too far from the calculated position,
I make the player "teleport" to last received position... not elegant, but no way, or the game could become inconsistent.
In all when it comes to multiplayer syncing you have some different choices:
- esteem position and sync frequently, or in most needful situation (the thing I did)
- make the system "foresee" movement by some frames, and gather all data to make its bet the best (but could and will end up in a "big error" if /when he foresee bad!)
- an "authoritative server" solution will make (almost) sure all players see the exact same things, but you will lose direct input (you send your movement data to the server, then the server makes it calculations and send you -and other players- back the answer on where you must be placed - both players see same things, but you lose the instant feel of controls in the time it takes for these messages to go back and forth)
I think the choice mostly depend on the kind of game you're doing.
In an action game, you'll want to privilege user input responsiveness so each player has same feel of single player experience.
Turn based games could of course be almost issueless on this department.
As for achievements and other stuff (leaderboards)
google has provided both the issue and the solution
they want you to put some achievements in or you can't publish the game,
so if I had to do that... I thought it would have been better adding a good number of things.
But I took benefit of the achievements and (partly) leaderboards GUI that comes with the Google API,
so at least that part was already done!