The Worms project is underway, and as i have not recieved anything since the declaration of the game to do, i have now taken it upon myself to set the game design out and assign sections to each one of you.
The Screen
The screen will be split into two. The upper portion will use HIRES to allow the game-play to take place there. The screen will use one colour for the Land, whilst a Blue/Cyan background will set the Sea/Water Level. Any unreachable point will use other colours. This will enable the optimum resolution for the Worm Animations and cancel any possible chance of Attributes clashing.
Since in Hires, the Land will be destructable in various ways and the Worms may have limited movement left and right with Jumps allowed.
In order to allow for a wider arena, the Screen may be flipped left or right to reveal further areas but will be no wider than 2 screens to minimize consumption of memory.
The Lower portion of the Screen will be in TEXT and assigned for Messaging, Trajectory control and the displaying of the various weapons allowed
The split between the upper HIRES and the lower text will be about a 50/50 ratio with 120 Rows of HIRES Lines to 12 Rows of TEXT Lines.
This increases the available memory for the rest of the system whilst still allowing HIRES access for the game play.
The memory map is one of the most important parts of game design on the Oric. I usually turn to this area at first to organise the available space.
In general...
0000 Zero page will be used to hold the Interrupt routine (To play the samples) and working variables for Player1, Player2 and 
0100 Page one will, at this time, be reserved for the Stack
0200 Page two Basic system variables will be replaced with Worms general variables. In addition, the interrupt and NMI vectors will
        be changed here according to system requirements
0300 This holds I/O access to the 6522 VIA Oric Microdisc interface as so is reserved for this unchangable purpose
0400 Reserved for the Disc handling routines. For the Loading of Levels and the saving and loading of the HI-SCORE tables
        In the cassette version of the game, this area will be used for the Turbo Cassette routines.
