Impossible Mission
As i say, i only discovered it recently. However the 80's game Phsychiatric used a split line technique (similar to wurlde scheme) in order to display both hero and platform.
I thought my internet connection was down or something cos my laptop taskes 5 minutes to load each page. Then i tried it on this mininote laptop and its fine, so vista crap again then!
Log..
implemented the new running frames into the code again, tested and works much nicer. Also captured half the new furniture graphics and found i have to reshuffle the screen layouts for each room that contains them. But all looking peachy atm.
Now trying to work out the best strategy to move the hero (Ethan). Currently Ethan can run left and right and jump (Although a bit corrupted atm).
To calculate the correct number of steps for each running frame i laid all the running right frames onto an image and adjusted the xpos until they looked correct (feet synchronised to floor) as follows..
First i need to detect the floor (I already use a collision map for this and detecting other stuff like robot, spark, wall and terminal collisions) and make Ethan fall (potentially off screen). Next i need to get Ethans jump todetect platforms. Some screens in IM lack liftsbut have half height platforms. Ethan could jump onto these then jump again to get onto the full height platform. Very nice but potasntially nasty to code.
I think i may tie Ethan to 1 of 7 levels(Platforms). 4 full height platforms and 3 half height ones.
The screen below illustrates the height of the jump frames in respect to the robots and the half height floor..
The red dots mark the top left of each frame so i am now able to determine the verticasl (y) step each jumping frame needs to take.
Apologies for mistakes above. Using mininote with mini keyboard with long fingernails and stubby fingers
I thought my internet connection was down or something cos my laptop taskes 5 minutes to load each page. Then i tried it on this mininote laptop and its fine, so vista crap again then!
Log..
implemented the new running frames into the code again, tested and works much nicer. Also captured half the new furniture graphics and found i have to reshuffle the screen layouts for each room that contains them. But all looking peachy atm.
Now trying to work out the best strategy to move the hero (Ethan). Currently Ethan can run left and right and jump (Although a bit corrupted atm).
To calculate the correct number of steps for each running frame i laid all the running right frames onto an image and adjusted the xpos until they looked correct (feet synchronised to floor) as follows..
First i need to detect the floor (I already use a collision map for this and detecting other stuff like robot, spark, wall and terminal collisions) and make Ethan fall (potentially off screen). Next i need to get Ethans jump todetect platforms. Some screens in IM lack liftsbut have half height platforms. Ethan could jump onto these then jump again to get onto the full height platform. Very nice but potasntially nasty to code.
I think i may tie Ethan to 1 of 7 levels(Platforms). 4 full height platforms and 3 half height ones.
The screen below illustrates the height of the jump frames in respect to the robots and the half height floor..
The red dots mark the top left of each frame so i am now able to determine the verticasl (y) step each jumping frame needs to take.
Apologies for mistakes above. Using mininote with mini keyboard with long fingernails and stubby fingers
I ran into this with Firefox. If I don't exit it periodically or have too many windows open I get really slow connections. Other programs don't seem to have the problem.Twilighte wrote:I thought my internet connection was down or something cos my laptop taskes 5 minutes to load each page. Then i tried it on this mininote laptop and its fine, so vista crap again then!
I think its just Vista. I really have to find an XP install and be done with it.
Log..
Not so much done yesterday since i was in London for an MRI scan
Nevertheless managed to get Ethan to search items using a different frame height than standing
I have now moved on to redoing the collision code which will now be based on a 40 column collision map.
All but the hero will be stored in the collision map. This includes sparks, Robots, furniture, Terminals, platforms, Simon computer, lifts and walls.
Also added the jumping vertical steps and worked out the collision cells used by the hero jumping frames
Log..
Not so much done yesterday since i was in London for an MRI scan
Nevertheless managed to get Ethan to search items using a different frame height than standing
I have now moved on to redoing the collision code which will now be based on a 40 column collision map.
All but the hero will be stored in the collision map. This includes sparks, Robots, furniture, Terminals, platforms, Simon computer, lifts and walls.
Also added the jumping vertical steps and worked out the collision cells used by the hero jumping frames
Well if you were really crazy you could always nab the frames shown and change your iconChema wrote:Man, your designs are incredible. Movement is using quite a lot of frames, so I am really wishing to see this working !
Then when the game is finally released people will tell me i stole the design from you
I guess i could have kept to the original C64 format (Wouldn't touch the Spectrum sprites because they were just plain lame!) and resized but i definately felt they would not work well on a dithered backdrop. Also by placing a black outline around the top part of the body it makes the whole sprite alot more distinct from any backdrop.
I just hope i can work out these special jumping behaviours. I thought the lift section was gonna be a show stopper but now i am starting to get really concerned over this new tricky stuff.
One potantial problem is as the hero jumps over the half platform there is nothing (in the collision map) to prevent him continueing some feet before he stands again. But i guess it just means i need to cross examine the original game behaviour.
Unless someone can point me to an article or interview with the Author about the game design. But not the original source code which i know about already
Twilighte wrote: Well if you were really crazy you could always nab the frames shown and change your icon
Then when the game is finally released people will tell me i stole the design from you
Ok, got it. In fact when I thought about an avatar for me, just wanted to put something related to isometric perspective and Space:1999. For anybody not knowing yet: all graphics in Space:1999 are Twilighte's, including my avatar I suppose I should have asked for your permission
I should think about a replacement, anyway... Maybe something related to Elite, if I ever got it nearly finished.
Yep. As long as you are able, it is allways better to redesign. They are currently very nice!I guess i could have kept to the original C64 format (Wouldn't touch the Spectrum sprites because they were just plain lame!) and resized but i definately felt they would not work well on a dithered backdrop. Also by placing a black outline around the top part of the body it makes the whole sprite alot more distinct from any backdrop.
Don't know if I got it. You mean that what is drawn in your picture above is not the preferred behaviour? (jumping over the half platform and falling away from it).I just hope i can work out these special jumping behaviours. I thought the lift section was gonna be a show stopper but now i am starting to get really concerned over this new tricky stuff.
One potantial problem is as the hero jumps over the half platform there is nothing (in the collision map) to prevent him continueing some feet before he stands again. But i guess it just means i need to cross examine the original game behaviour.
Unless someone can point me to an article or interview with the Author about the game design. But not the original source code which i know about already
Edit: just realized that a new icon with a Cobra ship rotating (for instance) would have the same problem: it is not my design... urgh.
Actually half true, i think i did the bottom half, i think u did the heads. Anyway joint effort.Chema wrote:Ok, got it. In fact when I thought about an avatar for me, just wanted to put something related to isometric perspective and Space:1999. For anybody not knowing yet: all graphics in Space:1999 are Twilighte's, including my avatar
For Icon i think the one you chose is very cool and we have come to recognise that as you, if not simply because you wrote the best Isometric game on the oric
And before you jump to the conclusion that i designed all those frames by myself i didn't completely. The legs were captured from the original C64 game, resized 75% and edited quite alot.
There are two behaviours. If Ethan stands far enough away he should be able to jump onto the half height platform and remain at the half height rather than falling off the other side. This is as per the original game on C64.Chema wrote:Don't know if I got it. You mean that what is drawn in your picture above is not the preferred behaviour? (jumping over the half platform and falling away from it).
Though i believe the original didn't have a platform less than 3 bytes wide.
The other behaviour was the jump over and land after as detailed in the picture.
Interview...
Hi,
I found the source code and as I'm a little bit paranoid, I take the joke for myself
I hope that this interview of the author will help you understand the design, which start with coding a running man...
http://www.mayhem64.co.uk/interview/caswell.htm
Don't forget to read also the overview and history available on the site remake for PSP/DS at : http://www.grinlock.com/websites/impossiblemission/
>Unless someone can point me to an article or interview with the Author >about the game design. But not the original source code which i know >about already[/quote]
I found the source code and as I'm a little bit paranoid, I take the joke for myself
I hope that this interview of the author will help you understand the design, which start with coding a running man...
http://www.mayhem64.co.uk/interview/caswell.htm
Don't forget to read also the overview and history available on the site remake for PSP/DS at : http://www.grinlock.com/websites/impossiblemission/
>Unless someone can point me to an article or interview with the Author >about the game design. But not the original source code which i know >about already
[/quote]/kml
skype pseudo : kamelitoloveless
skype pseudo : kamelitoloveless
Thanks for that Kamelito, i was about to complain you'd provided the source code links but the interview was definately new to me and showed just a little insight into the game design. Not sure though about 10 months. Though it may take that long (or short )
The second link to the IM for WII etc. was interesting but it appears all the retro information was lifted from that interview and stuff i already knew.
It is surprising how much you can absorb about the background mechanics of a game just by playing it.
Thanks again
)The second link to the IM for WII etc. was interesting but it appears all the retro information was lifted from that interview and stuff i already knew.
It is surprising how much you can absorb about the background mechanics of a game just by playing it.
Thanks again
Puzzle
Yep, the site seems to be a rip off...I suppose that they didn't find the author, in the site they even mispelled its name "Cadwell" instead of "Caswell".
I found this site about an implementation of the puzzle.
http://www.linuxmotors.com/puzzle/
Kamel
I found this site about an implementation of the puzzle.
http://www.linuxmotors.com/puzzle/
Kamel
Twilighte wrote:Thanks for that Kamelito, i was about to complain you'd provided the source code links but the interview was definately new to me and showed just a little insight into the game design. Not sure though about 10 months. Though it may take that long (or short
The second link to the IM for WII etc. was interesting but it appears all the retro information was lifted from that interview and stuff i already knew.
It is surprising how much you can absorb about the background mechanics of a game just by playing it.
Thanks again
/kml
skype pseudo : kamelitoloveless
skype pseudo : kamelitoloveless
That last link is very cool. If anyone wants to have a go in designing some similar ones but this time make them simpler then i may use them in the game. Remember unlike the above linked Linux game these require random black dots to signify holes in a punchcard.
The required format is 7 codes (rather than 9 in original game), 4 sets (like original) and the pieces themselves are 24x8 pixels.
That means 28 puzzle pieces.
Naturally you will be creditted in the game if you provide the puzzle pieces.
Log..
Been busy tonight. Got Ethan falling now. Fixed collision code for Lift shaft (wasn't clearing area so could walk across top of shaft).
Also got jumping frames working (albeit with some bad steps at the end).
I now have to iron out the bugs and try jumping him onto a half height platform
The required format is 7 codes (rather than 9 in original game), 4 sets (like original) and the pieces themselves are 24x8 pixels.
That means 28 puzzle pieces.
Naturally you will be creditted in the game if you provide the puzzle pieces.
Log..
Been busy tonight. Got Ethan falling now. Fixed collision code for Lift shaft (wasn't clearing area so could walk across top of shaft).
Also got jumping frames working (albeit with some bad steps at the end).
I now have to iron out the bugs and try jumping him onto a half height platform
Ok not so productive yesterday since i was at a wedding for most of the day (not mine i might add!). However have returned thinking a bit differently about the frames for the hero.
Currently i store both left and right frames for running and jumping.
In addition all frames have an associated mask exactly the same size.
However after reading an interview with the original IM author he mentioned he mirrored Ethan in realtime to save half the amount of bytes used by the left frames. This makes alot of sense since their is little happening in cpu terms that requires the plotting of Ethan to be very fast.
The complete size of all frames for running and jumping right is 1524 bytes. The additional code and tables for mirroring will take about 128 bytes, so thats a saving of a whopping 1400 odd bytes!
But also the height of the mask and the height of the Bitmaps are actually very different in design. Such that the mask contains the legs, body, head hair and black arm outline whilst the bitmap just contains the face and arms. So i have recaptured the running frames (at least) only captureing the height used by each frame.
I have also changed the format of the Table that defines the height of each hero frame on a level.
Currently this defined the next offset that Ethans frame should rise or fall relative to the previous.
However on thinking about it a bit more it makes more sense to make this table hold the offset from the current level (platform) up for a frame.
This makes it much easier to synchronise(tie) Ethan to the platform.
Note Platforms are those visible objects that Ethan stands on whereas levels are markers on the screen that define the possible existance of a platform.
And since i am dealing with Levels rather than platforms jumping across or into a chasm will not cause a problem.
Just need to get these changes coded now
Currently i store both left and right frames for running and jumping.
In addition all frames have an associated mask exactly the same size.
However after reading an interview with the original IM author he mentioned he mirrored Ethan in realtime to save half the amount of bytes used by the left frames. This makes alot of sense since their is little happening in cpu terms that requires the plotting of Ethan to be very fast.
The complete size of all frames for running and jumping right is 1524 bytes. The additional code and tables for mirroring will take about 128 bytes, so thats a saving of a whopping 1400 odd bytes!
But also the height of the mask and the height of the Bitmaps are actually very different in design. Such that the mask contains the legs, body, head hair and black arm outline whilst the bitmap just contains the face and arms. So i have recaptured the running frames (at least) only captureing the height used by each frame.
I have also changed the format of the Table that defines the height of each hero frame on a level.
Currently this defined the next offset that Ethans frame should rise or fall relative to the previous.
However on thinking about it a bit more it makes more sense to make this table hold the offset from the current level (platform) up for a frame.
This makes it much easier to synchronise(tie) Ethan to the platform.
Note Platforms are those visible objects that Ethan stands on whereas levels are markers on the screen that define the possible existance of a platform.
And since i am dealing with Levels rather than platforms jumping across or into a chasm will not cause a problem.
Just need to get these changes coded now
Twilighte sit down please
Twilighte,
I'm in contact with the C64 author of IM.
He told me how he can help...
I propose that you sent me a list of questions who cover everything you need to know about IM and I'll sent it to him. As I don't want to disturb him more than needed I suppose that you need to be as complete as possible to avoid bothering him too much...
kamel.biskri AT free DOT fr
How about that?
regards
kamel
I'm in contact with the C64 author of IM.
He told me how he can help...
I propose that you sent me a list of questions who cover everything you need to know about IM and I'll sent it to him. As I don't want to disturb him more than needed I suppose that you need to be as complete as possible to avoid bothering him too much...
kamel.biskri AT free DOT fr
How about that?
regards
kamel
/kml
skype pseudo : kamelitoloveless
skype pseudo : kamelitoloveless
Hi kamelito, that is great and i may need his help at some time in the future but for now i am quite ok with all of it. I believe i have figured out how to rise the hero when he's jumping onto a half platform or lift.
To me that is pretty much most of the difficult bit.
I have made the changes in the code of all the above stuff (including mirroring) and have compiled the code successfully but now i'll need to test it all and watch all those nasty bugs suddenly appear again
I guess one question that does spring to mind at the moment is if the Puzzles were drawn at new game by the computer or just flipped/coloured randomly?
To me that is pretty much most of the difficult bit.
I have made the changes in the code of all the above stuff (including mirroring) and have compiled the code successfully but now i'll need to test it all and watch all those nasty bugs suddenly appear again
I guess one question that does spring to mind at the moment is if the Puzzles were drawn at new game by the computer or just flipped/coloured randomly?