uhmm, if I understand it right, these aren't screen space reflections.. you're using reflections rendered by a view with it's position and angles mirrored along a plane.

SSR are reflections computed only through the information of the pixels you can see (= screen space), without any further rendering of geometry.
Usually SSR is done by tracing the scene per pixel.

anyway, looks really cool, nice job

Yeah the result looks nice indeed!
However, as we all know the game stands and falls with its gameplay. When does prototyping start in that regard?

Thanks for the comments.

@Kartoffel: You are absolutely right, let's call it screen-space lookup method

@Superku: Honestly, I consider the demo from 2007 as gameplay prototype I have absolutely no concerns about the gameplay, so, the first working version will be the last of the current-gen prototyping. My concerns were always how to achieve the kind of render-esque, no-texture visuals with my limited time and money budget.

Next visual steps are in this order: sun shadow, quasar entity + lighting + shadows + reflection, DOF... this will be pretty straight forward and I expect a good outcome

Then, I will test some considerations about screen resolutions and -orientation... this will be interesting, I don't know about the results

end of techdemo #1

After that I will implement user interaction... picking up the quasar, moving it around + collision detection with rings + dynamic camera programming...

Then, the first gameplay cycle of a single puzzle.

Hey guys. Came back from vacation and I decided one night at the beach that it takes to much time to get used to any other engine and that I want to do the whole thing more relaxed.

So if anybody is interested: I will do it with Gamestudio, for Windows PC. If the engine is updated and new exporters will be released - good. If not - its OK!

Awesome! \(^.^)/

Btw. some time ago I was thinking about your project when I scratched another Superku level. AFAIR you controlled the ball/ orb/ puck directly in the old a77itude, right? I think a much more interesting gameplay would result from controlling it indirectly where you place the mouse cursor somewhere next to the ball and as long as you hold down the left mouse button the ball gets pushed away (gets an impuls) from the mouse cursor position.

Oh... and I was sure you already decided that before. Anyway. That's nice and I hope to you finish it

There is a game that is called "The Moon Hates The Stars". It was long ago available as freeware on the Experimental Gameplay site (http://experimentalgameplay.com/), where you was able to send in all kinds of creative/experimental games. The site closed, was long under re-construction and follows now since 2009 a totally different approach - but I remember the game very well (here is download link:
http://www.sosej.cz/Software/Hry/Arkady/The-Moon-Hates-The-Stars/Download). I once tried to find/contact the author, but failed - because it is a very beautiful game: you control the moon and all the stars react like a herd of sheep to it - they go away .. it uses crowd behaviour AI. Goal of the game was to fit the stars into one, or many, shapes (circles). Simply beautiful.

Although easy mechanic, you have to take your time. It is relaxing. But it can be unsettling, when you pushed some stars on the one side into the circle, and on the other side some decide something like "hey! lets get out of here"

A passive control scheme for A7ITUDE... I don't know. Can only work if the puzzles are rather easy and slow... I would have to experiment with that.

I also wanted to experiment with some new ingame mechanics (collectables, magnet rails/impulse rails, switches, multiple holes) - some of them are pointless if you have direct control (like collecting items) and get interesting if they are in a "difficult" area, like fast moving obstacles/rings... if I implement a passive control scheme with slower movement, this could get even more interesting. Good point, Superku!

I could also imagine a multiplayer mode, in which different people influence by their pull/push control of their own orb other orbs of other players. Or a co-op mode: two players control together the orb.

Besides, this would destroy totally the "action-orientated" game of skill, in which you have to move fast and quick... hm.

On the other side, having a move + one click button mechanics resolves the necessary to deal with different mouse cursor speeds.. this was an issue with the old approach. It also makes it possible for a touchscreen, because then you would NOT HIDE the orb with your finger, you can see it...

Great idea, Superku! Thanks a lot!



Nope... I thought that the approach "make the game up to a certain degree", "shift the prototype to another engine" and finally "finish the game" was a good idea. But with simple algebra I figured out that step 2 is impossible for me alone and that it costs to much money to hire someone to do so. Therefore I decided to work with what I know and do the best I can. All this "use a new engine" gibberish somehow catched me... I should have known better.

Actually trying out another engine works well enough - but I would not prototype with Acknex and then shift either. Feels painful and time intensive.

You are welcome. I'd just write one or more gameplay prototypes and see what works or feels best, and don't be afraid to delete or scrap stuff and make it completely different. You are not bound by any design document and that freedom is something very precious in my opinion.

I got the lightfrog demo up and running under A8 (the skybox doesn't seem to work) - and I am currently digging into the source.

Hummels shadows are really amazingly done and if it works out, I will pull them into the game.