0800 Reserved for Page 0 Copy
0900 Reserved for Page 2 Copy
0A00 Tables
1000 Game Samples (32K(Using upper and lower nibbles to double sample memory size))
5000 Permanent Animations/Sprites/Graphics memory
6000 HIRES Buffer
8800 Game Machine Code
A000 HIRES Inlay for displaying the Lands,Sea and Worm game arena
B2BF HIRES to TEXT attribute (Only one byte actually required!)
B2C0 Tables
B500 The Standard character set for the TEXT graphics
B800 Tables
B900 The alternate character set for the Message Text
BB80 Message Table
BE00 TEXT Screen
BFDF TEXT to HIRES Attribute (One byte required!)
BFE0 Permanent game variables such as language, HI-scores, one or two player game, Sound On/Off
C000 Music Code and Tunes
All the areas as yet assigned for Tables may get used for other purposes. I think i have covered all areas, but there are always amendments to be made.
6144 bytes have been assigned for the games Machine code. This should suffice, 
The HIRES buffer area will have a dual purpose. Each levels data and new arena will be loaded into this area. Then, the levels data will be extracted from this point leaving the space for the HIRES Wide Screen and any further Worm Animation buffers as required.
The message table will hold all the text messages within the game.
Each Player will take his/her turn to select a Worm,weapon, angle of trajectory and velocity. Each player (On his/her turn) will also be given the facility to flip the screen left/right to view the whole arena and judge the best manouvre to make on the opposition.
There will be background music, but only on the disc version of the game. This will consist of chip sounds only.
There will be Sound Samples on both formats to represent the comical nature of the worms! and to add a sparkle to the monochromatic graphics.
Oric Project Members
This is how i see each member taking part in the Project.
The requirements that i am expecting from each team member is based on the pool of information given to me, by you as to your competence in the available areas within the game.
Please read all the members areas so that you can gather the resources from the whole group.
I have used your first names to identify you unless a nickname has been found (fortunately, all first names are unique within the group!). If you would like to be known under another name, then this is the time to let the group know!
Alexios, Can you do the Title Menu Screen (Observing the same HIRES inlay/Text ratio as previously described) and background Code. It is up to you to liase with the appropriate people to establish links to the other sections of the game.
The titlecode will be an integral part of the game in memory, with only the game levels, Title screen (If in HIRES) hiscores and music files being stored on disc.
Bernhard, Hans, Laurent & Raul
Game ideas required of you lot, to be sent to the Group in general. This is an intrinsic part of the development of the project. If wanted, you may also become Game-Testers in order to deliver some constructive feedback.
The group will need ideas on types of missiles and their characteristics, Level scenarios, Short effective sampled words!, Simple Melodies/Musical tunes and whatever else the group calls out for.
Matt and David
Can you manage the English messages for the game?. This is a block of 640 Bytes used to hold all messages for the game. You will be contacted by various members of the group for messages to go into the game. Rely on a maximum of 64 messages to start with. These may be as simple as "OUCH!!" or "That really did hurt!". when a message is required, it is up to you to decide on the appropriate phrase to use, and to return the number of the message to the appropriate person. Eg. Number 10 ="OUCH!!"
It is up to you to use 1 byte for each character used (including spaces and punctuation marks) and to limit the number of characters within the whole message block to 640 bytes.
Please take note of each messages start position within the block, so that a table can be written at the end to point to each one.
David, will you take the helm to be the recipient of all the messages required?
Symoon, Dominic
Additional Coding areas. These will become more apparent as time goes by. If you feel up to it, can you do some Worm animations. Following the same procedures as i have given Kamel, Oguzhan and Jede.
Can one of you, or both of you also manage the French messages as set in english by Matt's task?
If so, can you please contact David (if he agrees to the above) as far as message numbers and phrases required.
Mike, can you handle the main Control System, comprising of the switching between the two players, the control of each player to set the angle and velocity of the trajectory and the setting of the weapon to be used.
Fabrice will hopefully be handling the Trajectory Code, so please contact each other accordingly.
Also, can you set up part of your site dedicating it to the Developing Project cycle.
Fabrice, do you feal you can handle the Disc Access routines?, since i plan to use the top 16K of RAM for music data in the disc version of the game. Could you also write a small routine to switch out the ROM at startup.
In addition, could you handle the Central trajectory code. The code is required to expect two inputs. Angle of trajectory and velocity. In addition, the current X/Y coordinates may be read from a location in Page 2 in order that the missile or bomb sprite can set off from. Liase with DBUG for the Player control code
Kamel, can you do levels 7 through 9. Also, have a go at the Worm animations. These will consist of a cycle of animations to make the worm appear to move from left to right, from right to left, to crouch then jump, to hold a weapon and point it up,left right and down. As for further details, see the notes given to Oguzhan and Jede.
For Level Format, please refer to other parts of this newsletter.
Jim, might i ask you to handle the game Testing of the various sections of the game, reporting back to each individual via the group in general.
Creation of Level Screens from Level 1 through Level 3. Please adhere to the format as mentioned within this Newsletter. Can you also design some Worm animations using the same format as that used by Jede. Sending them to the group for judging.
As for further details, see the notes given to Kamel and Jede.
For Level Format, please refer to other parts of this newsletter.
Jede, can you create levels 4 through 6 observing the same rules as for Oguzhan.
Can you also do some animations of the main Worm sprite. I would like to see this sprite no higher than 7 pixels and no wider than 6!, to give each worm a larger playing area. The number of animations can be up to 16 for each movement left and right. Use a character editor to create the animation and then send them to the group as a file for all of us to judge.
As for further details, see the notes given to Oguzhan and Kamel.
For Level Format, please refer to other parts of this newsletter.
Me (Twilight)
I will handle the Newsletter, reporting on the project development.
I will also handle the Music and Sample side of the game and memory management. If any of you feel that you have the talent to unload me or anyone elses jobs within the game, then please let me or them or the group know.
I will also work (If no other offers are put forward) on an Editor to design the Wider screans for each Level. This may take a little time, so, all those out there that have been assigned levels to do, please either work on some PC Picture editor or remain patient for the utility. It will not be as flexible as some paint packages, but will enable the whole arena to be drawn.
Screen shots of the work in progress should appear on DBUGs WEB-Site,
in addition to extra material to do with the project, system resources and memory management
as long as he agrees. The rest of you are free to put as much project information on your own sites (Particularly, you own material to do with the project in the group), so long as we can all remember that DBUGs site is the main representation of the Oric Project.
I foresee that we must all first concentrate on the central game aspect. Other features such as the mentioned Movie sequence, Intro/Outro sections and Name of the game can be dealt with when the basic game structure, code and levels have been completed.
The game will be programmed in 100% Machine code, C may be used as a programming tool(I think) so long as the effective resultant code is in 6502. Memory will be portioned out on demand and so long as the 48/64K stretches.
Coders requiring pieces of the available memory for their code should approach solely me in order that their is no clash in memory usage of each others code. 
Could you all please respond to this Group mailing. If only to notify to me that you have recieved the newsletter!
I do not want some people to return asking why they have not recieved anything from me or the group!
Please excuse any spelling errors, punctuation faults or words too obscure for anyone to understand. I know that certain members have difficulty reading English, and i respect this whole-heartedly but have tried to write in English, as best as possible!
And last, but not least, Have Fun!