Re: [Enigma-devel] Re: Yin-Yang Switch Stone

[Ronald Lamprecht]

Hi,

Ivan Wick wrote:
> I sent the email below about a month ago and haven't received any
> replies about it.

Sorry - somehow this subject got lost on my long long TODO list :-(

> Any thoughts?  Ronald, I got all of your info about MinGW development
> (my email to the list on the same day as the one below) so thanks for
> that, but I hope you'll understand that the main reason I wanted to
> compile any of this myself in the first place was to mess around with
> the fun stuff like adding features and items! (:
>
> Ivan
>
>
> On Tue, Jun 10, 2008 at 2:16 PM, Ivan Wick <address@hidden> wrote:
> > Developers,
> > I am working with level designer Ray Wick who had an idea for a "Yin-Yang
> > Switch Stone," i.e. a stone which when hit switches player control between
> > the black ball and the white ball in the same way as it-yinyang.  However,
> > in the case of a yin-yang switch stone, the switch must be activated where
> > it is on the map rather than allowing the player to carry it-yinyang in the
> > inventory.
> > This idea could make for some new and interesting Enigma levels so I
> > implemented it.  I couldn't find a way to do it purely by Lua-scripting
> > level objects so I made some source code changes.
> > My first attempt was simply to add support in the YinYang Item's class
> > (items.cc) for a "swap" message, so that it-yinyang could be activated in
> > the level's Lua script by other level objects like a floor switch or switch
> > stone.
> > My second attempt was to create a new subclass of the switch stone which
> > called "player::SwapPlayers()" on actor_hit, in addition to otherwise being
> > a fully functional switch stone.  I also put together artwork for this stone
> > and added it to the Lua model scripts where needed.
> > Originally I was working against the released source code for version 1.01.
> >  I was able to replicate the behavior from my first attempt above easily in
> > the subversion trunk, however the code for switch stones has
> > been re-factored since 1.01 and I wasn't sure how to proceed.
> > So a few of questions:
> > - What do you think of the new idea and how do the developers decide whether
> > to integrate new game features like this?

I have a list of more than 200 new object ideas, at least 30 of them 
demoed by sample implementations. But we will add just very few new 
objects each Enigma relase.

There are several reasons. First we are currently in major reengineering 
period focussing on fixing thousands of bugs and incomplete 
implementations of the existing objects. Furtheron we have to note that 
the first fun implementation of an object is less than 5% of the costs. 
The rest of workload is the maintainance of the objects as keeping them 
compatible with all other upcoming features and levels. But the most 
important point is the value of any addition for the user. They are 
suffering of the huge zoo of existing objects and would not appreciate 
to many new objects with just a few levels using them.

So we try to evaluate every idea on its longterm value and effects on 
the game and select just the very best ones.

Concerning your idea of a "Yin-Yang Switch Stone" I do think it is an 
idea that fits very natural into the game. It would not need any long 
explanations - a big plus point. But the usage value is a bit limited: 
just levels designed for single computer usage, that have just two 
single actors assigned to the two players would profit. The idea does 
neither match a future networking game, nor does it provide a solution 
for multi-marble two-player levels. Nevertheless I can imagine that it 
help authors writing interesting 2 marble levels for a single gamer.

Is there an alternative solution for the targeted problem that is 
feasible? There is an alternative solution that works with Enigma 1.01, 
but it is dark Enigma Voodoo. It is unnatural and not WYSIWYG at all.

The costs of this object would be very low. Simple code and just one image.

Overall I think this object idea has a fair chance to be added in the 
next release.

> > - Is subclassing a switch stone the best way to implement this?  I would be
> > glad to hear any other approaches and suggestions.  What about making
> > it-yinyang respond to a "swap" message, should this be left in?

It should just be a simple stone that inherits from "Stone". There is no 
"Switch" stone functionality that can be inherited. It is a most simple 
stone object that just switches the players and performs its action on 
an actor hit. As a name I would suggest "PlayerSwitch" and 
"st_playerswitch".

There will be no "swap" message, neither in the item nor in the stone. 
This feature would be not WYSIWYG - we should keep the API clean.

> > - If this feature is to be integrated, what is the best way to submit diffs
> > (and artwork)?

You can either post diffs to the list or send them directly to me.

For this tiny object there is no real need of sourcecode diffs, as 
patching takes as long as coding it.

If you like to submit diffs, please just on base of the new reengieered 
object structure.

Images of 32,40,48 pixel resolutions are required, 64 and 16 would be 
useful.

Greets,

Ronald