FreeLists / zxspectrum / [zxspectrum] Fw: A Proposed Plan for DDragon.

["Stefano" <flydream@xxxxxxxx>]

Chi avra' letto ZX Notizie sapra' sicuramente dell'imminente uscita di Double 
Dragon per ZX 
Ecco lo stato del progetto

----- Original Message ----- 
From: "Karl McNeil" <kgmcneil@xxxxxxxxx>
To: <KgMcNeil@xxxxxxxxx>; <fikee@xxxxxxxxxx>; <dean.swain@xxxxxxxxxxxxx>; 
<cpuz80@xxxxxxx>; <flydream@xxxxxxxx>; <moroz1999@xxxxxxxxxxxxx>; 
<gasman@xxxxxxxx>; <jerri1977@xxxxxxxxxx>; <webmaster@xxxxxxxxxxxxx>
Sent: Tuesday, July 05, 2005 9:46 PM
Subject: A Proposed Plan for DDragon. 


> Now here's something Im emailing to all...
> 
> These are only MY suggestions, which Im hoping team
> members will read and add to (or critise and modify). 
> What we need to do first is all agree on a plan, even
> before we go our separate ways and work on our bits...
> I shall type a few ideas here and include them as a
> Txt file attachment.  What I would like is for all to
> read the ideas, cross out, or edit, or critise the
> ideas you like, or don't, and send edited copies of
> the plan back to me and each other.  That way, we can
> correlate bits of our plans together and come up with
> a copy that we can all agree on... Agreed?... Okay,
> heres the plan (please read and edit):
> -------------------------
> SUGGESTED PLAN FOR DOUBLE DRAGON
> (A LIST OF PROPOSITIONS)
> VERSION: 5TH JULY 2005 (1st Draft)
> EDITED BY: Karl McNeil (Please add YOUR name and new
> date if you make changes)
> 
>>>> GRAPHICS <<<
> [1] GAME ENGINE: The game shall use a flip screen,
> rather than a scrolling game engine to reduce CPU
> intensive work.
> [2] The playing area shall advance at variable amounts
> when the screen flips, accomodating the original
> positioning of the enemies as close to their arcade
> starting positions as possible.
> [3] COLOUR: The game shall be monochrome to reduce
> memory, colour clash, and because if it doesn't look
> good in monochrome, it won't look any better in colour
> anyway...
> [4] SPRITES: I propose we use the same map tile engine
> to do the sprites as the map tiles (reusing code).
> [5] I propose we reuse sections of the sprites (eg:
> reuse of legs and body)(eg2: reusing billy body for
> green ninja sprite) - hence my choice in [4]
> [6] I propose we arrange the sprites masks in the same
> way we arrange the sprites (ie: as reusable tiles) for
> the same reason as [5].  This also gives the
> possibility of using the mask of one sprite for a
> range of different sprites.
> [7] Propositions [4], [5], [6] will inevitably mean we
> will be required to store map array data for: a: the
> map, b: the Sprites, c: the Sprite masks
> 
>>>> SOUND <<<
> [8] I propose we have 3 modes: a: Music only, b: SFX
> only, c: Music and SFX.
> [9] Mode c above (Music and SFX): Since I do not know
> how one can have both together (you may know?!!), I
> propose we can fade out one and fade in the other at
> key points in the game (eg: SFX fade out, and music
> fades in during the final confrontation scene on level
> five, or during end of level one)
> [10] MUSIC: I vote we use Matthew Westcott's
> (gasman@xxxxxxxx) Zx music for the game, in Pt3
> (Protracker 3) format.  The player code is well
> established and easy to use (See
> http://bulba.at.kz/vortex_e.htm for more info).
> [11] SFX: I propose we use the above Pt3 format to
> create the sound effects, in the same way that
> instruments are created in Pt3 music.  The same player
> code could thus be used for music and/or sound
> effects.
> 
>>>> INPUT <<<
> [12] I propose we offer both conventional 8
> directional, single fire button AND 8 directional 3
> fire button control methods if possible.  If we could
> only chose one or the other, however, I would vote
> that we use something close to the original arcades
> control system (eg: something like the PC's cursor
> keys, and Z,X,C buttons for fire)... This I believe is
> really a coding issue, so I can't say what is
> realistic on this point.
> 
>>>> CODING <<<
> [13] (Since Im not a coder, please feel free to
> disagree with anything I say here) I propose we write
> the code in assembly.
> [14] I recommend a modular approach, writing the
> assembly as replacable procedures or libraries, so we
> can easily update parts of the code as we progress.
> [15] I would like some agreement as to what assembler
> to use, in case one of us comes across some useful
> code that could be used and wants to share it to the
> other team members.  I propose using the built in
> assembler of the PC emulator called EmuZwin.  This can
> be downloaded at:
> http://bonanzas.rinet.ru/apps/EmuZWin_Eng.htm 
> Since Im not coding, I really want to know what others
> feel about this issue - which assembler would you
> suggest?
> If our team expands any more, we may be better able to
> share the code work if we have some agreed standards
> about what format it is in.
> [16] What ever assembler we use, I propose that the
> source code should at the very least be in ASCII, so
> that it can be cut and pasted across a variety of
> different applications and systems.  Raw spectrum
> formats should therefore be regarded as end products,
> but not the source of the code.
> [17] In relation to [16], I suggest we do much of our
> development on emulators, 16 bit and 32 bit systems
> (eg: PC's, Amiga's, Mac, etc) before porting our code
> across to spectrums.  This enables us to use a whole
> array of tools available freely on the internet for
> our work, guarentees some level of compatibility for
> others who may wish to add to or contribute to the
> source code, and generally makes life easier (you
> don't think I did those graphics using Art Studio 128k
> do you????!!!)
> 
>>>> CREDITS <<<
> [18] No one should send anyone elses graphics, sound,
> code or other work to friends or others ourside the
> group, unless they have first asked permission from
> the author, or at least informed them of their
> intentions.
> [19] Team members should try to make a habit of
> keeping each other in contact and informed of any
> developments they make.
> [20] Team members are to ask others in the team or at
> least keep others informed if they intend to invite
> another member into the group.  That way, we know who
> is working on what, can avoid duplication of work, and
> can better coordinate the work, and give credit where
> its due.
> 
> [21] This plan is being forwarded to everyone who
> every expressed interest and corresponded directly
> with the team, whether contribution was big or small,
> or none at all.
> [22] There are no team leaders, decisions will be made
> democratically.
> [23] Each person listed is entitled to their say, and
> entitled to be heard regarding their ideas of how the
> game should be designed and encouraged to contribute
> by editing this plan and forwarding it to the others.
> 
> END - PLEASE ADD, EDIT, CRITICISE, AND RETURN A COPY
> TO:
> 
> KgMcNeil@xxxxxxxxx,fikee@xxxxxxxxxx,dean.swain@xxxxxxxxxxxxx,cpuz80@xxxxxxx,flydream@xxxxxxxx,moroz1999@xxxxxxxxxxxxx,gasman@xxxxxxxx,jerri1977@xxxxxxxxxx,webmaster@xxxxxxxxxxxxx
> 
> Thankyou
> -------------------------
> 
> 
> 
> 
> 
> 
> ___________________________________________________________ 
> How much free photo storage do you get? Store your holiday 
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com


--------------------------------------------------------------------------------


> -------------------------
> SUGGESTED PLAN FOR DOUBLE DRAGON
> (A LIST OF PROPOSITIONS)
> VERSION: 5TH JULY 2005 (1st Draft)
> EDITED BY: Karl McNeil (Please add YOUR name and new date if you make changes)
> 
>>>> GRAPHICS <<<
> [1] GAME ENGINE: The game shall use a flip screen, rather than a scrolling 
> game engine to reduce CPU intensive work.
> [2] The playing area shall advance at variable amounts when the screen flips, 
> accomodating the original positioning of the enemies as close to their arcade 
> starting positions as possible.
> [3] COLOUR: The game shall be monochrome to reduce memory, colour clash, and 
> because if it doesn't look good in monochrome, it won't look any better in 
> colour anyway...
> [4] SPRITES: I propose we use the same map tile engine to do the sprites as 
> the map tiles (reusing code).
> [5] I propose we reuse sections of the sprites (eg: reuse of legs and 
> body)(eg2: reusing billy body for green ninja sprite) - hence my choice in [4]
> [6] I propose we arrange the sprites masks in the same way we arrange the 
> sprites (ie: as reusable tiles) for the same reason as [5].  This also gives 
> the possibility of using the mask of one sprite for a range of different 
> sprites.
> [7] Propositions [4], [5], [6] will inevitably mean we will be required to 
> store map array data for: a: the map, b: the Sprites, c: the Sprite masks
> 
>>>> SOUND <<<
> [8] I propose we have 3 modes: a: Music only, b: SFX only, c: Music and SFX.
> [9] Mode c above (Music and SFX): Since I do not know how one can have both 
> together (you may know?!!), I propose we can fade out one and fade in the 
> other at key points in the game (eg: SFX fade out, and music fades in during 
> the final confrontation scene on level five, or during end of level one)
> [10] MUSIC: I vote we use Matthew Westcott's (gasman@xxxxxxxx) Zx music for 
> the game, in Pt3 (Protracker 3) format.  The player code is well established 
> and easy to use (See http://bulba.at.kz/vortex_e.htm for more info).
> [11] SFX: I propose we use the above Pt3 format to create the sound effects, 
> in the same way that instruments are created in Pt3 music.  The same player 
> code could thus be used for music and/or sound effects.
> 
>>>> INPUT <<<
> [12] I propose we offer both conventional 8 directional, single fire button 
> AND 8 directional 3 fire button control methods if possible.  If we could 
> only chose one or the other, however, I would vote that we use something 
> close to the original arcades control system (eg: something like the PC's 
> cursor keys, and Z,X,C buttons for fire)... This I believe is really a coding 
> issue, so I can't say what is realistic on this point.
> 
>>>> CODING <<<
> [13] (Since Im not a coder, please feel free to disagree with anything I say 
> here) I propose we write the code in assembly.
> [14] I recommend a modular approach, writing the assembly as replacable 
> procedures or libraries, so we can easily update parts of the code as we 
> progress.
> [15] I would like some agreement as to what assembler to use, in case one of 
> us comes across some useful code that could be used and wants to share it to 
> the other team members.  I propose using the built in assembler of the PC 
> emulator called EmuZwin.  This can be downloaded at: 
> http://bonanzas.rinet.ru/apps/EmuZWin_Eng.htm 
> Since Im not coding, I really want to know what others feel about this issue 
> - which assembler would you suggest?
> If our team expands any more, we may be better able to share the code work if 
> we have some agreed standards about what format it is in.
> [16] What ever assembler we use, I propose that the source code should at the 
> very least be in ASCII, so that it can be cut and pasted across a variety of 
> different applications and systems.  Raw spectrum formats should therefore be 
> regarded as end products, but not the source of the code.
> [17] In relation to [16], I suggest we do much of our development on 
> emulators, 16 bit and 32 bit systems (eg: PC's, Amiga's, Mac, etc) before 
> porting our code across to spectrums.  This enables us to use a whole array 
> of tools available freely on the internet for our work, guarentees some level 
> of compatibility for others who may wish to add to or contribute to the 
> source code, and generally makes life easier (you don't think I did those 
> graphics using Art Studio 128k do you????!!!)
> 
>>>> CREDITS <<<
> [18] No one should send anyone elses graphics, sound, code or other work to 
> friends or others ourside the group, unless they have first asked permission 
> from the author, or at least informed them of their intentions.
> [19] Team members should try to make a habit of keeping each other in contact 
> and informed of any developments they make.
> [20] Team members are to ask others in the team or at least keep others 
> informed if they intend to invite another member into the group.  That way, 
> we know who is working on what, can avoid duplication of work, and can better 
> coordinate the work, and give credit where its due.
> 
> [21] This plan is being forwarded to everyone who every expressed interest 
> and corresponded directly with the team, whether contribution was big or 
> small, or none at all.
> [22] There are no team leaders, decisions will be made democratically.
> [23] Each person listed is entitled to their say, and entitled to be heard 
> regarding their ideas of how the game should be designed and encouraged to 
> contribute by editing this plan and forwarding it to the others.
> 
> END - PLEASE ADD, EDIT, CRITICISE, AND RETURN A COPY TO:
> 
> KgMcNeil@xxxxxxxxx,fikee@xxxxxxxxxx,dean.swain@xxxxxxxxxxxxx,cpuz80@xxxxxxx,flydream@xxxxxxxx,moroz1999@xxxxxxxxxxxxx,gasman@xxxxxxxx,jerri1977@xxxxxxxxxx,webmaster@xxxxxxxxxxxxx
> 
> Thankyou
> -------------------------