[zxspectrum] Fw: A Proposed Plan for DDragon.
- From: "Stefano" <flydream@xxxxxxxx>
- To: <zxspectrum@xxxxxxxxxxxxx>
- Date: Tue, 5 Jul 2005 22:10:12 +0200
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
> -------------------------
Other related posts:
- » [zxspectrum] Fw: A Proposed Plan for DDragon.
