• Advertisement


Popular Content

Showing content with the highest reputation since 03/20/18 in all areas

  1. 9 points
    At an, 'indie' level, probably not, but otherwise, yes. Unity is almost a framework for making engines, rather than a finished engine. There's a lot of room for customising the engine to fit your needs. They're actually making this easier in 2018 by making the core of the renderer even more scriptable. UE4 is less flexible, but AAA teams would still have internal engine programmers tweaking their version of it! No two games that I've worked on have ever used the exact same rendering code, even when using the same engine. This is especially true for console games where the hardware is so underpowered and the expectations are so high. Even when I was working at a small /sub-AAA console developer who pumped out ~$1M games annually, we had multiple graphics programmers on the team, plus a tech artist also doing graphics programming work sometimes
  2. 9 points
    Download the SDK and check out the docs to see the problems that it's solving: http://forums.directxtech.com/index.php?topic=5860.0 Basically, an RT API is a great stress-test for modern compute-based GPUs. You want things like: Dispatch calls that can dynamically produce more dispatch calls, recursively Dispatches that can pre-empt themselves with calls to a different shader, before resuming. Being able to bind an array of compute shaders to a dispatch, and have them refer to each other via pointers. Being able to bind many root-parameter sets to a dispatch. A very smart scheduler that can queue and coalesce these different shader invocations into large thread groups before executing them. Current GPU's are almost here, but even with DX12/Vulkan, this kind of stuff is impossible. The API described in the SDK preview is trying to solve these problems. They're also promising to put a full compute-shader based fallback implementation up on GitHub, which is amazing! ...and then any apps written against this common API will be able to be accelerated further as the HW vendors move more and more of it over to their next generation of front-ends / thread schedulers. NV already has hardware that can do this stuff, so Intel and AMD are under pressure to catch up with more flexible shader thread scheduling. Also, NV don't like being locked to MS, so you can be certain they will releaseGL and VK extensions soon enough... at which point Khronos will feel the pressure to standardize these features too. Maybe in the long term, having standard RT API's is a silly idea... but in the short term, this is going to have a very positive effect!
  3. 7 points
    Oh, please, please, whatever you do, don't ask people about their weaknesses, unless what you are looking for is the ability to manufacture bullshit. If someone asked me about my weaknesses, I would either walk out of the interview or tell them that my biggest weakness is not having any tolerance for ridiculous questions like that one. Really, what do people expect to learn from such a question?
  4. 6 points
    I've put together some tutorials that explain the ideas behind Marching Cubes and Dual Contouring. Maybe it'll be useful to some of the forum-goers. Marching Cubes 2d Marching Cubes 3d Dual Contouring Each tutorial comes with sample code in Python. Let me know what you think. This is the first time I've written a tutorial, but may do more if people want them.
  5. 6 points
    I sent Dave a gift on behalf of GameDev.net. We've known him a long time, and while I didn't get a chance to sync up with Dave at GDC this year, I had a chance to speak to him at length at the Austin Game Conference last year and get to know him better. Dave loves game AI, and he loves the community surrounding it. He does a tremendous job running the GDC AI Summit and in Austin talked with me about how he organizes it. His passion is deep and inspiring. This is the latest at this point from his family: We're all hoping @IADaveMark recovers fully.
  6. 5 points
    I use CMake to generate my VS projects with filter layouts that match my disk folder layouts. I was quite surprised when I started a C# project and realized that VS would do this automatically there! Surely there's some hidden option to turn in on for C++ projects (/ off for C# projects)?
  7. 5 points
    Definitely a null pointer access. The fact that you accessed `pic` in the previous line doesn't guarantee that it wasn't null. I suggest posting more code!
  8. 5 points
    Hey guys, got a lot to show today- we've been very busy! 4/6/18 4/5/18 by Blakkfox by Blakkfox 4/4/18 created several tiles by Blakkfox by Blakkfox by Blakkfox by Blakkfox 4/3/18 finished two large lake maps by Blakkfox by Blakkfox finished five small tent maps by Blakkfox by Blakkfox by Blakkfox by Blakkfox 4/2/18 three hadou plague busts by Blakkfox refined plagues' plot 3/30/18 moar monsters by liquid_pencil & Blakkfox by liquid_pencil 3/29/18 by Blakkfox working on exterior maps of Darkfall Lake pixel monsters by liquid_pencil by liquid_pencil & Blakkfox by liquid_pencil & Blakkfox by liquid_pencil & Blakkfox by liquid_pencil & Blakkfox by liquid_pencil & Blakkfox by liquid_pencil by liquid_pencil by liquid_pencil by liquid_pencil by liquid_pencil -created fort interior by Blakkfox 3/28/18 worked on GUI for battle stats by liquid_pencil worked on map paths by Blakkfox & Catalyst 3/27/18 worked on adjusting plague busts to be more expressive, have 10 finished ones working on 5 more by Blakkfox 3/23/18 worked on several emotion plague busts by Blakkfox by Blakkfox 3/22/18 worked on Plague bust default by Blakkfox 3/21/18 created Fusion article working on Plague bust 3/18/18 created Daksu the Destroyer article fleshed out Asrea and Saukvi a little more Revision of past plot created Eve character art
  9. 5 points
    It's true that game engines handle most of the heavy lifting out there and aid you immensely as far as the graphics pipeline is concerned, but even if you do build a game on Unity or Unreal those usually don't get you all of the way there, especially when your game demands some more specialized advanced behaviors. Say you want to implement a seeing through walls mechanic. What this guy did here is nothing short of impressive. His solution was built on Unity but required a lot of ability as far as the graphics are concerned. What if you wanted to implement a wall jumping mechanic? Or a gravity on the walls mechanic? There are tons of cool things you can do to your game that OOTB free game engines don't have implementations for. I'm working on a racing game where the track twists and corkscrews, and I needed a mechanic that would apply gravity to only the track. Unity's built in physics weren't really that useful for me so I had to use some good ol' linear algebra to get things working right. </self-promotion> The point is no matter how much heavy lifting these engines do, there's always a ton of ways to get creative on top of them, and it's going to making things way easier for you if you come in equipped with some of that mathematical/graphical knowledge. The thing is a lot of big publishers still have dedicated teams working on in house engines that have their own rendering pipelines and physics engines. For example most Nintendo games are made on game engines that aren't publicly available. Id hasn't released their new engine they used to build Doom. A lot of these in house engines rely on various pieces of middleware from outside though, so they still need talented developers to string them together.
  10. 5 points
    SVO - it is only necesasry when you literally couldn't fit your 3D texture into memory. The voxelization, building tree, etc. is not that expensive - the traversal is what is much more expensive. Also using properly hardware trilinear filtering ends up in increased memory usage. I could eventually switch to it to show the differences (in memory and performance). And give you here more proper figures - if you want. Actually it's 1.0f / resolution - it's size of voxel cube within 0.0 - 1.0 boundaries (as we're just looking up texture). The sample_diameter is actually maximum from minimum voxel size (in texture space coordinates) and 'cone_ratio * dist' - where dist is distance travelled and cone_ratio is representing apex angle. Sorry for that, here is updated one (my tone mapping parameters are a bit 'overdone' though): This one has disabled MSAA for GI and Reflection cone tracing buffers, and enabled MSAA for deferred shading (hence different numbers), this doesn't matter for voxelization though - it took ~4ms here. I enabled voxelization of whole scene every frame. So why was there 0 before? Simply because I voxelize only 'when required'. This is especially useful in editor! I can post more detailed analysis on that if you are interested in that part (how long actual voxelization takes, how long separate miplevel generation take - for specific resolutions, etc.), as I've written this into profiling back when I worked on SVO implementation - so it's just about switching some defines and writing it out.
  11. 4 points
    I'm always interested in learning others' stories. How and why did you start learning game development? Mine: Like most of us, I grew up playing games. My earliest memories are playing games I can't even remember the names of on Atari, Donkey Kong on Colecovision, and I remember when I received a Nintendo along with Legend of Zelda, SMB, 10 Yard Fight, and Top Gun. My imagination would run wild during my days at school, so I started doodling levels and maps for different games. I'd draw my favorite characters, like Link and Mario (if I had the motivation I'd dig up the Mario coloring book I made when I was a kid and show it), then come home and play more games. I did a lot of other things as a kid, but any "down time" was playing games. Then I learned that you could do that for a living, and around that time I also got some exposure to computers. Some in my family came across a Commodore Plus 4 at a garage sale, and while they didn't know what I could do with it (if anything), they left it up to me to figure that out. In the manuals was a BASIC programming guide. And that's when I learned how to make games. "Flip a coin" was the first. Don't discount that simple BASIC code. In fact one should never discount anything based on its scope. The act of making that interactive, RNG, text-based game opened the mind to all kinds of possibilities. More simple games followed - and then I learned how to render lines on the Commodore and my focus turned to graphics. As I learned more about programming, my ambitions expanded, and I shifted into a pattern of learning more about game development by trying to replicate gameplay from games I loved to play. I jumped interest in BBS games and started writing a clone of BRE and SRE in Turbo Pascal. I did a TradeWars 2002 clone and a few other ideas I'd play with, like multiplayer games over a serial connection between two PCs (had to write the serial driver). I loved to play Warcraft, and one of my first C/C++ language uses was to make a text-based/ASCII turn-based, two-player Warcraft clone. Somewhere along the way I came across mode 13h. I spent many nights learning 3D graphics and rendering spinning boxes. Various other game projects came and went. I loved to read others' source code and learn how they approached many of the same problems I've faced. These days I can easily spend hours on Github. GameDev.net spawned out of a love for all the above and a desire to make it easier for people to learn and connect with others about game development - and nearly 20 years later (in June 2019!) all the above is still fuel for the fire. Eventually, I got a job in the simulation training industry - basically serious games interfaced with real equipment for training purposes. I worked on various products for a few years until we made the decision to upgrade our technology. Unity was brand new and barely functional, and UE2 lacked the necessary features, so as Technical Director I architected and led a team to develop an internally used game engine and toolset (entity-component) based on ~40 commercial/open source packages but with many of the same content creation capabilities in modern engines, including things like blueprints. The goal was to build a simulation and training curriculum without having to write a line of code, and we came very close to achieving that in most cases. Production went from ~12 months to ~3-4 months. Big win for the company and a total cultural change. Now I'm in semiconductors with a team working on developer tools, and we work with a lot of developers around the industry. Depending on what you do, it's possible you use my team's products. My game making days are pretty minimal, but I always have the urge and a list of games I'd like to work on. But making sure everyone here has a game development community through GameDev.net tends to take most of my free time. [EDIT: I should clarify why I didn't go into games. It basically came down to a certain type of work-life-pay-location balance that I wanted to have at the time I started my career, so instead of going into the industry I decided to do the next best thing and work where I got to work on the same type of technology, but the end product was different. I've thought about going more directly into games in more recent times, but I'm at a much different stage of my career now (engineering director-type) so it would have to be the right fit.] Having said that, it's motivating to see what everyone is doing, and I appreciate seeing how the industry has evolved since those early Commodore days. So, what's your story?
  12. 4 points
    Ah yes, DarkBASIC, that was my starting point too for programming. I dropped it pretty quickly though once Unity became free. Well like many I absolutely loved and still love gaming. I'm a lot younger than most on here, so my experiences are pretty different. This story starts when I was 10/11 years old. My mom, a professor in an IT related field, saw my interest and saw this software known as Alice, though back then it was still Alice 2. To an 10/11 year old kid who was interested in how games are made, this was the most amazing thing ever. Dragging and dropping commands to manipulate a 3d world was amazing. I made several small games with it, but soon reached the limits of its capability. So in middle school, I moved on to try learning programming. I learned a language known as DarkBASIC, and tried building stuff with it. I didn't get far (DarkBASIC just isn't that great honestly), and moved on to learning Java, etc. At that time, Unity was made free, so I built several small world explorer type things. I learned some very basic modeling with a software known as 3D Canvas. Now this is where my story diverges a bit from others here: I started to lose interest in pure game dev and became interested in things like AI and machine learning, ultimately prompting me to pursue a degree in Computer Science. Game dev would sit on the back burner for some time. The past two years did see a bit of a revival in a very related field: 3d art. In particular, I became much more interested in just pure 3d art. So nowadays I spend more time on these sorts of things: (The above is a work in progress btw) I've attached some other pieces, of which the last two are 1 day mini pieces. But this is what I do on the side. My job now is in software development, about 1 year out of college. I'm still figuring out career directions (which include graphics, machine learning/AI, or something entirely different), so let's see where I go. I've toyed with several game ideas and still use Unity for making cinematics, but I haven't actually worked on a game as of yet. Maybe I will once more potentially. Still a huge gamer of course!
  13. 4 points
    I'm moving GameDev Challenges to the new Groups feature, which I'm rolling out as a beta as I work out the kinks figure out how best to integrate it with the community. (so many ideas!) I've already created a GameDev Challenges Group. You can also access groups through the Browse -> Groups menu item. Join the group and check out the group announcement! I'll be posting the next challenge there within the week. Thanks for making the GameDev Challenges a fun and successful part of the community. Let's make it even better with the new Groups feature.
  14. 4 points
    QFE. Formatting a format string is a bad bad thing to do. If you include any user input at all, you're opening a gaping hole (imagine a username of "%s"). It's as if you've said to yourself "how can I take one of the most insecure, error-prone, dangerous parts of the language and make it more error-prone, dangerous, and insecure?" Then, of course you come here asking "I've made the most error-prone part of the language more error-prone and now I have an error, can I keep digging until I find my way out?" Modifying format strings that get used elsewhere at some unknown time is implicitly modifying global state as a side-effect of your functions. Instead, make your functions pure and have them returns already-formatted strings, only assembling them into larger strings when you have control and not as a global variable.
  15. 4 points
    Nintendo Switch is the only console that uses mainstream graphics APIs (GL/Vulkan supported). Every other console uses/used a custom API. PS4 has GNM, which is lower level than Vulkan, plus a wrapper around that called GNMX which makes it look a little closer to a D3D11 style API, and then a semi-unofficial wrapper around that to make it look like a GLES style API. Those wrappers are only recommended to get started, with the recommendation to eventually port to raw GNM. Xbone has D3D11.x and D3D12.x which are very similar to their PC counterparts, while also being very different in some key areas. PS3 had GCM, Xb360 had D3D9.x (again, very different to PC), Wii had GX. Everything earlier than that was even more fragmented as the concept of a GPU hadn't solidified yet... An indie dev who shall remain unnamed started a rumour that GL was the fastest API on PC and that it was used by the PS3 years ago, and for some reason many people still regurgitate this as fact... If you're making a cross platform game, you've always needed to have multiple graphics API back-ends. Even if "cross platform" just means Win/Linux/Mac to you and you believe in "OpenGL everywhere" - that's at least 7 different OpenGL implementations that you need to test your code against and almost certainly make code tweaks/fixes for (every manufacturer implements the entirety of GL from scratch, with differing core behaviour, extension support, performance characteristics and shader-code parsing abilities). It's quite likely cheaper to use D3D and Metal rather than doing the extra GL QA work on your Windows/Mac ports! The SDK was rolled into the Windows Platform SDK. The toolkit is the equivalent of the old D3DX library - very useful utilities that most apps will need, but aren't "core" enough to be part of the D3D API itself. "Practical rendering and computation with direct3d 11" is my go-to reference for D3D11
  16. 4 points
    Here we go! DevBlog #3! Wow! It's crazy how far we've come in the past three months or so. The support from everyone here and through Reddit has been awesome! Since the last post so much has changed with the game. It's hard to even know where to start talking about the changes to 'Crazy Seas'. The whole team has been working their butts off since the last blog, and we had a very productive Easter vacation. Before I go any further, I am going to do a shameless self promotion. As some of you know from previous posts, we have a twitter which you can find here! We try to post updates on the Twitter as well, so if you want to see progress before it reaches the DevBlog, that's the place to go. As the game progresses and we reach a public play-testing stage, we'll be revealing a lot more on there and you'll be able to see when and how you can get your hands on the game. This week we also started a sub-reddit. You can find it here. The sub-reddit is a really important place for you if you want to stay updated on news and be able to actively help shape the game. If you have questions or suggestions, the sub is the place to go for that. We are looking for some community moderators, so if you have experience please let us know! Anyways with that said... back to what you've all been waiting for; News! Starting with some Art Alright lets talk art. Over vacation we lost our artist. They moved on to try and make a living through solo gigs so we've been back to lacking in the art department, HOWEVER, I tried to pick up some of the slack. I've been trying to teach myself some art programs over the past couple of weeks and I finally have some things to show for it. I did a lot of GUI work. It's a little rough, but we have the starts of some menus and systems that are coming to the game soon! The first one is the Log Book. This is the menu where a lot of things are accessed. The symbols pictured above don't represent everything, but some of the things you'll find here are your Inventory, Mail, Friends, Announcements, Skills, the World Map, your Crew, your Glossary, and more. All (or most) of these things will also be accessible through hotkeys, so its kind of user preference whether or not you want to use the book. Below are some close ups on some of the symbols. Again, these are rough and were my first ever go at some real art so things can only get better from here! Something felt wrong with my mail icon originally, but I figured it out now... I think! I also did a temporary make over for the inventory just so we didn't have to look at the Unity placeholder eye-sore anymore. Now we can look at a slightly less eye-sore of an eye-sore. And of course, we've been working on a chat system, so I did the art for that as well. As you can see, we've made lots and lots of progress even without an artist. Being totally honest, I think we're even better off now because we realized we could do what they were doing without them anyways. However, we are looking for a much more artistically talented artist than myself so if anyone is interested, feel free to hit us up! Oh and we have an indicator for combat tagging, but I didn't make this one all by myself. Transitions I'm excited for this one. In a previous post, we finished off changing the water color depending on where you were in the world. It's finally implemented into the build now and well, I'll just let these GIFs speak for themselves. Look how seamless and pretty that is. You may have noticed the big yellowish thing on the top of the screen as well. That's our new transition scroll! It went through a couple of phases before it got to where it is now, and it's still using a placeholder, but this notification pops up whenever you transition from an area so that you can see where you are. It's going to need some modifying, but our eventual plan is for it to tell you what Crew has control of the area and whether or not it's PvP or PvE. But overall, the scroll is looking really good and I'm very excited for the prospective things that could come from it. Weapons I was going to make you wait till the end to hear about the weapon additions but I figured you wouldn't want to wait that long. This post comes with two brand new weapons, and I'm very excited to introduce them both. I also made a TON of placeholder cannon skins for the test build so that we can start messing around with skins. I don't really have any ready to show off yet, but take my word for it, they're coming. The first new weapon is the Sniper Cannon! For now, it's just looks like a longer version of the Regular Cannon. It shoots a faster, smaller, cannonball that has medium range. The speed of the cannonball allows for a higher hit chance as it has less travel time than any other cannon. The reload speed of this cannon is faster than the others, but it deals much lower damage. The aim of this cannon is so that you can hit your target and know your shot will land. It's useful for enemies who are on the run and need one last hit to finish them off. (This GIF has the old assets... sorry) The next new weapon, and my favorite addition so far, is the Harpoon! (Harpoon Cannon? Not really sure what to call it...) The harpoon is a weapon that fires, well, a harpoon, at an enemy ship. The harpoon attaches that ship to yours and drags them toward you for a brief period of time before breaking. You'll be able to extend this time depending on the type of Harpoon you find and with your perk tree. The rope length is also a variable that can change depending on the stats of the weapon. It's not perfect and still needs a little adjusting, but it totally changes ship combat. Since implementing it, we've decided its probably better in a front slot than on a side slot, so it will probably go where the Ram goes. And speaking of Rams, I guess we technically have three weapons being added because the Ram is now in game as well. I've mentioned it in previous posts, but its in game and fully functioning now. It will Here's a GIF. There's no indicator of damage or damage particles because that's not an actual player I'm testing it on. But normally it will produce particles and the enemy ship will take damage. You can ram an enemy ship without a ram, however you'll need a ram to negate the damage that it would cause to your ship. If you ram a ship at a higher speed, you'll do more damage to it, but it will also do more damage to you. There is a falloff/recoil if you're not using a ram, so it's best to only be charging into your battles with a ram equipped. Inventory The inventory system is coming along nicely since the last post. We now have separate player and ship inventories, and different tabs for the various things you'll be carrying. It's currently in active development, so I took some sneaky screenshots, but a lot of things are missing from it still. It'll probably be done by the time this post is actually out. Hopefully the new GUI art will be implemented for the next Blog post so you can see how pretty the inventory will actually look. Anyways, enough rambling, here's a GIF. (The things you see in the player inventory are just testing.. ignore them... seriously, don't read into them.) Ocean Objects Here's a rock. I'ts not very pretty, but it does its job. Rocks, and other sea objects, can be found out in the ocean. They help break up the boring ocean and also provide cool places to have fights around. As of right now, you can also hide behind them. I'm not sure if this mechanic will stay in game, but for right now it's kind of cool to not know when a ship could pop out. Ocean Locations (Hotspots!) Some ocean locations have been added to the game as well in preparation for the fishing mechanics. These locations provide two useful services. For one thing, they help to keep the ocean interesting and make it so you don't have to sail across plain sea for hours on end. Consider them to be "mini-biomes" if you will. The second thing they do is house different fish. At these fishing 'hotspots' you can find different species or harder to catch fish that you might not find in other places. As of right now there isn't anything to show for fishing, but work is starting on that soon. I'll go into more detail on the fishing mechanic in a future post. Here's two of the three locations currently in the game. The have terribly awful placeholder art (I can say that because I made it) but they serve their purpose. This is the Coral Reef and the Bone Graveyard. There's also a ravine but that placeholder is not worth showing. In Conclusion... It's been a very successful past couple of weeks. We're still working hard on features and will have a lot to show off in the next DevBlog. We have been working on a ton of back end and server side stuff behind the scenes so that we can start having people join in the game. Account creation, User IDs, and a lot of other systems are already in place, which is really good. We need to get a few more things done with the inventory and the markets before we can start to allow people to come into the game world as well. I didn't show it off, but we have started to build a town on the island. If you're an eagle-eyed reader, you may have even caught the name of our first island hidden somewhere in this DevBlog. Anyways to feed your interest, the next entry will probably feature some new weapons, fishing basics, and the finishing of the UI. I'll try to throw in some stuff about the islands as well. That's all I'm willing to tease as I want it to remain a surprise as to what else I'm going to share. Thanks again for all your support and for taking this journey with us! - Jack from VG As a reminder, you can follow us on Twitter here, and can stay up to date and participate in the community by exploring our sub-reddit here. And one more extra reminder, we are looking to expand the team and add another artist. If you're interested you can add me on Discord at Jack#2228, or you can reach out to us in the comments or from one of the social medias listed above.
  17. 4 points
    Hi, It's been a while since anybody posted here but I thought I would share the fact that I'm presenting more of our cloud work at Eurographics 2018 next Thursday in Delft, The Netherlands. I don't know if any of you are or will be in the area, but it would be a good opportunity to meet and talk clouds. Best, Andrew
  18. 4 points
    if you discard only 1/255 of the pixel (assuming you mean black == 0.f), then there won't be any performance benefit from discard nor stenciling, as the GPU will dispatch pixel in groups of at least 2x2 (yes, fragments will be processed that are already rejected). Therefor the only speedup you'll get is in cases where there are 2x2 pixel blocks of black pixel, which are also exactly in the 2x2 pixel grid. 1:4Billion Hence, if that is only about performance, go for a discard, it has at least less setup overhead.
  19. 4 points
    I disagree with most of your post, but that doesn't really matter -- I'll only focus on the quoted part. The poster is not asking for a discussion about copyright laws and how they could or should be changed. This is very clearly a "what can I do to prevent this" question. As such, your subjective feelings on the matter don't really matter. If you really do feel strongly about the topic, maybe you could start another thread, but my opinion is that you shouldn't keep on derailing this thread.
  20. 4 points
    The skills from one platform can be converted to the other platforms easily. You get a set of different libraries to do things, but it isn't so different. If you're comfortable making games in Windows with DirectX then you can also develop them on the XBox One. The console's OS is a customized version of the OS. If you're comfortable making games on Unix then you can also develop them on the PS4. The console's OS is a customized version of FreeBSD. Game studios know that students and recent graduates don't have experience on that specific hardware. But fortunately for you, the specific hardware is nearly irrelevant. Hardware changes every few years, just like operating systems are constantly changing, and programming languages are constantly changing, and hardware is constantly changing. The languages you use today didn't exist a decade ago. Even though you use versions of Java, JavaScript, Python, C#, and C++, the versions of those languages that you know and use today did not exist a decade ago. The devices will change again, there will be the PS5, the XBoxTwo, and the Switch3D, or whatever follows. Those all change. The thing that doesn't change, the thing which is constant across all operating systems, across all hardware systems, across all programming languages, are the algorithms, theory and data structures. Learn and master those. They will never go out of date. As you gain a solid grasp on the core algorithms and data structures, also spend time making games on whatever system you have available. The game studios already have tools available that let their source code work on the Windows PC, on the Mac, on Linux, on smart phones and tablets, and all the programmer needs to know is the programming language and the theory behind them.
  21. 4 points
    I'm currently using the one that skips voxels on the way. I've had some attempts on DDA, but the general problem with those is that they ended up being far inferior in performance. I can even share: // P - ray origin position // V - ray direction // cone_ratio - using 1 large cone lead to poor results, multiple ones with some sane ratio looks a lot better // max_dist - maximum acceptable distance for cone to travel (usable for AO F.e.) // step_mult - in case we want "faster" and even less-precise stepping float4 ConeTraceGI(in float3 P, in float3 V, in float cone_ratio, in float max_dist, in float step_mult) { float min_voxel_diameter = resolution.y; float min_voxel_diameter_inv = 1.0 / min_voxel_diameter; float4 accum = 0.f; // push out the starting point to avoid self-intersection float dist = min_voxel_diameter; // Marching! while (dist <= max_dist && accum.a < 1.0f) { // Calculate which level to sample float sample_diameter = max(min_voxel_diameter, cone_ratio * dist); float sample_lod = log2(sample_diameter * min_voxel_diameter_inv); // Step float3 sample_pos = P + V * dist; dist += sample_diameter * step_mult; // Sample from 3D texture (in performance superior to Sparse Voxel Octrees, hence use these) float4 sample_value = voxelData.SampleLevel(shadowSampler, sample_pos, sample_lod); float a = 1.0 - accum.a; accum += sample_value * a; } return accum; } This is the result for such GI (this is in-editor): The performance is also no that bad (considering this is an editor - and we're running full deferred pipeline at 4x MSAA (including 4x MSAA for calculating GI and reflections) ... along with a lot of other things). Overall I'm quite satisfied with my VXGI implementation. Even though I also have support for octree-based version (not 3D texture based one), it ends up being few times slower. To also give you a hint on performance - here is another one with profiler shown:
  22. 3 points
    Ive finally put together this demo. Only one enemy, but I hope you will like it and leave some response. My main goal is inventory system. Grid functions arent my favourite thing, but I will still use them, but first I wanted to show you at least some of my work. Errors will probably appear, Im sorry for that, but the base is good in my opinion. Im NOT an artist, my sprites are bad and I know it, so ignore them now. Here is my work so far --fightSystem for rpg3.zip--
  23. 3 points
    Hey All, Another week another great update! So we have several new features that were implemented. First, we now have a start screen with a menu. Right now I'm just using the starting room background for the artwork on the start screen. This is only a place holder and will be changed. Right now the options to select are; New Game, Continue Game, Arena, Store, Credits, and Quit. 3 of these options currently work. New game starts the game and continue game works as designed, more info below on how that system works. Arena mode, the store, and credits are placeholders. The quit option currently quits the game but that will be removed as you do not need that for a mobile title. Also along the same lines we now have a game over screen. This screen also has the same artwork as the start screen (will be changed later) and displays game over text to hit the space bar to continue. For this screen I will also be creating an animation of the main character spinning and falling on her knees. So now lets talk about the continue game feature. This does exactly what it states, allows you to continue an ongoing game. There is a save system in place for the game that is making all this work. The save system is an Auto Save feature. The player is not allowed to manually save their progress. Remember this is going to be a "rogue-lite" game. So it will autosave every time the player enters a new room. I found it best to implement it this way as it's a mobile game and if you get interrupted, your last progress of clearing that room will not be lost and you can pick up where you left off. If you get a "game over" the auto save is completely erased. You cannot continue a game after a game over. The next thing I did was some more tweaking on the shadow engine. I did a lot more work on this to try and get it more realistic. Now the left wall, door, open door, room props, and enemies have shadows. I even added depth to the shadows so if an object goes under a shadow it gets darker from the shadow being casted upon it. Still needs some more tweaking but it looks a lot better. I will be creating a lighting feature in the game. Some rooms are going to be dark. The only light in the room will be from candles or a flashlight. This will just add more elements to the gameplay and look really cool at the same time. Created two new objects in the game. These are room hazards. The first one was mentioned in the previous blog post. Mucus was created. He does not harm the player. He sits on the ground and pulsates a little. If the player runs through the mucus your speed is drastically slowed down while your in the mucus and up to 1 second after you get out of the mucus. This proves to be a huge obstacle when you are running away from an enemy or need to run from an enemy. The second hazard which I am extremely proud of is the hole. There will now be random holes in the floor of the rooms. If you get to close you will fall into the hole. I have also created the animation for falling into the hole. Once you fall into the hole you disappear, lose 1 heart of health, then re appear at the location where you started that room. You will also be slightly invincible while you re spawn just in case you are re spawned next to an enemy (invincible while blinking). I am very pleased with the results of this feature and it's going to be expanded upon. Which leads to the next feature that will be implemented......Secret Rooms! Secret rooms is the next thing I will be focusing on. In order to access these secret rooms you have to fall through a hole in the floor and be granted by the RNG gods that the hole does not damage you and brings you to the secret room. If you find a secret room through one of the holes you will have the option to purchase upgrades. These can range from +1 heart, +1 stamina, health potion, etc. These can be purchased via coins that are collected while playing. What will be offered will be complete random and will only be temporary for that particular play through. This way every play through is different and you always end up with different stats and upgrades. More on this to come. Two sound effects have been added to the game. They are for hitting an enemy and using the firecracker explosives. Which reminds me I have not talked about that power-up yet. The firecrackers can be used against all enemies, even damage the main player, and are very powerful. They require 3 stamina for use and do 4 damage. Also a long with this I have cleaned up the pause and inventory screen. I made the dim of the game darker while in the pause screen so you can see the inventory more clear. Also I will be adding a quit to menu option here if you choose to quit back to the main menu, which can be important because doing so will NOT delete that auto save file. I believe that was everything, if I missed anything I will add it to next weeks blog. Here is a gameplay video showcasing most of the features discussed in this weeks blog. Please post comments and questions we will respond! Thanks much!
  24. 3 points
    I am happy to announce that we release first demo of Rail Route! We have polished our first prototype of train routing and added a simple tutorial. To make it more a game than a prototype we have included short level where you can try your dispatcher skills. You can download it at our blog: https://railroute.bitrich.info/2018/04/17/demo-r0-1-released/ Or you if don't want download .exe from the internet we prepared Unity WebGL build: https://bitrich-info.github.io/railroute/r01/ Levels in Future Our vision is that the final game will contain a handful of such levels, some longer, some short (puzzle game / unlock scenario). You will be able to compare your performance with the others (global Top 10 list). We are thinking of tools that enable you to create & share own levels, so you will be able to model your home city railways if you want. These levels will be only one game mode, but the primary game play will be something completely else. Something like career mode where you take care of rail network that you will need to built, upgrade, manage and so on. We will write about it soon! Feedback We would like to hear any feedback from the prototype. So feel free to reach us anywhere :-). What's the best score you can reach?
  25. 3 points
    I think you'd need to make a reference vector that is perpendicular to your navmesh edges, right (a "surface normal")? You could cross product two of your edges on the current cell. If you know they are always in a specific order, that means the cross product of edge[0] and edge[1] should be fairly consistent between cells. If your navmesh is always flat (or nearly flat), the normals of all of your navmesh cells should be close to the same direction ("up"). It may be simpler to just always use "up" in this case to bypass having to compute the cross product of the cell's edges each time you need it. Alternatively if the navmesh never changes, you could at the very least precompute the normal vector of each cell when it is created.
  26. 3 points
    Well I was 6 years on, back in 198t. Then I wrote other games and taught myself how to program with a pen, paper and math grid paper. I was in Africa no access to a computer, just a library card that gave me access to computer magazine and monthly Radio Shack manuals. Eventually through the efforts of an expatriate British English teacher I got my hands on a ZX spectrum, eventually a BBC microcomputer, AMIGA,Archimedes. I released a sprite editor, and a paint program on shareware back in the late 80's on Atari ST. Been doing this as a hobby for years I refuse to be in the industry, and instead been working on network engineering stuff. Currently working with NVDIA developers and CISCO developers and 3rd party company on firmware, firmware and opengl drivers fixing issues with remote graphics on platforms using HP RGS, UGE Openlava on an NVIDIA Grid k2 cards on ciscoc240+ servers.
  27. 3 points
    You should never use sprintf to begin with, because it has no way of checking if you are writing past the end of the buffer. A valid alternative is snprintf. Then again, you should only use this when you need formatting. When passing the string around, when storing it or when sending it to the drawing function, you should just handle it as a plain string, without doing any formatting. EDIT: Oh, and please use std::string if you are programming in C++. You are much less likely to mess up that way.
  28. 3 points
    Once again we have a new entry to this devblog. First of all some logistics: We will post new updates every other week from now on because we just don't make enough breakthroughs to justify wasting your time every week. And we decided to categorize these entries. So far we got "Update" and "Feature". Updates will deal with the current state of the game while Features are more theoretical and will explain certain features we are planning on implementing or are currently implementing. So let's jump right in, shall we? The cell stage is coming along nicely. You can see the current state in this video on our ... Could that be? On our brand new YouTube channel! There are still two minor bugs with the compound clouds: #1 Vertices only move until they are in the center then stop there; Solution: Move the cloud end reorient the vertices as soon as one hits the center #2 You can basically swim through the cloud and as long as you don't get too close to any vertex it won't deform; Solution: If you are between a vertex and the center move that verteg towards the center of the mesh One feature we wan't to add that isn't in the code yet: Calculate the value of the clouds (the amound of the compound you can extract from it) based on the mesh's volume. So far it's a static value and the mesh simply disappears once it's zero. Also you don't gain any compounds from consuming the clouds yet. But that will change within the next week. During that time we will also implement the different types of clouds. So far there is no solution in sight on how we will generate the cloud representation so we can finally make the mesh invisible. This is our main hurdle at the moment. There is now a Logging function that writes important messages into a log file, e.g. if the connection to the database failed. That's right: We now got a database connected to Lyfe. There will be a separate DevBlog on its structure once it's fully planned out. We decided on SQLite. Mostly because it does everything we need and is easy to use. Another thing that's currently being discussed is how we should save your creations. The first idea was to use XML: <Creature name="" stage="creature"> <Backbone count="6"> <!-- starting at 0 then move in one direction and note all vertebrae then the other direction alignment in the degree varying from horizontal --> <vertebra id="0" parent="" alignment=""/> <vertebra id="1" parent="0" alignment=""/> <vertebra id="2" parent="1" alignment=""/> <vertebra id="3" parent="0" alignment=""/> <vertebra id="4" parent="3" alignment=""/> <vertebra id="5" parent="4" alignment=""/> </Backbone> <Limbs count="2"> <!-- type are the prefabs you pull into the creator x and y position on parent body mesh or something Limb set as tail/one central leg etc are symmetrical but not split --> <limb id="0" parenttype="body" type="" positionX="" positionY="" symmetry="y" split="y"/> <limb id="1" parenttype="body" type="" positionX="" positionY="" symmetry="y" split="n"/> </Limbs> <Extremities count="2"> <!-- Extremities can also be put onto the last vertebra--> <extremity id="0" parenttype="limb" parent="0" type="" scale=""/> <extremity id="1" parenttype="limb" parent="1" type="" scale=""/> <extremity id="2" parenttype="vert" parent="5" type="" scale=""/> </Extremities> <!-- ... ... ... ... ... --> </Creature> But one of the problems was finding a proper way to parse it while directly constructing your creation after each parsed node. Also XML files are gerenally constructed in scripts like C# or JS (from my experience; correct me if I'm wrong). This would create some additional steps while storing your creation so we decided against it. The next thing is a quite simple text file that looks pretty much like a config file and our programmer came up with: #CREATURE creature #BACKBONE 6 #VERTEBRA 0 -1 0 #VERTEBRA 1 0 0 #VERTEBRA 2 1 0 #VERTEBRA 3 0 0 #VERTEBRA 4 3 0 #VERTEBRA 5 4 0 #LIMBS 2 #LIMB 0 body -1 -1 -1 y y #LIMB 1 body -1 -1 -1 y n #EXTREMITIES 2 #EXTREMITY 0 limb 0 -1 1 #EXTREMITY 1 limb 1 -1 1 #EXTREMITY 2 vert 5 -1 1 As you can see the structure is preserved so all parent objects are listed before their children so the creature can be built line by line. All the stats are missing a defining name now and this is the only let down with kind of structure: it's not that easy on the eye and probably hard to understand. But it's easy to write, easy to parse and a lot smaller. The second one only is a third the size of the first one (after you remove the comments). I guess that's it for this week. And as always we would appreciate if you shared your thoughts with us. Keep on evolving!
  29. 3 points
    If you want to make a proper game you at least need to learn some coding. Even Gamemaker has it's own scripting language and could be a good start. There is also Unreal Engine, which allows you to code with blueprints in a visual manner, but for a bit more complicated systems you have to code in C++ which is a lot harder to pickup. This is how I would progress: Start with some basic programming tutorials. Teamtreehouse has a week long free trial, try to get in a lot of hours and it will be a nice jump start all for free. Create a command line game like hangman in the language you chosen. Keep things very simple, it is very easy to grow the scope of a game and then fail to complete it. Pick and learn a framework like Libgdx or Monogame. Code simpel games from start to finish worthy of releasing. They do not need to be great or extremely polished but they "just" need to work. You will get a tremendous boost from releasing a finished project on your own but don't expect any sales or income from them. Repeat making simple games, look for making clones that teach you something new and perhaps something you could use in your turn based game. Depending on your time it might take a view years until you are able to make something you want. Games are very complex and you need to know a lot about programming to finish a slightly complex game on your own. Don't let this put you off, if you like to code and solve problems the road to your goal will often be fun and satisfying.
  30. 3 points
    I think it would have been the summer of 1975 or 1976, my grandfather taught me cribbage and pinochle. I was 7. I haven't spent much time not playing games since then. I am usually playing a game of some kind at any given moment, I'm not really normal when it comes to games. The next summer he recognized how quickly I had advanced with games so that summer he taught me how and why Backgammon was not really a game, it was an abacus because no matter what you roll there is always only one best move, so there is never really any decision to make over the course of an entire game of backgammon. It's a more advanced version of the tic-tac-toe lesson. Tic-tac-toe always ends in a tie, backgammon doesn't actually have any decision making in it other than the doubling cube... which is why it has the doubling cube. My grandfather had a pretty advanced understanding of games and simulations.
  31. 3 points
    You make me wish I started earlier in my life. Well, for me, it's a long bumpy road.. I grew up around Nintendo super Mario, but it never impressed me. I was mostly disinterested in video games, up until Doom. I realized that video games can invoke a lot of emotions. They were art. From there, I experienced Wolfenstein 3D, Out of this World(Another world,) Blackthorne, Bioforge, Little Big Adventure... the list goes on, and on. They inspired me in many ways, and left a significant impact in my life. As well, being dyslexic, a few of these games allowed me to push myself to read, and when voice acting was involved, allowed me to follow along. Video games have always been a special place in my life due to this. So, this sparked my interest in developing video games as I wanted to bring that love that I have to someone else. To keep the inspiration train going, so to speak. Unfortunately, plagued with depression and self-confidence issues, I felt I was too dumb to make a game, and never pursued until I was 18. Found out that I really could not code, wasn't a great artist, or anything... Around the time I joined GameDev.Net. I stayed in the community while floundering from C++, to C#, to python, to C# again, but then gave up on programming. I had hoped to thrive as a writer though. I ended up actually working with someone from IRC #GameDev developing Deadly Dungeons for the android. Seemed to be a modest success. Then a few failed projects after that. I found more frustrations than enjoyment, unfortunately. So I moved on from the game dev, and just kind of did art for a while. Yet, video games keep calling me back. I decided to take up learning Japanese as one of my means to step outside of my mental imposed "I cannot do this because of x" toxic thinking. So, despite my dyslexia, I said I was going to learn japanese and translate this video game. The video game was XZR II(exile.) Took me 4 years, but I translated it, and did a let's play on it. Then moved on to translating the first game of the series (which is still incomplete.) However, I realized I needed a marketable skill. Translating was not teaching me japanese well, and I could not justify the time spending on it. Yet, I wanted to keep doing something game related. Three years ago, I got a job at a financial office. They had programming learning courses in the skillsoft website, and would look at those during slow periods. Suddenly, it all clicked. Programming made sense. Took me 10 years, but it clicked. I picked up python, and wrote a program that simulated grocery shopping, but the computer shopped for the items you told it to collect. I wrote this in a month. That concreted my path at the moment. From there, I made Tic-tac-toe in C# console, pong in Unity, Snake in monogames, and now extending on snake in C#\Monogames. Confirming that I can do this, maybe not as well as others, but that I can. Currently set up to go to college for computer science. Also, I am currently debating learning project management skills, and forming a team to make games I would otherwise not be able to. Time will tell though.
  32. 3 points
    I was in ATD (Advanced Technology Division) and my division joined BD2 to work on Final Fantasy XV, on which I was a senior graphics programmer. Most foreigners get accepted into ATD, which is basically the western side of Square Enix (note that R&D departments (which is what ATD is) are always westernized in every video-game company because R&D programmers need to be fluent in English to keep up with research papers and visit The United States of America for the major technology conferences etc.) This means the rules are different for you if you plan to join a game team directly. Very few people will speak English and it can easily become a problem. The HR team only translates the most important e-mails and in the case of BD2 there was a specific setup for this just because of how many foreigners eventually began working on it (Final Fantasy XV), so I can't guarantee any such situation exists for the group you want to join. There is no division just for this. Your computer will be set to Japanese and you will be expected to live life in Japanese (getting your own apartment, maintaining yourself and bills in Japanese, using trains in Japanese, talking to all coworkers, etc.) If you are on a major team, you can expect over 100 e-mails daily, 99% of which will be in Japanese. Free Japanese lessons are only available to ATD. I think only ATD takes foreign interns. A girl from MIT joined temporarily (I think 6 months) as part of her schooling, for example. The game teams/business divisions take "new recruits" fresh from school, but this is just part of a common tradition based around Japan's culture—it is why all companies get a bunch of new employees in April. I was not on those teams so I can't say they don't, but my feeling is they don't. Those are the tools that that team uses, so they are non-negotiable. Note that it does say "Mayaなど," which means, "Maya or similar," but this feels like a verbal technicality, since Maya is what they actually use. The only way it would be okay to have no skills in Maya is if you have amazing skills in 3DSMax (or such) that they believe can easily transfer to Maya. If you can't use Maya and have no skills that can easily transfer to Maya, then you can't get the job (note that you should always let them decide if you can't get the job—this hardball advice is just to give you an idea). BUT this is a 2D job listing. You probably will not be using these tools. They are good to know so that you can communicate with other artists (which is already going to be a hurdle), but likely won't damage your chances. If your cosplay is a typical kind of bad then I expect it would not be used to judge your skills as an artist. But there are kinds of bad that might make them think poorly of you on a personal level. And there are kinds of good that might make them think you are dedicated to the industry etc. No one can say, which means it is a risk, which means you only need to consider it if the rest of your resume is bare and you need something to fill space (but a better way to fill space would be to show relevant works you have done). Several of my female friends at Square Enix are fashion designers, one of whom (I think she is on either Final Fantasy XIV or a Dragon Quest game) only wears fluffy princess/maid-café dresses every single day (complete with a parasol, ribbons, bows, and other props). Like cosplaying at work, every single day, and she made all of her outfits herself. Some people have jobs just designing the fashion in these games, but these positions are very specialized and already filled. That being said, it never hurts to show you have secondary relevant skills. Sending in sketches and designs of fashion would be fine. Of extra note is that all foreigners are required to join on a contract basis (I was an extremely rare exception just because I lived in Japan for so long before joining). Because Square Enix does hire from abroad often, it is their policy that the recruit join as a contract employee in order for them to see if they really like living in Japan. This means that if you join before you are truly ready, you have the extra stress of wondering if you have impressed them enough to keep you for another year (stress you are less likely to have once you are more skilled). They have just started a new policy under which contracts cannot be restarted after 5 years, so you also have to have a plan for getting full employment status or considering you only have 5 years at-most on the job. Joining prematurely might decrease your chances at getting more than 5 years in the company. L. Spiro
  33. 3 points
    This week was full work on the AI, which was lacking a bit, to say the least. It is a simple state machine that changes based on the distance to the character (far? jump, close? punch/kick) and its own physical state (falling? stucked? idling? close to edge?). Eventually I managed to make sequence I'm quite proud of: Several silly situations came out of it before I reached that stage: The AI trying hard to punch, only to fall to their death. Finally! It manages to punch me. It's not really hard to terminate the threat. Sometimes it even terminates itself... is the most convoluted way. When your fighting your bro, and a brofist is mandatory. The AI is not prepared to fight flying robots. Ok, that was a decent punch. So it does not get too cocky. If you are interested in Posable Heroes, you can wishlist it on steam.
  34. 3 points
    It's entirely up to you. Lots of programmers enjoy the tinkering aspect that comes with starting low-level and building up their own set of routines, others like to see results as soon as possible and consider the coding to be more of a means to an end. And then there's the issue of whether you care about learning new skills while you do it, or whether that is just time wasted. My default recommendation is usually "Unity/C#", but if you are comfortable with Java and have had some decent results from LibGDX then you can certainly continue with that. In particular, working with larger engines like Unity (or Unreal, or similar) can often mean a period of readjustment for someone who is already a programmer, while they learn how to adjust their normal method of working into the way that the engine 'wants' you to work. That alone could be a good argument for sticking with LibGDX in the short term, at least while you get used to the fundamentals of game development.
  35. 3 points
    Hey everybody! Boy, it has been crazy since the last blog post! I've managed to get a coder onto the project and they are doing extremely awesome work. How awesome? Check it out! The first thing you'll notice is that the HUD has changed dramatically. A lot of it is still a work in progress but the layout is how we'd like for it to be in terms of where everything is. Also, 99% actually works now, from the magic bar, the spell selector, the item indicator and the health! (We're just missing the currency) Next is the combat, which we've started working on and most of the player functions are prototyped. Whilst the attack effect does need a little more polish, the player can attack and have the spell they have activated, push out from their fist. The first step to having a fully functioning combat system has been taken! Speaking of combat, the other systems have also been worked on! The player can dash in four directions when the button is held, keeping their direction when the button was held. As well as blocking, which stops them from moving but they can rotate around in a circle to block incoming attacks. This will make for some interesting battles for sure! On the non-combat side of things, we've gotten a few of the puzzle elements started, the first of which is picking up environmental objects! It's still in need of a bit of work, as you can see, but the player can pick up certain objects and throw them, with the impact having different effects depending on what we want them to. On top of that, we have pushing and pulling objects! This is still being worked on at the moment, as the collision detection is a bit buggy but we're making progress! Another aspect that has had work done is the dialogue system. Here, we can see the colored text aspect that we all know and love from Zelda games. We've worked on making a system inside Unity to allow importing of simple .txt files to make writing a lot easier for us down the road! In terms of general movement, we've added in swimming, which will inhibit players from attacking, so watch out for water-dwelling creatures! Whew! That was a lot to unload! Everything is still in need of a lot of work to tidy, debug and make the best we can for all of you to play in the future. Hope you all enjoy the update and I hope to hear from you all on what your thoughts on this is!
  36. 3 points
    Being approached with the task to create a ‘calming’ experience for LiminalVR users was juxtaposing because at first we were absolutely not calm with our approach to research and our aggressive surveys distributed over social media (Which by the way, feel free to take part in here and here). However, a week later the team had a meeting with LiminalVR and were given access to their concentrated psychology documentation which, to say the least, was a lighthouse in the fog of endless research. The research provided to us allowed us to decide on creating the natural setting that we wanted, with factors of detail such as colour and vegetation types that allow for a calming user experience (we hope!) The terrain itself was generated with World Machine, using a low resolution to ensure its cost remain low for mobile optimisation. The terrain, when translated across into Unity, had some scaling issues and as a result, the long rolling meadows that were seen in World Machine imported much smaller. To fix this issue we doubled the size of the terrain but as a result, we discovered that we had lost a lot of our ability to create finer details when painting textures. However, as this is essentially saving cost and the painted roads will be in the distance, we decided to push forward. Itween was used to create the curve in which the lantern follows, travelling at an increasing speed as it moves further from point A towards point B. The lantern model is still underway, however this will be one of the final features that will be implemented. On feedback we changed the initial idea from dusk to dawn and to really harness the colours of an early morning sunrise, we used optimised volumetric lighting beams to simulate the sun rising in the morning. It was extremely challenging to simulate atmospheric fog inside of Unity that is mobile optimised and after research we decided to create a cylinder to surround the terrain with a low alpha material on the inside which gives a low cost effect of fog. This encompassed with Unity’s inbuilt fog feature allowed to create a believable environment. User Input is required at the start of the experience, the player simply must use their head to turn and look at one of three pieces of paper that represent most how they are feeling, this is a feature that is currently being worked on in a test scene and will be migrated over to the experience on completion. Next up we will be working on polishing, grass, textures, finalising models and audio. Stay tuned and watch this space! Sincerely, Team Tuff Knight P.S - Follow us on Twitter for regular updates! @BraydenBeavis @MohamadAlRida
  37. 3 points
    You say that "you can't be 'just' a designer" - sure you can... for specific values of 'designer'. Saying that "you can't just be an idea guy. So I must take on either programming or art" is a false dichotomy. Here are some of the tasks that a designer might take on in a typical team, in my experience. Many teams will separate this out into multiple roles, so it's not necessary for anyone to have all of these skills, but these are what an actual designer might do, even if they don't get to be the idea guy. Broad character/vehicle/unit/species design 'Grey box' level concept design (artists replace the grey with real assets later) Level design by placing assets, or using a level editor tool Hook up animation assets to characters Write design documents for producers, artists, and programmers Choose input schemes and keybindings Implement character archetypes within an engine Create 'flavour' documentation or narrative to guide feature implementation Plan cutscenes Produce UI mockups for artists Consider UI/UX issues, accessibility and usability, plan a player's flow through the program, etc Perform competitor analysis on related products Create trivial game logic and events in Blueprints or Playmaker (yes! Playmaker!) Write pitch documents for game ideas Prioritise features and sub-features to guide producers and programmers Plan and design game systems (movement, camera control, character progression, encounters, AI) Design and balance game systems (via formulae in spreadsheets, simple scripts, etc) Balance game systems via testing and measuring Write narrative, dialogue, flavour text, or prose, and enter it into the engine Evaluate and refine monetisation approaches Create scripted events Set up quest definitions with objectives, conditions, etc Loads of other things With that out of the way, the other problem you face is that the route to a high-level design position is not generally obtained by being a programmer. For starters, studios often expect to hire designers for less money than they expect to hire programmers, so you'd be looking at a pay cut. Secondly, studios find it harder to recruit programmers than to recruit designers, so they will tend to be reluctant to let you move sideways internally. As such, I would strongly recommend that if your interest is design, to focus directly on being the best designer that you can be. Finally, I'd leave you with a warning to not get too focused on the problem of "bland and boring plots". There has been no shortage of people over the years who, as creators, want to see something deeper from games, but only really evaluate the stuff that is deliberately mass market. There are more interesting works available, just not when one is mostly focused on the obvious works (and, with all due respect, the games you mention are from a fairly narrow section of the field). There are trade-offs to be made when it comes to spending a lot of someone else's money on a AAA project, so if you want to work at that level, you have to be thinking about the mass appeal foremost.
  38. 3 points
    Hello everyone! Part 6 will be my final entry regarding the GameDev.net Challenge to complete a Pac-Man style game with a multiplayer component. Above you will see some screen shots, and a video of the game in action. I will also attach a copy for you to play. The requirements to complete this challenge are as follows: ------------------- Game Requirements 2+ player board - Choose one or more games modes - local multiplayer, networked multiplayer, and/or AI players Team play? Vs play? Both? You decide. The game must have: Start screen Player selection Score system for appropriate mode (winner in Vs mode or team total in Team mode) Sound effects Graphics representative and capturing the spirit of a Pac-man clone One or more levels Gameplay mechanics and mazes in the spirit of Pac-man - the game does not need to be an exact clone in graphics or gameplay, but it should demonstrate inspiration from Pac-man. The idea is to create multiplayer Pac-man gameplay. Art Requirements The game may be in 2D or 3D Players must be clearly identified Duration February 2, 2018 to March 31, 2018 (expires when all world timezones are April 1) ------------------- Background on what went into the creation of the game: I created a solo play feature to use as the foundation in order to easily transition into a multiplayer version. The two player split screen is a slightly modified version of the solo play mode, but with two split views, and independent sprites and movement for each robot. I also added shared lives, and the aliens will split up to chase you. The start screen has the two play modes - Solo, and Two Player. The score system is based on power orbs collected, and in Two Player mode all power orbs collected are collective for scoring. You will win the game by removing all power orbs from the map. You will lose if your lives hit 0. Solo play has 3 max lives, and Two Player has 4 shared lives. For the sound effects, I just added music which you can toggle, and a basic sound effect for power orb collection. The graphics are a bit different, but the Robot is the replacement of Pac-Man, the Aliens are the Ghosts, and the Power Orbs are the Pac-Dots, ect... There is only one level in this game to meet the requirement. On the programming side I had to setup a gliding based movement system that has a queue for smoother movement (same system as Pac-Man). How this works is that you will move in the direction you've pressed until you hit a wall. The queue works like so: If you're moving right and you will have a bottom opening coming up, you can just press down once and release, then your Robot will auto move down and continue moving in the downward direction. This allows smoother movement because you would have to always be holding the keys to get smooth movement prior to directional change unless you're 100% accurate on input due to movement bounding box at 96x96, and all tiles are at 96x96 giving the maze like feel. I did a bit of an edit for the sprite bounding boxes as I'm not using 96x96, but the pixel size of the graphic less the transparency. The 96x96 is just used to direct movement through the maze evenly. I also added in path finding for the aliens which is very optimized to reduce unnecessary checks. For the Ice Block, I just programmed a quick class to handle animations by loading in frames with a set time per frame. Beyond that, everything else is fairly standard for this 2D based maze game. The game itself was programmed in C++ using SFML, and openAL for audio. I had to program interpolation to smooth out the graphics as I use fixed time step with variable rendering. I created all the graphics in 3D then converted to 2D, and slightly touched them up. What I didn't get a chance to do, and would like to improve on: Sadly one of the biggest problems when working on this game was the lack of time I could commit. I missed the deadline for the prior GameDev.net challenge and really had to push myself to commit this project to completion. If I had more time I would improve on the graphics more, add in full animations to everything including directional movement. More sound and music. More levels. AI player mode. I also would have considered full 3D for this game. I really need to start these much earlier. What struggles did I have? The biggest struggle I had beyond time restrictions was a stupid issue with my openal32.dll file. I was including an older version, and not the one in the bin folder for the latest SFML release, so I had massive performance issues due to the wrong file. Took me a bit to figure out what was going on which all the threads exiting like wild fire, so I replaced the .dll file and problem solved. Final notes: Regardless of the all the issues I had, and changes I wanted to make, I really enjoyed making all the graphics, and programming the Pac-Man themed game. Even a simple looking game like this takes a lot of work, easy or not. I find it extremely rewarding just to complete the task itself as we all know making games isn't easy, and sticking to the game until the end is even more of a challenge. I recommend everyone take advantage of the GameDev.net challenges if possible. Game Download - Windows (32-bit) - Built on Windows 10 (Should work on Windows 7 - 10) rutin-gamedev-pacman-chall-gamebuild1.zip If you've missed any of the earlier parts, check below for the links:
  39. 3 points
    Asking about weaknesses is, in theory, trying to see if the candidate is capable of self-reflection, seeing if they can be humble, and if they can be honest about how their skills are distributed. If an interviewer accepts bullshit as an answer there, then they've not really thought the question through. When we interviewed technical directors, we asked this in a slightly different form: something like "which areas of expertise do you think you'll need to hire for, or research in depth, in order to deliver this project?" Nobody knows everything, and I don't want to hire someone who thinks that they do. When I was last doing mid to senior level programmer interviews, I did have the applicants look over a page or two of our code and asked them to suggest improvements. It wasn't about playing spot the bug but it was about assessing their approach to code quality, and also their approach to communicating with team members.
  40. 3 points
    Generally that is easy to test because hopefully the legacy code actually compiles and you can debug through it in some manner. Why do we have 2 singletons? Is the issue that the large things take along time to collate? Are we worried about how they are constructed because you are (Assuming the compiler errors are just typos) calling getInstance in each-others constructors? Are the typos\compiler errors supposed to be tricking me up or apart of the exercise? How did I get to looking at this code? Did I notice something odd? Bug report filed? Randomly browsing? Again, I think this exercise does not help at all. Generally you are working with actual code or responding to some behavior in context.
  41. 3 points
    As I have experience in more - Unity (and other game engines) and custom game engines - I can clearly state that any non-custom engine is restrictive at some point. You can clearly figure it out by attempting to add some specific feature in Unity (Such examples being as small as adding Voxel Global Illumination - and I know there is an implementation around, but it is extremely limited ... compared to custom engine implementation). Yes there is a way to work around, but it often takes multiple headaches with Unity ... or as big as large terrain rendering). In the end it all gets down to: Do you have resources to produce and maintain custom game engine? This often means spending hours and hours weekly on engine. Including (for some people) very annoying parts where you work with internals - which isn't really visually rewarding in any way. What advantages will custom game engine give to you? This is not necessarily saving money (because it will most likely get far more expensive than using already built engine). But do you require specific features and high performance? Then custom engine may be something for you. What are your time options? If you're in a hurry (doing a game jam, or such), custom engine can provide large disadvantages due to missing features. While Unity or others might already have those ready made. Simply because they are far bigger projects. An example can be F.e. this: This is my engine in action - PBR rendering, Voxel Global Illumination re-calculated every frame (therefore noise), MSAA and deferred shading (multiple lights), Virtual shadow mapping, Physics, Dynamic cone-traced reflections, Instancing, etc. etc. (A very long and exhausting list of features). All this is recorded in editor (UI is fairly simple through ImGui but it is enough for the purpose I need). Average framerate is over 60 fps (with recording on ... and 4x MSAA for every single buffer up to resolve AFTER tone mapping - hence huge bandwidth usage). Average CPU usage with the physics is well under 5% (whole engine is multi-threaded, and uses all 8 cores of Ryzen CPU on which I've ran this). So why am I describing all this? Compare with this - https://ldjam.com/events/ludum-dare/38/run-u-fool - and I recommend, try both - WebGL and Desktop builds. Shattering objects can't be activated at once (due to performance reasons), there is far less graphics effects and far less actual logic for CPU (it runs as a runtime, not as an editor). It is not just the performance difference, but also GI and other features which are hard (if not impossible) to achieve with Unity. Yet can be well optimized in your custom game engine.
  42. 3 points
    Greetings, In this devlog I want to show you how the combat with a boss will look like. You appear in a large room with a weird contraption in the middle of it. This contraption is a boss who attacks you immediately. There are several platforms around, where smaller enemies appear time by time. Also you can find some places with replenishments for health and ammo. You need to move a lot to dodge the boss's ammo and shoot the smaller enemies which chase you. And of course the main action is shooting at the boss which has a lot of health. The video in toxic display mode is here:
  43. 3 points
    You should add a table with cards, and split the problem in four steps: while not done: # Get input from the player, or "no input" if the player doesn't do anything within a short time interval. # Typically interval is somewhere between 1/60th to 1/30th of a second, the animation frame rate. inp = receive_input() # Process any input from the user, and update the cards on the table accordingly. # Note this are only logical game actions, like 'take card', or 'deal' or so. table.process_input(inp) # Cards are animated, so update the position for any card that is flying. table.update_card_positions() # And finally, render the table as it is. table.render() The table is the central data structure that knows where each card is. It can also hold the state of the game. If the game gets complicated, you may want to take that into a new class. The above loop runs at animation frame rate. Input processing obviously doesn't do anything if the user doesn't give a command. Animation moves each card that is not where it should be a little. Rendering then just draws the entire table. Attach an entity to the card (or give the card an index number pointing to the entity to draw). Your blunt "pos += vel" position update may fail (not to mention you update x twice, and y never). As an example, suppose vel =2, pos = 1, dest = 6. Position will update like 1, 3, 5, 7, 9, ... since pos is never dest. Instead, just update to the final destination when the card is "close enough" (less than 'vel' away, for example).
  44. 3 points
    Can you tell us the big picture of what you're trying to implement? You could bind your texture as a UAV instead of RTV if you want to be able to write into the whole thing arbitrarily. Btw, as mentioned above, you really should get the debug / validation layer working. Invalid use of the D3D12 API is undefined behaviour and can do nasty things -- e.g. It might work fine on your PC but crash the GPU on someone else's PC. The Validation layer catches the vast majority of mistakes and provides extremely helpful human-readable descriptions of the errors. I would go as far as to say that it is mandatory for development.
  45. 3 points
    We'll update this list as we become aware of more presentations. You can also submit links to presentations. Design Gameplay Setbacks As a Tool for Creating Impactful Moments - Scott Brodie (Heart Shaped Games) Rules of the Game: Five Further Techniques from Rather Clever Designers Game Design Patterns for Designing Friendships - Daniel Cook (Spryfox, Lostgarden) Playtesting VR - Shawn Patton (Schell Games) Ultimate Online at 20: Classic Game Postmortem - Raph Koster, Starr Long, Richard Garriott de Cayeux, and Rich Vogel Production All the Families: The Making of Animation Throwdown - Peter Eykemans, Katrina Wolfe (Kongregate) Going Cross-platform: Is It Worth the Effort? - Tammy Levy (Kongregate) Marketing Judo: Leverage Your Time, Sell Your Game - Sam Coster (Butterscotch Shenanigans) Producer Bootcamp: Be the Best Producer for Your Team - Ruth Tomandl (Oculus Research) Remote Unity Studio in a Box – Ben Throop (Frame Interactive) Rules of the Game: Five Further Techniques from Rather Clever Designers - Richard Rouse III Shipping Call of Duty at Infinity Ward - Paul Haile (Infinity Ward) Programming Advanced Graphics Techniques Tutorial: The Latest Graphics Technology in Remedy’s Northlight Engine – Tatu Aalto (Remedy Entertainment) Beyond Emitters: Shader and Surface Driven GPU Particle FX Techniques – Christina Coffin Circular Separable Convolution Depth of Field - Kleber Garcia (Electronic Arts) Cloth Self Collision with Predictive Contacts – Chris Lewin (Electronic Arts) Conemarching in VR: Developing a Fractal Experience at 90 FPS - Johannes Saam, Mariano Merchante (Framestore) Creativity of Rules and Patterns: Designing Procedural Systems - Anastasia Opara Democratizing Data-Oriented Design: A Data Oriented Approach to Using Component Systems - Mike Acton (Unity) Epic Presentations Building High End Gameplay Effects with Blueprints - Chris Murphy Cinematic Lighting in Unreal Engine Optimizing UE4 for Fortnite: Battle Royale: Part 1 Optimizing UE4 for Fortnite: Battle Royale: Part 2 Programmable VFX with Unreal Engine’s Niagara Creating Believable Characters in Unreal Engine GPU-Based Clay Simulation and Ray-Tracing Tech in ‘Claybook' – Sebastian Aaltonen (Second Order) Khronos Group Presentations WebGL and Why You Should Target It Standardizing all the Realitites: A Look at OpenXR Linear Algebra Upgraded - Eric Lengyel (Terathon Software) Real-Time Ray-Tracing Techniques for Integration into Existing Renderers - Takahiro Harada (AMD) Rendering Technology in 'Agents of Mayhem' - Scott Kircher (Volition) Shiny Pixels and Beyond: Real-Time Raytracing at SEED – Johan Andersson, Colin Barre-Brisebois (Electronic Arts) Spline Based Procedural Modeling in 'Agents of Mayhem' - Chris Helvig, Chris Dubois (Volition) Terrain Rendering in 'Far Cry 5' - Jeremy Moore (Ubisoft) The Asset Build System of ‘Far Cry 5′ – Remi Quenin (Ubisoft Montreal) Tools Tutorial Day: Shipping ‘Call of Duty' – Paul Haile (Infinity Ward) Visual Arts Capturing Great Footage For Game Trailers – Derek Lieu Independent Game Summit Building Games That can be Understood at a Glance – Zach Gage Porting Games to Consoles (Youtube) - Thomas O'Connor (PlayEveryWare) User Experience Summit UI/UX of Creating Your Mobile Game in VR - Miranda Marquez (MunkyFun) Immersing a Creative World into a Usable UI - Steph Chow (Steph Chow Design) Game Narrative Summit The Nature of Order in Game Narrative - Jesse Schell (Schell Games) Other Content Houdini Foundations - SideFX The Transvoxel Algorithm (poster download) - Eric Lengyel
  46. 3 points
    Out of memory is a different error code, unless you were asking a size above the DirectX limits. With D3D12, you should run most of the time with the debug layer and solve any issue as soon as possible, it is life saving ! It is as simple as installing the graphic tools ( start menu > optional feature > graphic tools ), then in your application, at the begining, call D3D12GetDebugInterface and enable the layer from the returned interface. If you never did it, even if you are at the hello world triangle stage, chance you have dozens of errors and warning are pretty high. And consider that the layer is not a magical tool and many errors are not catch either !
  47. 3 points
    Hi. Don't fear, pixels are less important than you think. In truth you only ever need to worry about pixels when they produce less than desired results. No surprize here because it does not exist. There is no defined relationship between pixels and Units. It's up to YOU to decide what relationship they will have. Often it's easy to work with 1:1, 1:10, 1:100. Meaning that 1 Unity unity = a 100 pixels; this should be the default. The above image shows my button at 150 by 50 sprites. However I want each Unit to be 50 pixels large. So how do I set that? Simple. I select the image, then in the inspector I select what Pixel per unit I want. OK. Notice how things got blurry? That is because my game isn't pixel perfect. For most art styles this doesn't matter but let's fix this. The 800 by 600(4:3) ratio you are using has a problem. That is the 3 on the X axis is a odd number. Here we can see it is out by exactly 1/3. Because the computer is limited it can't solve 1/3. To fix this we scale the camera's Orthographic option to a base of 3. 3,6,9,12 etc. The above image shows how the problem is solved by setting the Orthographic to 3. Now My Units, camera and pixels all line up. In short: if one of your axis is a problem then use a power of that axis to correct the size of the camera. This lines everything up.
  48. 3 points
    Denoising isn't part of DXR. Those denoising algorithms have been published previously too - AI denoising has been around for a few years, and NV #hyped their version of it last year Read the DXR manual to see the new HW features they're pushing for, not the #hype/#fail articles/videos written by other people to lazy to read the manual. I posted a summary on the first page: There's a lot of HW changes coming to compute-core scheduling, bindless shader programs, compute coroutines and very fine grained indirect dispatching -- all things that renderers based around recursive ray generation system will need to perform well (and without CPU intervention). Offline/film renderers haven't needed these advancements yet because the millisecond-latency issues of CPU based workload scheduling don't affect them. For realtime we're going to need the GPU to be able to feed itself though. Ray-geometry intersections can be defined with HLSL "intersection shaders", so there's no specific HW required for that, but they also define a fixed-function ray-vs-triangle mode, which does allow GPU vendors to bake that into silicon if they like. I don't know if that's worthwhile, but it's worth noting that even after all the advancements in general-purpose GPU compute hardware, every GPU still has fixed-function HW for texture filtering, rasterization, depth-testing and ROPs, so ray intersection may have a place there.
  49. 3 points
    Your original code: void phongLighting (float3 normal, float3 lightDirection, float3 viewDirection, float specularPower, out float3 diffuseReflection, out float3 specularReflection) { // phong diffuse reflection term = (N.L) diffuseReflection = dot(normal, lightDirection); // reflection vector = 2*(N.L)*N-L float3 reflection = 2*(diffuseReflection)*normal-lightDirection; // phong specular reflection term = (V.R)^S specularReflection = pow((dot(viewDirection,reflection)),specularPower); } My recommendation: If you just translate the above formulas: float3 phongLighting(float3 n, // The normalized surface normal vector. float3 l, // The normalized direction from the surface point to the light source (i.e. constant for directional lights) float3 v, // The normalized direction from the surface point to the eye. float3 Kd, // The diffuse reflection coefficient of the surface material. float3 Ks, // The specular reflection coefficient of the surface material. float Ns, // The specular exponent of the surface material. float3 E_directional // The irradiance of the directional light source. ) { const float3 r = reflect(-l, n); // Calculate the reflection vector using HLSL intrinsics. const float n_dot_l = saturate(dot(n, l)); // Note the saturate! const float v_dot_r = saturate(dot(v, r)); // Note the saturate again! const float3 diffuse = Kd * g_inv_pi; // Evaluate the diffuse part of the Phong BRDF. const float3 specular = Ks * g_inv_pi * pow(v_dot_r, Ns); // Evaluate the specular part of the Phong BRDF. const float3 brdf = diffuse + specular; // Evaluate the complete Phong BRDF. const float3 radiance = brdf * E_directional * n_dot_l; // Combine the BRDF and the irradiance. return radiance; } You can use a value of 1.0f for Kd and Ks (since your code does not use such values at all). Apart from this, as already mentioned a few times, your code is missing all the saturates (i.e. clamps). Not doing this can be problematic, since HLSL's pow does not handle negative values as expected. Since, the barycentric interpolation of vertex attributes inside the Rasterizer Stage, does not preserve normalized vectors (consider what happens when you have barycentric coordinates of 1/3, 1/3, 1/3 and vertex attributes (1,0,0), (0,1,0), (0,0,1)), you should normalize in the Pixel Shader. Furthermore, if you support non-uniform scaling, then you use a wrong transformation for your surface normal inside your vertex shader. The formulas also work for directional/distant lights and are even trivial as one can directly store a constant irradiance value for such a light source type. For point lights (omni, spot, etc.), it would be a bit more tricky, since you cannot store a constant irradiance value.
  50. 3 points
    You're far too aggressive. You came to this forum to get opinions, so we're giving them. Whether you agree or not is irrelevant, but have the courtesy to treat us with respect. To me, there are some fundamental flaws with your idea, but it isn't impossible: 1. What you have described so far is player-driven lore. Not game mechanics, which is where player retention will be. When you open up an MMO, are you there because the story is interesting? No, that's just a bonus (a very rare bonus). You're there because the game mechanics are fun. You'll go pick up a book if all you want is a good story. The idea of the player driving the lore of the game is 'interesting' but not inherently 'fun'. Not to mention that if you did implement such a feature, players would want it two-fold: player-driven lore and mechanics. Which is a bit of a bastard to build, but rare enough that you have a high chance of people being interested in it (with, again, the bare minimum that the player-driven mechanics is fun). 2. You're making the game change genres in different stages of its progress. People who want to play an RTS aren't looking for an RPG, and vice versa. Your promise to the RTS players who get through the first stage is 'you can now play an RPG'. How would that interest them? Perhaps you can advertise a model where you separate the two types of players. The RTS fans will shape the world and when they're finished, the RPG fans can come in and enjoy it. However, this does make gathering enough players harder, and the marketing more confusing. 3. No-one wants to pay any money for the 'limited' version of a game (a single payment/subscription base would work much better), especially if it isn't backed by a respected company or approved developer. There are so many well crafted, complete multiplayer games that are drafted and failing because they didn't get enough player retention (either through bad marketing or bad luck). You need to be sure that your game isn't too niche to fall flat. Unlike other games, your game needs to be populated at its beginning otherwise the rest of it will spiral into oblivion. This is much harder then other types of design models. I'm not saying you can't make this game, or it won't be successful. All I'm saying is it is a massive time investment, a very niche market, and the only way it will succeed is if you provide quality player-driven mechanics alongside your player-driven lore. A follow up thought for this is to have your game be time-limited, and have the server start again every say 6-12 months. This would let new people experience the entirety of the game, and let old players implement new ideas and theories in the next iteration. Then you can have a progression system outside of a single 'game', and implement new mechanics over time.
  • Advertisement