Alpha975

This is an awesome idea, indeed Looking very much forward to it! This might be just the thing we need!

Thank you very much Yeah, I'm pretty sure one will not get all details right on the first try, so an iterative process with testing and refinement should be employed, until the players like it Oh yea, that is a great idea: just determine rigging based on the distance the ships have to travel. For for voting that would be option D Hm, yea garrisioning siege engines. Here we have the problem that if we allow the player to garrision artillery and it attacking enemy ships, somebody will just take the biggest ship and load it up with ballistas, while the ship itself only has deckspace for, let's say, 2 large artillery pieces. This would also make the player evade the dilemma of choosing between archery towers, boarding equipment or artillery on the ships. Perhaps a way out would be, to indeed allow garrison of artillery, but make it block the slot for the other equiment that could be placed in it. The advantages would be that the only thing modelling wise for this would be to place an empty for the place of the artillery, automatic inclusion of all updates to artillery-pieces (including all balancing) and the historical possibility to unload the artillery. Actually, I like that idea Oh yeah: color-schemes Some of the ships of antiquity were painted really beautifully. I was planing to have the player-colors as the colors of the stripes on the side of the ships. Historically, white was a very popular color for ships and in the roman navy, red and blue were the traditional colors. So I guess ships will become pretty colorful Also, traditionally, a tiny update: Additional attachment points for ropes for rigging and equiment in the front of the roman 5: Tiny details improved at the back of the ship (bronze holder for flag-signal-post and wooden beam for holding the landing-ramps in place): Also, medium quality roman anchor for later baking (looks like at the time wooden anchors with lead weights were the standard for the roman navy):

Also, traditionally, a tiny update: New details for the prow of the roman 5.

