strange coincidence... http://speccygames.webz.cz/4k.png
this is screenshot of game which is under development for minigame compo..
of course, it is not bejewelled, it is based on Zoo Keeper :D
strange coincidence... http://speccygames.webz.cz/4k.png
this is screenshot of game which is under development for minigame compo..
of course, it is not bejewelled, it is based on Zoo Keeper :D
Bejewelled is based on Zoo Keeper and a couple of other related games apparently. (from the wiki website)
Remember guys, this whole exercise is about team work more than it is about the game we are going to make.
I suppose it has turned into an experiment to see if a strange bunch of guys from all over the world can come together and create something for a 25 year old computer.
I for one, hope we can do it.
I will be starting some of the game coding this weekend.
Mr. Millside (Iron Sphere) has kindly donated some of his valuable time to do the menu and high score table.
If redballon or any others would like to email me about the screen design/layout please do so and I will also start on the game design document for us all to work from.
Hopefully fogartylee will have the project section of the sinclair heaven website setup for us to place our graphics, code and documents into soon.
my email is tommygun[dot]ide[at]gmail[dot]com <- anti-spam version :-)
I definitely agree.
Although at 8x8 the tiles/blocks would have to be 16x16 pixels so they fit into an area of 192x192 pixels.
Leaving 64 pixels to the left or right of the screen for a score panel.
Oops! :-(
Apparently my maths and use of a calculator are terrible.
With an 8x8 grid placed to fill 192x192 pixels, the tiles would be 24x24 pixels not 16x16 pixels.
Although if we used 16x16 pixels we could get a border around the play area and also a place for the score panel.
But thats up to the person designing the screen layout and the game tiles. Redballon? Swainy?
I should hopefully have the mock-up graphics for you over the next couple of days. I'll email them to you as well as posting a link up here for those interested in seeing what they look like.
So who is interested in helping?
Please state your name (nick), what you would like to help with, and the amount of hours per week your free to help, and maybe where you are?
I'll start,
Nick: Kiwi
Can do: TommyGun plugins and Z80 coding
Hours per week: ~10 hours
Where: I'm in Sydney, Australia.
I'm up for a bit of coding and have been in discussion with Kiwi through private eMail.
Nick: Retrocoder
Can do: Z80 coding + stuff no one else will touch apart from music :(
Hours per week: <= 5
Where: I'm in Harlow, Essex, England.
Yep i was gonna say i'll be quite happy to do any testing.
I would love to see Speccy versions of Zelda / Mario Land style games. I know a fair few people like original games but arcade conversions were huge for the Speccy also. Some Speccy conversions of Zelda/Mario Land style games would be brilliant.
Yeah, no. I meant the game system, not coding. I am planning to implement it in the open source ufo2000, but I know nothing about the ZX Spectrum development.
So, I proposed an idea, as Kiwi asked. The game system is quite simple and it's not difficult to code. Maybe I'll post it right here when I write a normal english specification for it.
And it's based on the turn-based x-com-like system, but is much more realistic, reducing turn-based-ness to a higher degree than the standard reaction fire implemented in the x-com.
Yeah, no. I meant the game system, not coding. I am planning to implement it in the open source ufo2000, but I know nothing about the ZX Spectrum development.
Right now we are trying to get a simple puzzle game off the ground, so a complex X-Com type game will have to wait! :)
Perhaps multiplayer.
Player vs. CPU (where the CPU's name is Lucky)
Collect something or other (points, lucky objects, whatever) and try to get more than Lucky.
Play with words obviously ... erm ... play with the sexual connotations etc.
Perhaps multiplayer.
Player vs. CPU (where the CPU's name is Lucky)
Collect something or other (points, lucky objects, whatever) and try to get more than Lucky.
Play with words obviously ... erm ... play with the sexual connotations etc.
Skruppy
>=}
Oh, I thought it would be about a car insurance advert...
Yeah, no. I meant the game system, not coding. I am planning to implement it in the open source ufo2000, but I know nothing about the ZX Spectrum development.
So, I proposed an idea, as Kiwi asked. The game system is quite simple and it's not difficult to code. Maybe I'll post it right here when I write a normal english specification for it.
And it's based on the turn-based x-com-like system, but is much more realistic, reducing turn-based-ness to a higher degree than the standard reaction fire implemented in the x-com.
If you would like to finish the specification, you can publish it on the project web site at sinclair heaven when fogartylee has it up and running soon.
Anybody with new game ideas should be able to post their ideas there, and hopefully we or some other team of programmers and designers will help make it happen.
I hereby post the first discussion of my idea. Take into account that now my system has changed and improved as compared to the one described here.
I could't give a link because the site's died.
The following discussion is reprinted without any corrections, original orthography and punctuation are preserved.
Hello all!
This post is very big but I'am sure that who is really interested will
patiently read it.
Here I want to present some ideas on the reaction fire system. In order
to give as comprehensive description as possible I have placed here not
only the description of my system but it's discussion at the EDF Projegct
forum:
Beginning of citation
-----------------------------------------------------------------------
Me:
Hello! I have always been dreaming about multiplayer UFO. And I have
found it now! Thank you very much for this game!
Here I propose two versions of the reaction fire mechanism. The first
is similar to it in the original game. The second is my own version.
Please, have patience and read it.
A, C - the units whose turn is now;
B - the unit which have reserved some TU for a shot.
1st version
When A is revealed by B but A don't see B then this unit will shoot at
A. But if they revealed each other simultaneously (when A caught sight of
B, B marked A) who will shoot first must depemd on:
1. Reaction of both players.
2. Their experience and morale.
3. The angles between the current direction of look and the direction
to the target for both units. The less the angle the faster the unit can
turn to the target and shoot.
4. Weapon characteristics. The harder and bigger the weapon the slower
the unit can turn.
The full time it takes the unit to turn, take aim and shoot is
calculated using theese four factors. The unit which it takes less time
will shoot first.
And maybe it would be good if you added some random factor.
If you find this version good I will think about the formulas.
2nd version (first draft which can have mistakes and uncertainty)
In the second version I propose to calculate who shoots first via the
amount of time units saved by B for the shoot. If he've saved 17TU then he
will be able to shoot after A spends 17TU for anything after he have been
revealed by B.
1. If A will try to shoot at B with aimed shot which takes 24TU for
example then B will shoot first becouse it will take him only 17TU to
shoot. Only after that (if B haven't killed A) A will be able to shoot.
2. If A see B and tries to fire snapshot wich takes 14TU then he will
shoot first. And he will now have (17-14=3) TU before B shoots at him
provided he see A.
3. If A doesn't shoot then he can spent 17TU for moving before B will
be able to shoot at him (if B can see A) or both for moving and shooting.
All teammates of A can spend 17TU before B shoots. Right after A or any of
his teammates spend 17TU B shoots.
That means that time which have passed still B had revealed A is equal
to the maximum ammount of TU spent by any teammates of A and A himself.
If only 3TU left (17-14) before B can shoot and B have not been killed
then B will shoot at A when A tries to move because moving requires at
least 4TU.
RESUME
The second version is based on the two main statements
1. B which have reserved time units can shoot after the target unit or
any his teammate spends this amount time units to anything irregardless to
what exatly: moves or shots. That gives more realism. The time is common
for all units of the team. The advantage of such a system can be shown in
the following example:
Classic Microprose system:
A suddenly revealed B when A has no enough TUs for a shot. If C is in
60TUs distance the player can move C to help A. C will come and shot (he
will have 20TUs left) and probably save his teammate.
But in reality in this situation B have enough time to shot at A before
C comes to help A! He has 60TUs for this. But since A havent moved since
he revealed B, B has no enough reaction to fire at A.
In my mechanism C will not be able to help becouse B will shot after B
spents the time needed for B to make a shot. (17TU for a snapshot for
examle, not 60). This is close to reality: B shots before C comes.
But if C and A were going together covering each other they will have a
chance to shot but in this case too B can shot first if it takes him less
time to shot then for C, counting the time from the moment when B revealed
C. Of course B could not have revealed C becouse he was looking along
another direction.
2. The unit shoots after the time needed for the shot have passed. So
if two units try to shoot at each other it is easy to calculate who shoots
first. You shoud only check the maximum ammount of TU spent by A or his
teammates after A was revealed by B. If A makes a shot that takes less
time then the difference of the time B have reserved and the time which
have passed since A was revealed by B (A crouched for example) , A is the
first otherwise B is the first.
There are some cases which need specification.
1. If A see B and B don't see A (If he is currently looking to other
side, for example) and A shoots at B and misses. In this case B have heard
the shot and can turn to the sound and reveal A. If he still have TU
enough to shoot (He reversed time for aimed shot and after he turned
around he have time enough for snapshot) then he can shoot (after A spends
this amount of time for anything).
2. If both units need the same amount of time to shoot I propose to
calculate who is the first via random number 50/50, their experience and
reaction.
In order to take the reaction into consideration I propose to increase
the time needed for a shot by a value which is the less the better the
reaction is.
I think this version is more realistic then the first.
In this version turn based mechanism simulates reality better then with
the classic engine becouse the time in it differs from real time less and
the result is less dependent on whose turn it is now. There are no turns
in real life but they are necessity in the game.
Sorry for my English.
Please, write what you think, ask questions.
-----------------------------------------------------------------------
Me:
An example
In the classic engine
If the time is not limited the most safe way to act is to advance
slowly saving time for aimed shot for every unit every turn.
In my engine
It is good to save time for aimed shot for snipers for example, but not
for all because they will not have time to take aim and shoot before
aliens shoot. It is closer to reality.
Anton Shepelev
-----------------------------------------------------------------------
<...> [- discussion too big, the forum doesn't allow such huge posts]
End of citation
I will be glad to have questions and comments.
Also I would appreciate if somebody posted a deteiled description of
the reaction fire mechanism which is currently to be implemented in
Xenocide.
For those who have read this entirely: thanks for your patience!
Anton Shepelev
If, after all this, it accidentally happens that somebody (still wants to read the whole discussion)/(is interested in the idea), I can post the resting part.
If you would like to finish the specification, you can publish it on the project web site at sinclair heaven when fogartylee has it up and running soon.
I think that the "Get more than Lucky" title is good. It puts me in mind of those old LCD games where you have to catch people jumping off a burning building, but instead you have a dog ("Lucky"), who is constantly pulling bricks down on your car. You have to avoid the bricks in order to win insurance money.
I think that the "Get more than Lucky" title is good. It puts me in mind of those old LCD games where you have to catch people jumping off a burning building,
D.
By the way, there is a Spectrum game pretti similar to that LCD game, it was released last year in a speccy games contest in Spain, the game came out good. If you want to see it, just tell me!
While I finish off getting those Zelda-esque graphics into a format that I can show you all (it's close), why not mull this over. How about a Spectrum version of 'Exile'?
fogartylee has kindly allowed us to store files on the Shed web site.
I have the information to login and will forward it to people as they need it to store stuff.
So redballon, once your graphics are ready you can pm me and I will send you the info to upload you stuff.
I'm still in the process of getting a simple bejewelled demo working, with some programmer art in it (ie. lots of colourful boxes ;-) )
So redballon maybe once you've finished the zelda stuff you could please work on some bejewelled graphics.
I will also try to upload a basic game design document for bejewelled in the meantime.
This may take a week or so, for the basic demo and the design doc, as I have to take care of my wife next week, when she is recovering from a surgery.
So please forgive me if I'm a little late. :-)
Many thanks to Lee for access to the storage space.
So come on guys if you have any stuff you want to add pm me, and lets get going. Sorry if I'm holding you all up though, I'll get it done sooner or later. :-)
I think that the "Get more than Lucky" title is good. It puts me in mind of those old LCD games where you have to catch people jumping off a burning building, but instead you have a dog ("Lucky"), who is constantly pulling bricks down on your car. You have to avoid the bricks in order to win insurance money.
Or something.
D.
A lot of those lcd games were crap, did you ever notice that a lot of those games had the same gameplay where things were falling down and you had to keep hitting them before they touched the bottom, and you would have to keep hitting them until you hit them off the screen? Weather it was a cat and mouse game or a football game, you would play it exactly the same way and it would make the same tune and noise as well? lol what a con.
Comments
http://speccygames.webz.cz/4k.png
this is screenshot of game which is under development for minigame compo..
of course, it is not bejewelled, it is based on Zoo Keeper :D
Bejewelled is based on Zoo Keeper and a couple of other related games apparently. (from the wiki website)
Remember guys, this whole exercise is about team work more than it is about the game we are going to make.
I suppose it has turned into an experiment to see if a strange bunch of guys from all over the world can come together and create something for a 25 year old computer.
I for one, hope we can do it.
I will be starting some of the game coding this weekend.
Mr. Millside (Iron Sphere) has kindly donated some of his valuable time to do the menu and high score table.
If redballon or any others would like to email me about the screen design/layout please do so and I will also start on the game design document for us all to work from.
Hopefully fogartylee will have the project section of the sinclair heaven website setup for us to place our graphics, code and documents into soon.
my email is tommygun[dot]ide[at]gmail[dot]com <- anti-spam version :-)
Oops! :-(
Apparently my maths and use of a calculator are terrible.
With an 8x8 grid placed to fill 192x192 pixels, the tiles would be 24x24 pixels not 16x16 pixels.
Although if we used 16x16 pixels we could get a border around the play area and also a place for the score panel.
But thats up to the person designing the screen layout and the game tiles. Redballon? Swainy?
I'm up for a bit of coding and have been in discussion with Kiwi through private eMail.
Nick: Retrocoder
Can do: Z80 coding + stuff no one else will touch apart from music :(
Hours per week: <= 5
Where: I'm in Harlow, Essex, England.
Cant wait to see what will be created, i'm praying it wont just be vapourware ! All sounds brilliant at the moment !!
Necros.
T-1
he'll have knocked up another 47 in the time between that and the game being written
You know anyone and everyone can help in someway.
Even its being part of the "mel the bell" cheerleader group :-)
Once coding starts and we get a useable game, we'll need testers.
I would love to see Speccy versions of Zelda / Mario Land style games. I know a fair few people like original games but arcade conversions were huge for the Speccy also. Some Speccy conversions of Zelda/Mario Land style games would be brilliant.
Cant wait to see graphics etc
What about a nice isometric tactical turn-based game (like x-com), with hot-seat mode and advanced reaction fire system, which I'll create soon.
You mean you're working on such a game? Well, go for it!
Bytes:Chuntey - Spectrum tech blog.
How far have you got with it? Can we see some preview screens? What details can you tell us about the game so far?
D.
So, I proposed an idea, as Kiwi asked. The game system is quite simple and it's not difficult to code. Maybe I'll post it right here when I write a normal english specification for it.
And it's based on the turn-based x-com-like system, but is much more realistic, reducing turn-based-ness to a higher degree than the standard reaction fire implemented in the x-com.
Right now we are trying to get a simple puzzle game off the ground, so a complex X-Com type game will have to wait! :)
Bytes:Chuntey - Spectrum tech blog.
"Get More Than Lucky!"
Perhaps multiplayer.
Player vs. CPU (where the CPU's name is Lucky)
Collect something or other (points, lucky objects, whatever) and try to get more than Lucky.
Play with words obviously ... erm ... play with the sexual connotations etc.
Skruppy
>=}
If you would like to finish the specification, you can publish it on the project web site at sinclair heaven when fogartylee has it up and running soon.
Anybody with new game ideas should be able to post their ideas there, and hopefully we or some other team of programmers and designers will help make it happen.
Actually, I am serious.
I hereby post the first discussion of my idea. Take into account that now my system has changed and improved as compared to the one described here.
I could't give a link because the site's died.
The following discussion is reprinted without any corrections, original orthography and punctuation are preserved.
Hello all! This post is very big but I'am sure that who is really interested will patiently read it. Here I want to present some ideas on the reaction fire system. In order to give as comprehensive description as possible I have placed here not only the description of my system but it's discussion at the EDF Projegct forum: Beginning of citation ----------------------------------------------------------------------- Me: Hello! I have always been dreaming about multiplayer UFO. And I have found it now! Thank you very much for this game! Here I propose two versions of the reaction fire mechanism. The first is similar to it in the original game. The second is my own version. Please, have patience and read it. A, C - the units whose turn is now; B - the unit which have reserved some TU for a shot. 1st version When A is revealed by B but A don't see B then this unit will shoot at A. But if they revealed each other simultaneously (when A caught sight of B, B marked A) who will shoot first must depemd on: 1. Reaction of both players. 2. Their experience and morale. 3. The angles between the current direction of look and the direction to the target for both units. The less the angle the faster the unit can turn to the target and shoot. 4. Weapon characteristics. The harder and bigger the weapon the slower the unit can turn. The full time it takes the unit to turn, take aim and shoot is calculated using theese four factors. The unit which it takes less time will shoot first. And maybe it would be good if you added some random factor. If you find this version good I will think about the formulas. 2nd version (first draft which can have mistakes and uncertainty) In the second version I propose to calculate who shoots first via the amount of time units saved by B for the shoot. If he've saved 17TU then he will be able to shoot after A spends 17TU for anything after he have been revealed by B. 1. If A will try to shoot at B with aimed shot which takes 24TU for example then B will shoot first becouse it will take him only 17TU to shoot. Only after that (if B haven't killed A) A will be able to shoot. 2. If A see B and tries to fire snapshot wich takes 14TU then he will shoot first. And he will now have (17-14=3) TU before B shoots at him provided he see A. 3. If A doesn't shoot then he can spent 17TU for moving before B will be able to shoot at him (if B can see A) or both for moving and shooting. All teammates of A can spend 17TU before B shoots. Right after A or any of his teammates spend 17TU B shoots. That means that time which have passed still B had revealed A is equal to the maximum ammount of TU spent by any teammates of A and A himself. If only 3TU left (17-14) before B can shoot and B have not been killed then B will shoot at A when A tries to move because moving requires at least 4TU. RESUME The second version is based on the two main statements 1. B which have reserved time units can shoot after the target unit or any his teammate spends this amount time units to anything irregardless to what exatly: moves or shots. That gives more realism. The time is common for all units of the team. The advantage of such a system can be shown in the following example: Classic Microprose system: A suddenly revealed B when A has no enough TUs for a shot. If C is in 60TUs distance the player can move C to help A. C will come and shot (he will have 20TUs left) and probably save his teammate. But in reality in this situation B have enough time to shot at A before C comes to help A! He has 60TUs for this. But since A havent moved since he revealed B, B has no enough reaction to fire at A. In my mechanism C will not be able to help becouse B will shot after B spents the time needed for B to make a shot. (17TU for a snapshot for examle, not 60). This is close to reality: B shots before C comes. But if C and A were going together covering each other they will have a chance to shot but in this case too B can shot first if it takes him less time to shot then for C, counting the time from the moment when B revealed C. Of course B could not have revealed C becouse he was looking along another direction. 2. The unit shoots after the time needed for the shot have passed. So if two units try to shoot at each other it is easy to calculate who shoots first. You shoud only check the maximum ammount of TU spent by A or his teammates after A was revealed by B. If A makes a shot that takes less time then the difference of the time B have reserved and the time which have passed since A was revealed by B (A crouched for example) , A is the first otherwise B is the first. There are some cases which need specification. 1. If A see B and B don't see A (If he is currently looking to other side, for example) and A shoots at B and misses. In this case B have heard the shot and can turn to the sound and reveal A. If he still have TU enough to shoot (He reversed time for aimed shot and after he turned around he have time enough for snapshot) then he can shoot (after A spends this amount of time for anything). 2. If both units need the same amount of time to shoot I propose to calculate who is the first via random number 50/50, their experience and reaction. In order to take the reaction into consideration I propose to increase the time needed for a shot by a value which is the less the better the reaction is. I think this version is more realistic then the first. In this version turn based mechanism simulates reality better then with the classic engine becouse the time in it differs from real time less and the result is less dependent on whose turn it is now. There are no turns in real life but they are necessity in the game. Sorry for my English. Please, write what you think, ask questions. ----------------------------------------------------------------------- Me: An example In the classic engine If the time is not limited the most safe way to act is to advance slowly saving time for aimed shot for every unit every turn. In my engine It is good to save time for aimed shot for snipers for example, but not for all because they will not have time to take aim and shoot before aliens shoot. It is closer to reality. Anton Shepelev ----------------------------------------------------------------------- <...> [- discussion too big, the forum doesn't allow such huge posts] End of citation I will be glad to have questions and comments. Also I would appreciate if somebody posted a deteiled description of the reaction fire mechanism which is currently to be implemented in Xenocide. For those who have read this entirely: thanks for your patience! Anton ShepelevIf, after all this, it accidentally happens that somebody (still wants to read the whole discussion)/(is interested in the idea), I can post the resting part.
Ok, I'll keep it in mind...
http://www.dcsnake.narod.ru/ — bad English, terrible hosting... but you should manage to download the game.
Or something.
D.
By the way, there is a Spectrum game pretti similar to that LCD game, it was released last year in a speccy games contest in Spain, the game came out good. If you want to see it, just tell me!
Bye
Regards
yes, and for PC. I mean a Futurama game for Spectrum.
Bye
I have the information to login and will forward it to people as they need it to store stuff.
So redballon, once your graphics are ready you can pm me and I will send you the info to upload you stuff.
I'm still in the process of getting a simple bejewelled demo working, with some programmer art in it (ie. lots of colourful boxes ;-) )
So redballon maybe once you've finished the zelda stuff you could please work on some bejewelled graphics.
I will also try to upload a basic game design document for bejewelled in the meantime.
This may take a week or so, for the basic demo and the design doc, as I have to take care of my wife next week, when she is recovering from a surgery.
So please forgive me if I'm a little late. :-)
Many thanks to Lee for access to the storage space.
So come on guys if you have any stuff you want to add pm me, and lets get going. Sorry if I'm holding you all up though, I'll get it done sooner or later. :-)
Cheers
I have uploaded some pics onto my internet connection webspace.
http://www.users.on.net/~tonyt73/gems.bmp
http://www.users.on.net/~tonyt73/gems.jpg
Both are the same picture, the jpg loads faster is all.
Its using programmer graphics, but I think they are ok for now.
I will be uploading a .tap file in the next week or so.
I also upload the TommyGun project file and game source code.