nerdboy64

Members
  • Content count

    34
  • Joined

  • Last visited

Community Reputation

718 Good

About nerdboy64

  • Rank
    Member

Personal Information

  • Interests
    |designer|programmer|
  1. Just a mini-update this time, nothing too major. The biggest change is that in simulation mode the test cube will act as an engine, pushing the boat forward. In addition to this, there are a bunch of small changes made to the editor: Machinery will appear in a translucent "preview" mode before being placed. Scroll wheel now rotates machinery. Machinery snaps to the horizontal grid by default, making it easier to line it up with the center of the ship. This can be toggled by pressing G. Machinery will only be highlighted when you're looking at it instead of all the time (eventually, you'll click to select machinery and be able to change options for them, for example the caliber and barrel length of a cannon). Right click deletes a surface or machine depending on which mode the editor is in. Also I got a new video editing program so now I can fast forward through building the exact same boat again.
  2. After a couple months of getting nothing done, I'm back on the Unreal wagon! This time I'm showing off the beginning of what will be the "machinery" system. Machinery is anything that actively performs a function such as weaponry, boilers, or radar. For now, though, it's just these cubes with an Unreal stock "tech panel" texture. I've also, er, changed the ocean shader somewhat. I'm not 100% happy with it, but it's already eaten more of my time than I'd like to admit, so I'm going to leave it as-is.
  3. In my last post I showed off an extremely early version of a project in which a simple boat could be constructed from triangular surfaces. Since then I've made a lot of progress in all aspects of the game. New features/improvements include: "Design" and "Simulation" modes split into separate levels Design mode now has a symmetry option, as well as the ability to view the vessel in wireframe to see the borders between surfaces Internal "compartments" are now handled properly; buoyancy calculations are disabled for sides of surfaces not on the exterior Designs can now be saved and loaded Main menu, almost like a real video game My plans for the immediate future are something like: More tools in the editor to speed up building Different materials to build with, each with different densities and other stats Ability to change "thickness" of surface (not rendered visually, but affects weight and eventually armor value)
  4. The exterior and interior triangles are not distinct but rather a single two-sided triangle with zero thickness. For a player not familiar with 3D modeling, it is conceptually easier to build with two-sided surfaces the way they might create paper models in real life. When a surface is damaged, it is flagged as "not watertight," but the mesh doesn't dynamically deform to create triangles that bridge between the interior and exterior. So at some point--whether in real time during construction or all at once when the design is loaded into the game world--the game needs to construct a one-directional mesh for each compartment from the two-sided surfaces the player will be working with. If we do it in real time, here's a potential situation that could happen: The mesh is the 1x1x2 square prism above, minus the internal partition. The exterior and the interior are two discrete half-edge meshes. The player places two new triangles to create that internal partition. The game now needs to update the references in those existing faces to connect to either side of the new triangle, forming two compartments from the one we had before. [attachment=34719:triangle madness 3.png] (I didn't draw every triangle in the picture to reduce clutter)
  5. After continued research it seems like a "standard" half-edge mesh won't quite be sufficient as it's still designed for meshes that only comprise an outer "skin" with no internal partitions. From Wikipedia: My game needs to allow internal partitions. The simplest example would be a square prism twice as long as it is wide, with an internal face dividing it into two cube-shaped compartments. One solution would be to add a pointer to the next half-edge around the edge, effectively making it an "nth edge" data structure. However, that creates a similar problem to my original one, as it would need to figure out which partial edge to split when adding a new face to an existing cluster.   Here's another picture to help explain what I'm after. The top left shows a very simple example of the system: a 1x1x2 unit prism with a partition in the middle splitting it into two cube-shaped compartments. The top left shows the game mechanic that arises from this: damage to one compartment allows water into side A, but the partition keeps side B dry. Finally, the bottom shows how a standard half-edge mesh only accounts for one-sided faces of a single-compartment mesh, but doesn't solve the problem of several faces radiating out from an edge. [attachment=34710:triangle madness 2.png]
  6. To be honest I wasn't [i]aware[/i] of the half-edge mesh data structure until you mentioned it. Currently my faces are just a big, dumb array of triangle structs, each with three vertices, because that translates easily into UE4's visual meshes. After doing some research, that seems like a good solution.
  7. It's not that simple, because while a fully repaired ship will only have its exterior faces exposed, damage to a face can flood the compartment behind it, causing previously dry faces to start performing hydrostatic calculations. Good design involves subdividing the ship into many compartments such that damage to one doesn't flood the entire thing.
  8. The "why" is that my game is a realistic shipbuilding and naval combat game in which sections of a ship can be flooded or not based on whether one of their surfaces has been compromised. Construction will have various tools for playability but essentially boils down to what you said: a player-made triangle soup. Edit: buoyancy is calculated by surface not by volume because the latter is nigh impossible with this kind of arbitrary mesh. Hence it is necessary to know which side(s) of each face are exposed to the water. The reason I was looking for the angle calculation is that my (perhaps naive) plan was to loop through all neighbors and check each one against the previous "best" angle, such that when the loop exits we're left with the closest neighbor in the given direction. Suffice it to say I did poorly in linear algebra. If you have a better algorithm I'm all ears.
  9. My problem is a little hard to explain, and it's pretty much unique to my project so even if I could I doubt there's a ready-made algorithm out there. In my game, I have a group of triangles, each defined by three int vectors. They form a mesh which has not only an outer skin but internal partitions dividing it into "compartments." The triangles are placed directly by the player, so they cannot be guaranteed to follow any order or convention. A partner and I devised an algorithm to assign every triangle to either one or two compartments: Start from a random side (+ or - normal) of a random triangle. For each edge of the selected triangle, find all other triangles which share that edge (triangles are only allowed to share an entire edge, i.e. two vertices are the same). Of those triangles, find the one which is at the smallest angle to the starting triangle in the direction determined by the selected normal (from 0 to 360 degrees). Determine which normal of that triangle points "into" the same compartment as the original (if the triangles are coplanar, the normals will be equal). Repeat 2-4 recursively until there are no unique sides to add. At this point they must necessarily form an enclosed solid. Select a new triangle side which has not yet been assigned to a compartment (but may be the opposite side of one that has) and repeat 2-5 until every side of every triangle is assigned to a compartment. Steps 3 and 4 are what's causing me grief. It's simple enough to find all the triangles which share an edge with a given triangle by looping over the collection and testing each triangle's vertices. It's slow, but it only needs to be done once when the mesh is loaded so it won't hurt the framerate. However, once we have this subset of triangles radiating from a given edge, the task becomes harder. Here's a picture to help explain what I need to do: [attachment=34701:triangle madness.png]   I've spent pretty much all day scrawling vectors on scrap paper and pulling my hair out but to no avail. Anyone have some advice on how to accomplish one or both of these tasks?
  10. There will be options to accelerate time in strategic view. Not sure about the battle mode, depends on whether or not it causes the physics to totally freak out.
  11. The intent is to make a realistic naval strategy game with player-designed ships. It's what the game I mentioned in the OP, From the Depths, was trying to do but rather missed the mark in my opinion. Players would design classes of ship in creative mode and build instances of them using actual time and resources. Strategic gameplay would take place on a 2D world map, but when two fleets meet, they are taken to a full 3D physics environment to settle their differences.
  12. This is a project I started in Unreal Engine 4 a while back, got fed up with, dropped for a few months, and finally came back to. The project began in a Discord channel of a role-playing group for a game called From the Depths. FtD had some good ideas, but it's clunky, unrealistic, and not very well balanced. Our group in particular found it unsuitable for the early 20th-century-style naval battles we wanted to simulate. This is my attempt to do better. Needless to say this is pre-pre-pre-alpha footage and there's a lot to be done before it's ready for public consumption, but I'm quite proud of what I have so far. [video=youtube][/video] The major difference of this game versus every other 3D ship construction game I can think of is that it scraps the voxel system for what I'm calling a "surface" system, because it works by placing flat surfaces whose endpoints are on a grid. This has a few advantages that made it ideal for the kind of game I want to make: Less performance drop with large constructions (a few large plates vs. thousands of small blocks in a voxel system) More room for player creativity as you're not limited to a finite palette of blocks Lends itself to realistic physics and damage models Also, since the video went up I improved the texture mapping on the meshes and added a preview of the surface you're currently placing to the UI: Here are some references I used for the math: Per-triangle buoyancy that doesn't rely on knowing the volume Equations to generate realistic waves Implementation of the above in an Unreal Engine 4 shader
  13. Yeah, it seems that Steamworks requires Visual C++, which is a pain in the rear because Microsoft doesn't distribute it without the entire Visual Studio IDE. I'm downloading the free version now, and hopefully I can get it to work with that. I'm also betting that whatever version of SFML I have doesn't work with MSVC and I'll have to reinstall that as well. Yaaaay.
  14. I recently had an idea for a quick little game and decided that I could use the idea to experiment with the Steamworks API in case I ever decided to release it or a future title on Steam. So, I logged into the Steamworks website, accepted their license agreement, and downloaded the SDK. After extracting it, I tried to link it in Code::Blocks. At the top if the "getting started" page, it lists three things you need to do to implement the SDK: Include steam_api.dll in the runtime directory or search path. Include the library steam_api.lib in the project. Include steam_api.h in C++. I did all those things, as well as include the directories containing these files in the appropriate search directory lists. When I compile, however, I get a long lists of very similar errors. Here's an example of one of the errors (the others are the same type of error but refer to different functions in different classes): C:\Users\Jonah\Code Libraries\SteamWorks\sdk\public/steam/isteammusic.h: In static member function 'static bool VolumeHasChanged_t::GetMemberVariable(uint32, uint32&, uint32&, uint32&, const char**, const char**)': C:\Users\Jonah\Code Libraries\SteamWorks\sdk\public/steam/isteammusic.h:62:1: error: no matching function for call to 'VolumeHasChanged_t::GetMemberVar_0(uint32&, uint32&, uint32&, const char**&, const char**&)' C:\Users\Jonah\Code Libraries\SteamWorks\sdk\public/steam/isteammusic.h:62:1: note: candidate is: C:\Users\Jonah\Code Libraries\SteamWorks\sdk\public/steam/isteammusic.h:61:1: note: static void VolumeHasChanged_t::GetMemberVar_0(unsigned int&, unsigned int&, uint32&, const char**, const char**) C:\Users\Jonah\Code Libraries\SteamWorks\sdk\public/steam/isteammusic.h:61:1: note:   no known conversion for argument 1 from 'uint32 {aka long unsigned int}' to 'unsigned int&' In file included from C:\Users\Jonah\Code Libraries\SteamWorks\sdk\public/steam/steam_api.h:24:0,                  from C:\Users\Jonah\Documents\Game Development\Twenty Paces\Twenty Paces\main.cpp:2:     My program is a stock SFML example program which opens a window with a static image. The only change I've made is adding "#include <steam/steam_api.h>" at the top of the file, just to see if it would compile. My compiler is MinGW GCC, which came packaged with C::B.   I've tried for hours and can't figure out what I'm doing wrong. Am I missing something obvious? Is Steamworks just not compatible with my compiler? Is there some extra setting I have to change? I'm well and truly stumped. Any help is much appreciated.
  15. I'm making a 2D tank game using a custom impulse physics engine based on this tutorial. However, the author's physics engine differs from mine in that it uses a side-scroller type view whereas mine is top-down. While in most cases the physics are the same, one important difference is that in my game, everything is constantly in contact with the ground. Therefore, everything is constantly subject to extra friction or other "resisting" forces which can be modeled by the same formula.   Modeling this with some degree of realism has me fairly well stumped. Linear motion is confusing enough, since it probably requires some heinous calculation involving the mass of the object. Rotation sounds even worse, because it requires calculation of torque based on multiple contact vectors. Can anyone link me a tutorial or point me in the right direction? I've tried Googling around, but it hasn't turned up anything.