Hm, that's a good question. In my opinion, in any case we have to consider the case where players want to play an island map. In this case it is possible that almost all engagements happen at sea. If we still want the game for the players to be fun, we would have to make the naval battles at least as fun and engaging as land battles. So the level of player management and involvement for both should be at the sweetspot (not sure we are at it with the land battles yet ). It should never feel like a hassle, and never make you bored. Generally, we also will always end up with less ships than we would with land units. By that standard we could consider that while land battles might have something like hundreds of units involved, naval battles might only have dozens (as did the largest amount of historical encounters). And additionally, we could introduce more options for micromanagement for naval units. But these options should always remain fun for both players: that is, the player using them and the player having these options used upon himself. I could imagine naval combat as such: Ships can ram, board or perform ranged combat. For boarding you could garrison melee and ranged units on a ship and internally, the ranged and melee soldiers would attack other melee units randomly, and if none are left, ranged units (or something like that). Once the garrison of the ship is gone, it is slowly damaged, set on fire and sinks (could possibly be made to look cool ... yes yes, I know, I' would have to do the animations ...). To initiate boarding, you would simply have to be in range, activate boarding mode, and if you are lucky and roll higher than the defense of the ship being attacked, I could animate hooks being thrown and boarding ramps being employed ... whatever looks cool and historical If you build a ship, it would come without a garrison, and a symbol next to the healthbar would indicate this. The advantage is what a player with an experienced land force could use these experienced soldiers at sea (like the romans ). And landing forces would always have the historical dilemma of possibly leaving the fleet behind unprotected ... The counter for the boarded party could be to "pin" enemy ships by sacrificing ships for boarding and sinking the enemy ships, while their ships are in melee (real, historical tactic ). We would also have the advantage that changes and updates to the land combat would automatically be in naval combat aswell and balanced land forces would automatically go a great length towards balancing naval boarding aswell. Ramming could be made straightforward. And for ranged attacks you would simply have the combined ranged attack of the ship's garrison as one attack, and the attack of the ship's artillery as another one. If it were up to me, I would also allow ships to be specialized. That is: when they are built, they come out plain. If you are in range of a port you could have several slots on your ships, that could be filled with specializations. For instance for a roman 5: 1 slot for the oars: either semi-cataphract (extra speed) or cataphract (extra protection) 1 slot for the belly: either nothing, copper-coating (after it is researched for extra health, but slightly lower speed) of lead-coating (after it is researched for a different amount of extra health, but slightly lower speed) 1 slot for the front of the ship: either nothing, an archery tower (ranged attacks, slightly slower speed), a corvus (after research for extra boarding chance but reduced maneuverability and speed), siege artillery (you guessed it ... research + siege attacks + reduced maneuverability and speed), light artillery (yeah: research + range attacks + slightly reduced maneuverability and speed) or fire pots (extra ram damage after research) or whatever we think of I would also allow ships to only unload troops once they are beached (I could provide animations). There they would have greatly reduced defenses. This would also give an attacked party a longer time to react to a landing and even more awesomely: allow a faction without any navy to destroy the navy of a landing force with melee units if they overwhelm the defending forces (and create some cool looking, burned ships on your beaches ). An interesting possibility that I thought about: ships would actually come in two parts (left and right) both with their own health. They could be damaged individually. The player would only see the one health bar per ship (geometric mean of the two semi-parts ... that is: sqrt(health1*health2) ). The advantage: you could concentrate your damage (ramming) on one, damaged, ship side that you can identify by the damage model. If one side has 0 health, the health bar will also be at 0. Also: if both sides are at 100%, the health bar will be at 100% (isn't math nice ) This would be a nice option that would never bother new players, but experienced players could try to really micromanage their attacks ... could be a lot of fun And in that case again: me -> anmations and damages ships textures I was also thinking about the dilemma of ships with all of their rigging. In combat ships typically did not have their rigging out (there are historical accounts of sea battles where unprepared fleets with sails out were caught and at a great disadvantage in combat). As I see it, there could be three possibilites: A: ships always have their sails out B: ships are always combat ready C: players can switch between the two states with a button press and both have their advantages and disadvantages (in that case I would even go so far as to provide some animations for this ) Ok, that was a massive post. Sorry for that What do you think about all that? And perhaps let us poll the last option. Who would like to see A, B or C?

Thank you all very much Good question. I haven't specifically searched for this in the literature, but here is what was in some of the literature I looked through to gain insight into ship-building much later: The first mentions of naval battles were around 3500-3050 BC [2]. If I remember correctly, minoean ships looked pretty much the same, independently of their purpose around 1650-1500 BC [2]. The first ships that could be identified as the predecessors of the later monoremes were developed around 1200 BC in mycenaean greece [1,3] and around the same time there were also depictions of the warships built in egypt and by the sea people together with distinct mentions of both trading and combat ships [2]. The first purpose built variants designed specifically for war might be estimated to be conceived around that time [1,2] though even earlier depictions of ships (1567-1320 BC) show the front and aft platforms of later warships [2]. As far as I know, the earliest direct mention of a ship-attached ram was around the middle of the 8th century BC [1], though it is estimated that it was developed between 1000 and 850 BC [1] or possibly even earlier as a reinvention of bronze age designs [3]. This is roughly also the point where from then on, civil and military naval architecture were no longer similar since a ram requires a strongly reinforced prow and hull [1]. The solution at the time was to make the ships shorter, more robust and equipped with more oars. Increasing the length of ships was not a great option at the time [1]. You can see the two possibilities with the development of the improved penteconter and the bireme. Around that time (second half of the 8th century BC) in the Odyssey there was a distinction between broad freighters with 20 oars and the 50 oared ship that can be seen as a specialization of the previously used ship type(s) [3]. Thucydides implies this "early" pentekonter was used for many tasks, including "convoyance of ambassadors, supression of piracy and, exceptionally, warfare" [3]. Biremes were in use at least since 700 BC [1,2,3] and the penteconter was mentioned (together with other warship types) in Homer's Iliad [2]. The penteconter seems to have been improved into a pure warship by at least the 6th century BC [1,2]. However, the evolution was even more gradual and harder to pin down than these numbers might indicate. The evolution of ships was very slowly with many intermediate steps so that even living at the time would still make it hard to tell in which century and in which region the transition happend, in particular as there are many examples where old designs and technologies were used alongside new ones until the new ones proved more reliable [3]. The issue becomes even more confusing as even at later times warships were often also used as transports and transports as warships [3]. Additionally the sources in the time of interest are very sparse and there is even debate to which extend the knowledge about ship-building from the late bronze age carried over to the early iron age [3]. And even the sources that are available are debated a lot [3]. [1] wikipedia and sources therein. [2] Warships of the Ancient world: 3000-500BC by Adrian K. Wood and sources therein. [3] The age of the galley by Robert Gardiner and sources therein. I hope this small paragraph helps a little

Ok, another tiny progress report. Finally, I finished unwrapping the main part of the high poly model. Here is how the model looks like (including a few very tiny changes): Now onto getting a nice version for the game engine So, first part of the low poly model are the rows. Here is a comparison between the high quality model (back, 148 faces, 296 tris), the early, placeholder low poly version (middle, 18 faces, 26 tris) and the new low poly version (front, 12 faces, 20 tris): And after some baking, the new one starts to look passable for its poly-count :

Hm, yes. Would be great if somebody would help with coding. Some more UV unwrapping and detail-work on the high poly model:

Thank you very much Yes, if the coding supported this, we could even give the player a toggle button, where he/she could raise or lower sails depending on whether extra speed or extra ship defense was needed. That, together with possibly ramming, boarding and equipping ships with artillery, could give naval combat quite a nice shunk of tactical options ... one could even go so far as to create and record (possibly youtube?) a combat tournament so one could see which of these options are actually useful to the players. If it were up to me, I would even go so far as to support partial damage to objects. That is: the left and right sides of the ships had their own damage models and could be destoyed seperately ... that way it looks ok, if a ship is rammed on one side. But I'll think about animations and damage once the low poly model is finished ...

You're welcome. Nope, the wooden texture is by fabooguy: http://fabooguy.deviantart.com/art/Bright-Wooden-Floor-Texture-Tileable-2048x2048-421883267?q=gallery%3AFabooGuy%2F50943294&qo=0 It's free to use for whatever (and saves me the hours in efforts trying to create high quality ab initio textures). Hm, yes, might still take a while Yes, I was thinking about the rigging. I was wondering if we even want sails. In combat ships removed sails, ropes etc. from the deck (basicly anything another ship could grab onto with a hook) to avoid being forced into a meele on unfavourable terms. There might also be the option of having both versions and animations transitioning between them. So what is the community opinion on this topic? Both versions? Just sails? Or just combat ready? I also still have to decide on the coating below the water line ... I could perhaps create a few versions (somewhere in the forum someone complained that it unfortunate that updates are invisible on units ... here simply the texture could change).

Alright, as promised: some baking. 1. Take the high poly model you want to bake down. For this example, it will be the main part of the roman 5: 2. Model a very low poly model around the part you want to bake. Here is only has about 32 faces (64 polys). Some hints with this step: try to leave out small crevices and the like, approximate high poly, but almost even surfaces with single polys. The prime goal is to produce a model that looks fairly close in siluette from almost every angle to the high poly model and sticks somewhat close to its surface (to ensure a good bake). For game engines: I know it is tempting, but try to avoid very long and narrow polys. This is because some lightning techniques might create artifacts with these and culling (thowing away polys during rendering that might not be visible) might fail with these vertices (they may either be culled too early, creating holes in the mesh, or not at all, decreasing performance). For our example, the mesh could look like this: 3. UV unwrap the low poly mesh. Create a texture you want to bake to (here we bake over a texture I previously used for baking ): As a rule of thumb for the resolution of the texture: make it a lot larger that the target resolution. Baking in blender works by a form of ray tracing. So it is noisy. In particular if the high poly mesh has sharp corners or grids. It is always easy to downscale a baked texture to a less noisy one in a picture editor, but hard to manually remove all the noise by hand (especially in case of normal maps) ... 4. Select both objects, the high poly and low poly mesh, select the type of baking to be performed and bake ahead: If you selected them in the wrong order, you might encounter an error message. A difficulty at this point might be to properly estimate the "distance" and "bias" settings. A nice rule of thumb: higher distance means that faces further from the surface are included in creating the texture. You want this setting so large, that every detail you want in your texture is on there (bake and check the result) but not so high that parts from the model that don't belong there get baked onto your textures. Bias mainly concerns how far away faces are treated. Try different values, until the textures look good. 5. After baking a normal map, ambient occlusion, specular color map and texture map, save each of them (be careful to save each of them right after baking to not accidently bake over them ). Here we then apply the textures to the low poly model for quality checks (multiply the ambient occlusion map to the texture map): At this point some 2D editing on the textures could be performed. I hope that helps

Sure, will do Sorry, I was rather busy the last few months, but more free time is ahead

So, as promised: a few screenshots with notes. Here I remodeled the ventilation meshwork at the side of the roman 5. Step one, the model with the old one removed. Step two, model only two wooden beams, uv-map them, use mirror-modifier (for right-left symmetry). Step three, use the array modifier to have as many of them at hand as one wishes. Step four, use the curve modifier, together with a curve (nurbs in this case), to have the mesh fit the opening. Also change the array modifier from fixed count to fit curve length. Step five, apply modifiers and manually adjust vertices when needed (use proportional editing to save time). Step six, example bake of this high quality 3D model to an incomplete low poly mesh with only 12 polys for demonstration. As you can see, simple baking already produces pretty good results, however in this case some texture editing would be required to really have convincing textures.

Sure, will post a few annoted screenshots next weekend. I'm pretty sure I can still learn a whole lot and there are plenty of things you can teach me

Well, several tricks can be employed. For instance all meshworks will be baked so they don't need polys. They currently make up most of the excess polygons. Additionally, I already made the model very low poly where ever I could. The oars and shields are already rather low poly (oars are 18 faces per oar, makes 3k in total ... but will be made even lower poly ... ingame they are currently 4 polys per oar but that is slightly too little in my personal opinion). Because I'm lazy, everything is currently also modelled with symmetry modifiers, arrays, curves etc. And of course nearly all small crevices will just be baked into the normal map instead of them being 3D. A large amount of polys are also locked in the railings, but without using advanced stuff like sub-model LOD, transparency and parallax-mapping there is not much to save there. One also always have to be careful with the shape of the resulting polygons. Very long and narrow polygons work just fine when rendering, but cause a lot of visual artifacts in most game engines ... In contrast to the other points, baking stairs down might not save nearly as many poly as reducing the number of polys per oar by one ... but we'll see. From experience it's always a game of cheating: how much poly-reduction can I get away with so the user does still believe the model to be completely 3D. We might end up with a let's say a 3k mesh, and 3x1M textures (diffusion, specular, normal ... though specular might be reduced further to 0.25M), making it look nearly from every angle like a 28k mesh with 2 0.5M textures and real time AO (like the screenshots) ... whereas the first one runs fine in realtime, the second one is just about out of reach (some rts-engines actually could handle it ... but we are talking about C/C++ written engines with lots of pointer arithmetics and advanced lightning and shader techniques with thousands of man-hours of tuning). I'm currently also thinking about creating some floating debris for the sunken ships and a few wrecks (you know, something nice to look at when you destroyed a ship that has beached ...). Animations are another important point. One can get away with quite crappy models if they are very well animated, whereas the other way around will usually transport the user right into the uncanny valley. So I'll use quite a lot more bones than the current models. The computational burden is usually not that huge on the users computer for even many animations, as long as the number of poly that are affected is somewhat small. From what I've seen in other strategy games, we might want to enable the regular user to run naval battles with about a dozen or so ships per side just fine graphics wise. So there is where I'm aiming at ... If it is of interest, I could make a few making of screenshots with explanatory text or something.

Currently around 24k vertices and 15.4k polys equating to around 28.8k triangles. After baking and low poly model that would be around 1-3k polys.