tank would be easy.
And if you get the order of operations within each time step right,
movement bugs such as thin ice not breaking will appear. You don't
have to specifically code the bugs. You don't need to look at the
source code to deduce the order either. I was discussing this with
Mark (Sqir) recently. I can tell you more about it if you want.
Then fixing all the bugs (if that's what you want to do) is simple,
eg. make sure you check thin ice underneath stationary objects as
well as moving ones. But then it won't be "Lasertank".
New objects? Maybe remove rotary mirrors! :)
I remember reading some suggestions for new objects in the message
archives (new and old boards). You could look at those.
LFE
--- In [email protected], "dwidel" <dwidel@...> wrote:
>
> I'm writing a new port of lasertank from scratch. I was wondering
if
> anyone could recomend some levels (preferably easy) that I could use
> to test edge cases. I've just been trying them at random. I got a
> surprise yesterday when I hit 778. I went ahead and implemented
that
> one so I could finish the level since it was a few lines of code.
>
> I'm still on the fence about how far I should go implementing bugs
> though. I kind of feel that implementing counter-intuitive behaviors
> is a little unfair. I'd like to add some new objects as well so I'm
> thinking of just using a separate format for the level file.
>
> What are your opinions there?
>
> Thanks,
> Dave
>