Re: [Supertuxkart-devel] Fw: Feedback for the proposal

[Joerg H. <jo...@lu...>]

Hi Jaskaran,

...
> Well I replied to you on melange that I'd be using the debug keys for
> giving the input as their was no input from the network input.
We have to judge you from what you have written, not from what you could 
have meant. Take your example above: I admit I have no idea what you 
mean, there are just too many 'input's in that sentence. In many places 
in your proposal it was just not clear to me what you meant. You wrote 
that you store the steering input. Great, but that's only around one 
third of all player input (acceleration, braking, fire, skid etc all 
need to be stored). It might be possible that you meant that, but that's 
certainly not what you wrote. I can't just assume that you meant the 
right thing. To me it just appears that I've mentioned 'steering' as an 
example of missing input, and only steering and nothing else was added.

In more detail, you suggest to store the steering input along with the 
karts in the frames. But then when you detect how far to roll back, you 
pop and discard all later frames, so you do not have steering input 
anymore. So your proposed solution does not work.

Yes, it's easy enough to fix, and no, please don't waste your time doing 
this.

We had to take into account what was written, and that clearly did not 
give us any confidence that you could implement the functionality we need.

...

We had enough proposals who added that by themselves, who thought about 
'quantising' steering input (i.e. mapping from floats to a 1 byte value 
in the range [-1,1]) to reduce data size, who described queue handling, 
...  All of this was missing in your proposal.

> IMHO I understood and visualised the problem correctly.If it wasn't so
That might be possible, but the written proposal certainly did not 
reflect that. One example of this is the storing of steering above. To 
give you more feedback:
- you have to write that you need to store all user input
- you have to think on how to store it
   [more explicitly: if you store them with the kart data on the same
   stack, that's basically fine and might even work, but then you can
   not throw them away, so don't write that you just pop them]
   If you store them in a separate data structure, then you can easily
   discard the unneeded frames, but you have to explain that. We can't
   just guess what you might be doing.
   Maybe there's an advantage in storing the input data with the kart
   data that I am just missing, it's your task to discuss this in the
   proposal (if you are not sure which one, or if you want to let us
   know that you evaluated different implementations).

I would recommend to sit down and do a flow chart of how you would 
implement it (high level only, no implementation detail). You have 
written that the user input is used in each frame, so you would see that 
when doing the simulation input from the user is taken. When you write 
down the replay code, you should notice that this is missing in your 
description.

Ideally perhaps ask a friend to do that, since it's difficult for anyone 
to read what he/she has written, since you know what you mean.



> why would auria say good to my proposal in the first case?
I am not sure what auria told you - in the feedback here she wrote "not 
bad". Note that we had many good proposals, and all(!) were rejected. 
And we had a few excellent proposals, and even of them we had to reject 
some.

Also note that the overall internal ranking is based on feedback from 
everybody involved, and the rejection/acceptance decision is never based 
on a single opinion.

> Even I was surprised after hearing the first feedback from auria that
> the proposal was good.You had been giving me such positive feedback that
> I was having a false sense of satisfaction that my proposal is good
> enough.At that time u/auria should've mentioned and should have laid
It's a competitive situation, and we can't give you any statement or 
security that your proposal is 'good enough'. Even if it was excellent 
enough, you might get rejected (see above). We had three slots, and not 
'1 slot for each good proposal'. And we could only make this decision 
once we read all proposals at the very end. Thinking "It's good enough", 
and then resting on your laurels is just not good enough. You are 
competing with the best world wide (and that's a compliment to most 
students who have submitted proposals to us).


> greater emphasis on the input storage.Its only after the second email
> and that too from my side asking for more feedback that you started
> talking about storing the user input on the stack.And that too I did
First of all, we are all only humans, and it's possible that we might 
have missed a thing, or perhaps gave the wrong impression to you as 
well. Also it takes a lot more time to properly think through a 
proposal, e.g. the fact that even if we would assume that you stored all 
player input with a kart (which wasn't clear), then you discard those. 
There's no way we can pick this up from a quick reading. It is your 
responsibility to make sure your proposal as written down is feasible.

Best regards,
    Joerg



> write in the proposal after you mentioned it on melange.
> Jaskaran Singh
>
> ------------------------------------------------------------------------
> *From:* Joerg Henrichs <jo...@lu...>
> *To:* Jaskaran Virdi <jas...@ym...>;
> sup...@li...
> *Sent:* Thursday, 30 May 2013 6:41 AM
> *Subject:* Re: [Supertuxkart-devel] Feedback for the proposal
>
> Hi Jaskaran,
>
> your feedback is really appreciated, after all we are only a 1st-time
> org, so we have to learn, too.
>
>  > But there are a few points that I would like to highlight:
>  > Physics engine:I thought that working on this project, I would learn
>  > about game engine and how you program for games. I never thought that
>  > you would be expecting me to have prior knowledge in game programming.I
>  > thought that I'd be working on this in the community bonding period.
> We did mention that this project involves studying the bullet code, but
> it was certainly not a prerequisite to know that. What we wanted to see
> in the application is that you understand the problem completely, and
> have thought about important things.
>
> For the rewind project understanding that the point is to go back in
> time, and then replay all events (especially player input) is essential.
> Maybe we did not mention it explicitly enough, but we did write: "...
> taking the new input from the client into account ...", which imho shows
> that you need player input.
>
> Even more: I've provided feedback to you: "I don't see where/that you
> store player events (perhaps you assumed that as trivial)? if you reply,
> you need to be able to set the correct steering etc." - so I think that
> pretty much makes it clear.
>
> We did not expect you to identify (say) all bullet states in the
> proposal, but we did expect people to understand the importance of
> storing player input. The rewind has to be an actual re-doing of the
> simulation (including player input).
>
> And a proposal has to show us that you understand the important points.
>
>  > Your expectation don't match the prerequisites listed on your GSOC ideas
>  > page:For the Rewind SupertuxKart project,the prerequisites mentioned are
>  > strong C++ programming skills,ability to understand a somewhat large
>  > code base .It doesn't mention anywhere that you must know how to use a
>  > physics engine and all the game programming lingo.This is not even
> Exactly, and we did not expect this. For this project at least there's
> nothing special about _game_ programming (special about game programming
> is imho (but I might be missing things here) that it involves a lot of
> different skilled people working together; 2d and 3d artists, level
> designer, sound effects, ...).
>
> And again: we did not expect anyone to know bullet (or any physics
> engine). But we do expect that you know that 'somehow' the game reacts
> to player input, so if you go back in time and restart, you need player
> input in order to recreate what happened.
>
>  > present in the description of the project.Had your organisation written
>  > in the prerequisites that a little knowledge of game programming is
>  > necessary I wouldn't have applied with so much vigour or would have
>  > spent my time on some organisation or something else which would have
>  > been more useful.The description is misleading.
> I am sorry that you are not really happy with the way we handled this.
> As I've said, the special thing about game programming is mostly the
> dependency on people with non-programming skills, and especially this
> proposal does not have anything of that in it (nor many of the others
> ... lobby needs some icons, but that's all I can think of atm).
>
>  > Would I have learnt anything new in my summer vacations if I already
>  > knew about game programming?How would it have been challenging then?
> You would have learned a lot about programming, not particularly game
> programming. And working in a team, dealing with a (medium) large code
> base. Note that this opportunity is not lost. Many open source projects
> are always looking for contributors, so you can always participate ...
> except of course that this doesn't pay the bills :(
>
> Thank you so much for your feedback,
> Joerg
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> Supertuxkart-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel