unfies
User
Captain
| Posts: 13 |   |
|
Re:UWNH remake in C/C++ - 2008/10/12 18:06
First some technical bits.
The following is based heavily on the SNES version. From my understanding, you play the PC version. There are going to be some obvious differences, but the conclusions are the same.
Using an emulator, you can undoubtedly discover what resolution the current graphics mode is, and from there work on deciphering some tile information. Cutting to the chase, from my understanding, backgrounds are made up of tiles ranging from 32x32 to 128x128 pixels. Sprites appear to be 8x8, 32x32, and 64x64.
Depending on video mode, screen width would be either 256 or 512 pixels wide. At 256, an 8x8 would give ya 64 ships visible across the screen (nope), and 32 would give you 8 (seems like not enough). The 512 wide screen is used less frequently due to speed concerns. If a ship is fully 32x32, then that would give ya 16 ships, which seems reasonable.
a 32x32 ship, and 32x32 background tiles appear to be making sense.
Assuming 16 ships across the screen at 32x32, you can use that for figuring out your tile sizes for laying out the world map. If you're not doing a graphical rip of the game, just keeping things in proportion would be key. Taking lots of screenshots here and there so you can do some measuring wouldn't be a bad idea  .
You should also note that alot of times, games on tile based systems don't follow the rules of 'sprite must fit within one tile' -- for example, I believe Samus in Metroid can be up to 4 or 5 tiles in size.... fire it up in an emulator and check out the tile set sometime... .
So. Proportion is what you want. And if you stick to whole tile movement, keep in mind that your game will act similar to the original UW's ship movement style.
Oh, and, the key to tile based animation isn't that the background is thing not allowed to move, but that it's made up of redundant graphics. You should still be able to scroll around a tiled world, its just your screen construction stuff builds off the smaller subset of tiles (saving memory). So, the tiles may be 128x128, but the world might be 128 of these tiles across and 64 of these tiles tall.
If you want to be exacting, I'd suggest starting at the southern tip of South America and take a screenshot for each 'screen width' you progress along the south pole. From there, chop up the images or p*** them together, etc, until you have a complete cir***frence of the south pole. That'll give you the UW2NH game width in pixels. How you determine it's height is up to you (a screen shots of the world map to get a complete image and then finding the ratio between w/h -- or perhaps picking something like sailing up the west coast of south america to the north pole, taking screen shots similarly to the south pole run...).
----
Mechanics and data types -- euh... they're all individual things. Treat them as such. Yes, you'll eventually get to where one can affect the other (cargo usage, food supply <> crew health, character data <> crew health, etc etc etc)... but.. I'd seriously work on keeping it all separate and working within their own little world before you attempt to cross mingle them. If you're doing this in a OO language, this should be easy to conceptualize. Tie-ins to the other areas of game mechanics can come at a later date with function/member calls or similar.
Keep things isolated to begin with for sanity.
----
Real time is subjective.
Depending on your target platform (web/html, web/flash, exe/tcp, exe/udp), and desired worst case latency.. you'll have to figure out what mechanic you wanna use. It's quite common for cross-world players to have latencies of 350ms back and forth, while people on the same ISP might have only a 25ms latency.
Also, I'm not entirely sure about how time passes while sailing in game. There have been instances where I'd swear that time passes in relation to your sailing speed.... in such a way that in slow spots, a day in game can pass in just a couple seconds, but on a speedy sailing speed a day can appear to last upwards to 10 or something. This is impossible during a real time networked game .
Lets say you assume you'll do 4 'ticks' per second, and each tick represents 30 minutes of game time. Every second, 2 hours of game time passes. One day will pass in 12 seconds. A Mederia -> Lubeck run taking ~10 days would mean 2 minutes of real time. I'm unsure if this is correct or not... but it's an example. I'd also avoid using something like '3 ticks per second', because then you run into fractional decimal math .
Next up - battle sequences in relation to 'real time'. Depending on how much control a player has over their fleet... this is going to suck hard. Attempting to coordinate 10 ships every tick is... impossible ? . No matter what the battle mechanic you use, any opening decisions (fight/flee/etc) is gonna suck because for every second the player debates their choices, they lose X number of game time ticks... and if one player stalls making a decision, they're possibly forcing the other player to lock up waiting for a pre-battle-response.
Battle decisions may have to be made while sailing or while leaving port. This way, during sailing, a collision can trip a completely computer controlled battle outcome generator. You lose combat-field related strategy of the game this way  .. but in an ever present and ever time-moving world... you may not have much choice.
----
Town travel and trading in real time. If you heavily debate a trading decision or similar in the game, you're losing valuable game time. In UW, you can spend an indefinite amount of real world time deciding things while zero game time has passed. In a live time game, you have some very quick decision making to do. Lets say, 4AM to 8PM trading time at the market. Using the previous 4 ticks/sec at 30 min each, you end up with 16 hours of game time and 8 seconds of real time in order to make your trade. Insanity ?
If you drop it to each tick representing only 5 minutes of game time, one real second is 20min of game time, and one game day lasts 72 seconds in real time. 16 hours of time that the merchant is available for trading correlates into 48 seconds. Slightly more reasonable, but how often do you spend less than a minute at port in UW ? And that 10 day trip from Mederia to Lubeck now takes 12 minutes. I dunno how 'correct' this is to keeping pace with the original game. Lastly, a 20 day trip from Lisbon to the New World would take about two and a half minutes.
The more you make each game tick mean less game time, the more sluggish regular sea faring will become.
----
Figuring out time is going to be your enemy ... especially if you try to keep everything 'real time' and UW style limitation on what you can do depending on time of day. Similarly, any difficult decisions or manual-mental-research-work done by the player can correlate into days lost in game.
Next up - lets say Matey fees. At About 4 minutes per game month at 4t/5min formula, one real world day would see roughly a year pass in game time (360 days). During which time, you're paying, say, 100-600 a month in salaries. At 600 a month, that's 7200 gold lost per real world day.
In short, time will be fun Long enough post heh.
|
|
|
The administrator has disabled public write access. |
twm
User
Knight
| Posts: 34 | |
|
Re:UWNH remake in C/C++ - 2008/10/13 02:13
unfies wrote:
First some technical bits.
The following is based heavily on the SNES version. From my understanding, you play the PC version. There are going to be some obvious differences, but the conclusions are the same.
Using an emulator, you can undoubtedly discover what resolution the current graphics mode is, and from there work on deciphering some tile information. Cutting to the chase, from my understanding, backgrounds are made up of tiles ranging from 32x32 to 128x128 pixels. Sprites appear to be 8x8, 32x32, and 64x64.
Depending on video mode, screen width would be either 256 or 512 pixels wide. At 256, an 8x8 would give ya 64 ships visible across the screen (nope), and 32 would give you 8 (seems like not enough). The 512 wide screen is used less frequently due to speed concerns. If a ship is fully 32x32, then that would give ya 16 ships, which seems reasonable.
a 32x32 ship, and 32x32 background tiles appear to be making sense.
Assuming 16 ships across the screen at 32x32, you can use that for figuring out your tile sizes for laying out the world map. If you're not doing a graphical rip of the game, just keeping things in proportion would be key. Taking lots of screenshots here and there so you can do some measuring wouldn't be a bad idea .
You should also note that alot of times, games on tile based systems don't follow the rules of 'sprite must fit within one tile' -- for example, I believe Samus in Metroid can be up to 4 or 5 tiles in size.... fire it up in an emulator and check out the tile set sometime... .
--------------------------->
I am using 32x32 tiles, resolution is scalable but it just draws more tiles with higher resolution, so a line of sight needs to be added to avoid high-res cheats..
Speed shouldnt be a concern, I am using 3D acceleration to draw 2D stuff, it'd be lightning fast as long as your graphics card supports 3D acceleration, actually most modern cards/integrated cards do.
Sprites bigger than one tile can be problematic when you need realtime collision, it's hard to test the sprite's collision box when the box's visual coverage is much bigger than a tile.
Here is how the game looks in 800x600 window, this is a ship(green arrow) got stuck near the English Channel on a 2048x2048 worldmap.Tiles are in 32x32.
So. Proportion is what you want. And if you stick to whole tile movement, keep in mind that your game will act similar to the original UW's ship movement style.
Oh, and, the key to tile based animation isn't that the background is thing not allowed to move, but that it's made up of redundant graphics. You should still be able to scroll around a tiled world, its just your screen construction stuff builds off the smaller subset of tiles (saving memory). So, the tiles may be 128x128, but the world might be 128 of these tiles across and 64 of these tiles tall.
If you want to be exacting, I'd suggest starting at the southern tip of South America and take a screenshot for each 'screen width' you progress along the south pole. From there, chop up the images or p*** them together, etc, until you have a complete cir***frence of the south pole. That'll give you the UW2NH game width in pixels. How you determine it's height is up to you (a screen shots of the world map to get a complete image and then finding the ratio between w/h -- or perhaps picking something like sailing up the west coast of south america to the north pole, taking screen shots similarly to the south pole run...).
------------------------->
Movement is per pixel or per world space, so is the scrolling around map, the camera is much more like 3D game's with a coordinates x, y, map scrolling is based on the camera position and the camera is locked to an object:either a ship or a city/port, so moving the ship will trigger scrolling(like in UWNH).
The map sizes I am evaluating are 1024x1024, 2048x2048 and 4096x4096, each tile has about 7 bytes of information atm, and I store the whole map in memory after loading from binary .map file, so the overhead of memory is significant at bigger tile amount.
So far 2048x2048 seems to a blend of memory usage and size, the generated world map looks decent and it takes only 1/4 memory compare to 4096x4096 maps...
UWNH's world size is probably smaller than 1024x1024, since it doesn't resolve combat on worldmap, rather it does it on tactical map when 2 ships collide.
----
Mechanics and data types -- euh... they're all individual things. Treat them as such. Yes, you'll eventually get to where one can affect the other (cargo usage, food supply <> crew health, character data <> crew health, etc etc etc)... but.. I'd seriously work on keeping it all separate and working within their own little world before you attempt to cross mingle them. If you're doing this in a OO language, this should be easy to conceptualize. Tie-ins to the other areas of game mechanics can come at a later date with function/member calls or similar.
Keep things isolated to begin with for sanity.
-------------------------->
Most data types are done, all data is stored in script files in plain text form, they will be loaded into read-only class/struct in memory upon game start.
Cross-reference between data types are inevitable, especially a ship's properties such as cargo, crew, weapon, seems they share the same 'storage space' in UWNH.
----
Real time is subjective.
Depending on your target platform (web/html, web/flash, exe/tcp, exe/udp), and desired worst case latency.. you'll have to figure out what mechanic you wanna use. It's quite common for cross-world players to have latencies of 350ms back and forth, while people on the same ISP might have only a 25ms latency.
Also, I'm not entirely sure about how time passes while sailing in game. There have been instances where I'd swear that time passes in relation to your sailing speed.... in such a way that in slow spots, a day in game can pass in just a couple seconds, but on a speedy sailing speed a day can appear to last upwards to 10 or something. This is impossible during a real time networked game .
Lets say you assume you'll do 4 'ticks' per second, and each tick represents 30 minutes of game time. Every second, 2 hours of game time passes. One day will pass in 12 seconds. A Mederia -> Lubeck run taking ~10 days would mean 2 minutes of real time. I'm unsure if this is correct or not... but it's an example. I'd also avoid using something like '3 ticks per second', because then you run into fractional decimal math .
Next up - battle sequences in relation to 'real time'. Depending on how much control a player has over their fleet... this is going to suck hard. Attempting to coordinate 10 ships every tick is... impossible ? . No matter what the battle mechanic you use, any opening decisions (fight/flee/etc) is gonna suck because for every second the player debates their choices, they lose X number of game time ticks... and if one player stalls making a decision, they're possibly forcing the other player to lock up waiting for a pre-battle-response.
Battle decisions may have to be made while sailing or while leaving port. This way, during sailing, a collision can trip a completely computer controlled battle outcome generator. You lose combat-field related strategy of the game this way .. but in an ever present and ever time-moving world... you may not have much choice.
----------------------->
The target platform is any platform supported by SDL, the network model I am think of is probably TCP and a client<->server approach, TCP guarantees packet arrival in order reliably, and client<->server minimizes the possibility of desynchronization during a network session, though the downside is increased delay in executing orders for non-server players and increased network traffic caused by sending/receiving requests.
All battles have to be resolved in real time on world tile map, you give orders on a fleet basis rather than on a ship basis, which means you give your fleet attack, move, attack order and the non-flag ships in your active fleet(the one you are controlling to sail around) will move and attack automatically, thus reducing the micro needed to play real time battle.
The time will be tricky to do, every few second in real life as a day in game sounds about right.Though additional heeds must be paid to implementing time properly.
----
Town travel and trading in real time. If you heavily debate a trading decision or similar in the game, you're losing valuable game time. In UW, you can spend an indefinite amount of real world time deciding things while zero game time has passed. In a live time game, you have some very quick decision making to do. Lets say, 4AM to 8PM trading time at the market. Using the previous 4 ticks/sec at 30 min each, you end up with 16 hours of game time and 8 seconds of real time in order to make your trade. Insanity ?
If you drop it to each tick representing only 5 minutes of game time, one real second is 20min of game time, and one game day lasts 72 seconds in real time. 16 hours of time that the merchant is available for trading correlates into 48 seconds. Slightly more reasonable, but how often do you spend less than a minute at port in UW ? And that 10 day trip from Mederia to Lubeck now takes 12 minutes. I dunno how 'correct' this is to keeping pace with the original game. Lastly, a 20 day trip from Lisbon to the New World would take about two and a half minutes.
The more you make each game tick mean less game time, the more sluggish regular sea faring will become.
----
Figuring out time is going to be your enemy ... especially if you try to keep everything 'real time' and UW style limitation on what you can do depending on time of day. Similarly, any difficult decisions or manual-mental-research-work done by the player can correlate into days lost in game.
Next up - lets say Matey fees. At About 4 minutes per game month at 4t/5min formula, one real world day would see roughly a year pass in game time (360 days). During which time, you're paying, say, 100-600 a month in salaries. At 600 a month, that's 7200 gold lost per real world day.
In short, time will be fun Long enough post heh.
---------------------->
Prolly it will be a disadvantage for slow mofos  , but due to network nature, all things need to be resolved in real time.I will try to make a detailed explanation on how it will work later.
Anyways thanks for the insightful thoughts, feel free to post more long posts if you have other interesting ideas and thoughts.
Post edited by: twm, at: 2008/10/13 10:48
|
|
|
The administrator has disabled public write access. |
JDeAss
User
Mate
| Posts: 7 | |
|
Re:UWNH remake in C/C++ - 2008/11/04 07:51
well, all for good ideas, i am not on the coding side. but if u have played 'high sea traders', the idea of using sea charts may be of a nice one.
Post edited by: JDeAss, at: 2008/11/04 07:51
|
|
|
The administrator has disabled public write access. |
|
Discussion
