Yeah I feel comfortable with it.General
Forum rules
This forum houses many years of development, tracing back to some of the earliest posts that exist on the board.
Its current use is for the continued development of the server and game it has always served: TMW Classic.
-
ElvenProgrammer
- Founder
- Posts: 2526
- Joined: 13 Apr 2004, 19:11
- Location: Italy
- Contact:
TMW Italian community-
mandrake1983
- Peon
- Posts: 43
- Joined: 07 Jun 2005, 12:12
- Location: Germany
-
ElvenProgrammer
- Founder
- Posts: 2526
- Joined: 13 Apr 2004, 19:11
- Location: Italy
- Contact:
how about zelda-style attacking, like swing sword left/right/up/down (whereever you're facing), and hurt any monsters on the neighbouring tile
trying a dozen times to click to where you think the monster's hitzone is isn't fun, also i tend to prefer keyboard controls
also, it would be nice to be able to read those roadsigns that are standing around (not that you could actually get lost in the current 3-map-overworld
)
trying a dozen times to click to where you think the monster's hitzone is isn't fun, also i tend to prefer keyboard controls
also, it would be nice to be able to read those roadsigns that are standing around (not that you could actually get lost in the current 3-map-overworld
)-
ElvenProgrammer
- Founder
- Posts: 2526
- Joined: 13 Apr 2004, 19:11
- Location: Italy
- Contact:
I think we could probably increase the range of mouse aiming to 3x3 tiles so you have higher chance to target it or at least check both current destination tile and previous tile of their path.
And as you said, well the Zelda/SoM approach could be better at least when using keyboard, even though I think in SoM they used something like a pixel per pixel collision with the weapon sprite. We could probably think on something similar when we get new playerset and equipments done.
The signs? Oh we could make them as npcs, someone could like them this way.
And as you said, well the Zelda/SoM approach could be better at least when using keyboard, even though I think in SoM they used something like a pixel per pixel collision with the weapon sprite. We could probably think on something similar when we get new playerset and equipments done.
The signs? Oh we could make them as npcs, someone could like them this way.
i dunno how your engine works internally, if it's fixed to 32x32 nevermind, if it's more exact you could take the last tile, the destination tile and and make 1/4 of each of the neighboring tiles part of the hitbox, like so:
(red tiles being monster location/destination, yellow parts of nb. tiles being aprt of the hitbox
btw, i dont think som used per-pixel collision, it just checked a certain range next to the player for enemies. after all we're talking 16-bit snes here.
(red tiles being monster location/destination, yellow parts of nb. tiles being aprt of the hitbox
btw, i dont think som used per-pixel collision, it just checked a certain range next to the player for enemies. after all we're talking 16-bit snes here.
-
ElvenProgrammer
- Founder
- Posts: 2526
- Joined: 13 Apr 2004, 19:11
- Location: Italy
- Contact:
underestimate the best console as of yet, moi? no way! but, even though the snes *could* to that, it'd be a terrible waste of cpu cycles, which were precious back then.
(also, i just tried it, and i managed to hit a rabite w/ 2 pixels free space. of course that doesn't mean it wouldn't be a nice feature for tmw though.)
(also, i just tried it, and i managed to hit a rabite w/ 2 pixels free space. of course that doesn't mean it wouldn't be a nice feature for tmw though.)
-
bahamutian
- Peon
- Posts: 8
- Joined: 07 Jan 2006, 01:20
- Location: PA, USA
- Contact:
Phew, a lot of topics here.
Signs: Have a list of sign ID's stored on the computer, When you mouseover the sign, it gets the sign's ID and if there is an associated description stored on the computer, then the client prints the text to the screen at that location (useful for simple signs, not very big ones though). If no description is available, then pass the ID to the server and request the description. Save description of the sign on the computer to Signs.txt, even if it is just "information not available." This prevents it from requesting the information each time.
Pixel per pixel collision, it is a good idea, but shouldnt be implemented for magic or hand based weapons. It would work for arrows though. With the current auto-attack feature of the Ctrl + shift, there would be either no possibility of missing or you would still have to move the mouse overtop of the monster and if you were lagging, then that monster may not be there. It would also require a lot of checks to determine if there was a collision with the pixel of the weapon art. I could probably write a function to take a png/bmp image and translate that into a series of locations to check on it, so that the number of checks is minimized. Remember, each check must be performed on the server, otherwise it promotes hacking on the client version. The basic concept of the multiple single point checks is similar to how i play battleships.
x---x---x---x
-x---x---x---
--x---x---x--
This comes from the odds that it can be split up into smaller sections where each are effective without losing ability to find the object.
The code would have to analyze the smallest monster(s) and compare them to the weapon, to find places on the sword that would find the monster with the same ability as checking every single piece of the outline and a few interior points (in case the monster is smaller then the weapon and can fit inside of it.
I have not explored how the movement by mouse has been working, but it should be possible to click behind a building.
My idea on chooseing spells/skills to use. It is similar to secret of mana and secret of evermore's system. Basically, you would use a ring of user specifiable icons for the spells/skills. This would give up to 10 possibilities per ring. It could work like a toggle, where you press m for magic, s for skill, i for invetory or v for varied combination. This would give the user to be able to setup 40 different spell/skill/magic quickkeys. An example on how to use it could also be to allow each to have anything on it, enabling the user to choose one for offense, defense, general, and skill training.
It would require the logic to set each of these. A way to do this is to select the a skill, item, or magic. Toggle that menu screen up and then hold Alt + key# to set it.
It could also just be a line of icons at a certain location on the screen, for example right above where the chat is, or if that is hidden, then along the bottom of the screen. It could even work like any other screen that is toggleable with the F# keys. Maybe it would have multiple ways to show it, for example, 1 x 10, 10 x 1, 2 x 5, or 5 x 2.
Signs: Have a list of sign ID's stored on the computer, When you mouseover the sign, it gets the sign's ID and if there is an associated description stored on the computer, then the client prints the text to the screen at that location (useful for simple signs, not very big ones though). If no description is available, then pass the ID to the server and request the description. Save description of the sign on the computer to Signs.txt, even if it is just "information not available." This prevents it from requesting the information each time.
Pixel per pixel collision, it is a good idea, but shouldnt be implemented for magic or hand based weapons. It would work for arrows though. With the current auto-attack feature of the Ctrl + shift, there would be either no possibility of missing or you would still have to move the mouse overtop of the monster and if you were lagging, then that monster may not be there. It would also require a lot of checks to determine if there was a collision with the pixel of the weapon art. I could probably write a function to take a png/bmp image and translate that into a series of locations to check on it, so that the number of checks is minimized. Remember, each check must be performed on the server, otherwise it promotes hacking on the client version. The basic concept of the multiple single point checks is similar to how i play battleships.
x---x---x---x
-x---x---x---
--x---x---x--
This comes from the odds that it can be split up into smaller sections where each are effective without losing ability to find the object.
The code would have to analyze the smallest monster(s) and compare them to the weapon, to find places on the sword that would find the monster with the same ability as checking every single piece of the outline and a few interior points (in case the monster is smaller then the weapon and can fit inside of it.
I have not explored how the movement by mouse has been working, but it should be possible to click behind a building.
My idea on chooseing spells/skills to use. It is similar to secret of mana and secret of evermore's system. Basically, you would use a ring of user specifiable icons for the spells/skills. This would give up to 10 possibilities per ring. It could work like a toggle, where you press m for magic, s for skill, i for invetory or v for varied combination. This would give the user to be able to setup 40 different spell/skill/magic quickkeys. An example on how to use it could also be to allow each to have anything on it, enabling the user to choose one for offense, defense, general, and skill training.
It would require the logic to set each of these. A way to do this is to select the a skill, item, or magic. Toggle that menu screen up and then hold Alt + key# to set it.
It could also just be a line of icons at a certain location on the screen, for example right above where the chat is, or if that is hidden, then along the bottom of the screen. It could even work like any other screen that is toggleable with the F# keys. Maybe it would have multiple ways to show it, for example, 1 x 10, 10 x 1, 2 x 5, or 5 x 2.
And what if the content of the message changes? If i understood correctly, the old stored message will appear...Signs: Have a list of sign ID's stored on the computer, When you mouseover the sign, it gets the sign's ID and if there is an associated description stored on the computer, then the client prints the text to the screen at that location (useful for simple signs, not very big ones though). If no description is available, then pass the ID to the server and request the description. Save description of the sign on the computer to Signs.txt, even if it is just "information not available." This prevents it from requesting the information each time.
-
bahamutian
- Peon
- Posts: 8
- Joined: 07 Jan 2006, 01:20
- Location: PA, USA
- Contact:
Well, it work work mainly as a saved file. It could be patched in at the beginning of the connection session. Maybe the game will hast the saved file on the computer and if it is different, then it will download the updated version.
There would of course have to be a way for the descriptions to be updated. Having a single file that has to be re-downloaded each time that there is a change seems like a lot of data transfer if the file gets to be big.
A slightly better workaround would probably be to have the client request a hashed value of the sign's text to be returned. If this is different then the client's hashed value for the sign's text, then the client requests the full text of the sign. This test would be stored client side, so that the request is only done the first time that the sign ID has occured.
This would require the client to be restarted for any updated sign texts to be transfered. The server could send out a signal that is has an updated sign text to all logged in characters, which also includes the sign text, thus updated the values stored on the computer. The client then saves the text file and magically its all there for the next time =).
There would of course have to be a way for the descriptions to be updated. Having a single file that has to be re-downloaded each time that there is a change seems like a lot of data transfer if the file gets to be big.
A slightly better workaround would probably be to have the client request a hashed value of the sign's text to be returned. If this is different then the client's hashed value for the sign's text, then the client requests the full text of the sign. This test would be stored client side, so that the request is only done the first time that the sign ID has occured.
This would require the client to be restarted for any updated sign texts to be transfered. The server could send out a signal that is has an updated sign text to all logged in characters, which also includes the sign text, thus updated the values stored on the computer. The client then saves the text file and magically its all there for the next time =).