The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation since 05/28/17 in all areas

  1. 18 points
    On June 15, 1999 - 18 years ago today - our band of developers and "webmasters" launched GameDev.net. Here's the story:[quote] GameDev.net has a rather interesting history. Starting from a conversation between Dave Astle of Sweet.Oblivion and Mike Tanczos of Game Programming 99, the idea to join forces of the largest game development sites in the world was forged. At first we thought small, deciding to create a simple resource page which would merely link to each other's prime material. But after contacting John Munsch of DevGames, the possibilities were blown into the stratosphere. Not wanting to create a mere portal page, Munsch insisted that our sites join forces to create one large site. Discussion between the people behind the sites began, quickly leading to an agreement to launch a game development site which would come to make even so-called 'mega-sites' look small. Realizing the potential of an existing Affiliate group created by Michael Tanczos, which consisted of the three previous sites and the Game Development Search Engine, Wotsit's Format, and Demonews, discussion further escalated to include those sites. This resulted in an agreement on varying levels between all the sites to assist each other in the creation of the new site, which we dubbed "GameDev.net". The domain was snatched up, and design and layout discussions began in early April. By the beginning of May, development on the site would begin at a feverish pace. Slating our original launch at June 1st, we realized that an effort of this magnitude would be impossible to achieve in that short of a time. GameDev.net would undergo many changes over the next few years. We soon added several major sites to our family as hostees, including NeHe Productions and Wotsit's File Formats. As the years have progressed, GameDev.net has continued to grow and evolve into the site you see today.[/quote] You can see what we looked like at the Web Archive, but here's a screenshot of an early version of the site: What you may not know is that none of us met each other in person until several years later. We have always been and remain a virtual team - although at the moment it's just myself and the Moderators. Team meetings were held over Internet Relay Chat, or "IRC" for the kids, and we'd communicate over ICQ, which amazingly still exists (although I've had comments saying the same to me about GameDev.net.. 18 is old in Internet years). To give some perspective, 18 years ago Unreal was starting to form the concept of a game engine and entering a battle with Quake. Unity was a dream. The GPU as we now know it did not exist commercially (we broke NVIDIA's GeForce news). And shortly after our launch a particularly large search engine contacted us to see if they could be our search engine, as I'll share in this team meeting chat log from July 18, 1999 - a month after we launched.[quote] [color=rgb(29,33,41)][font=Helvetica] I have another thing to mention[/font][/color] [color=rgb(29,33,41)][font=Helvetica] [/font][/color]Google.com[color=rgb(29,33,41)][font=Helvetica] wants to do our search[/font][/color] [color=rgb(29,33,41)][font=Helvetica] ?!?[/font][/color] [color=rgb(29,33,41)][font=Helvetica] They contacted us?[/font][/color] [color=rgb(29,33,41)][font=Helvetica] who's google[/font][/color] [color=rgb(29,33,41)][font=Helvetica] They want to be our search engine for the site[/font][/color] [color=rgb(29,33,41)][font=Helvetica] k - a search engine, like AltaVista, but nicer in some ways[/font][/color] [color=rgb(29,33,41)][font=Helvetica] mike - how do you feel about it?[/font][/color] [color=rgb(29,33,41)][font=Helvetica] Well.. their results are unique[/font][/color] [color=rgb(29,33,41)][font=Helvetica] They are a very impressive search engine (more a technology than anything else). They are going to IPO or just did, I can't remember.[/font][/color] [color=rgb(29,33,41)][font=Helvetica] wow, i've never heard of them [/font][/color] [color=rgb(29,33,41)][font=Helvetica] We'd have a search page at [/font][/color]www.google.com/gamedev [color=rgb(29,33,41)][font=Helvetica] will they go down/work slow, etc?[/font][/color] [color=rgb(29,33,41)][font=Helvetica] No idea.[/font][/color] [color=rgb(29,33,41)][font=Helvetica] I can speak to the last one, they are expected to get a sh*tload of money, so their servers will likely be fast.[/font][/color] [color=rgb(29,33,41)][font=Helvetica] you think itd be better than our own deal?[/font][/color] [color=rgb(29,33,41)][font=Helvetica] didnt you do a kick ass search engine mike?[/font][/color] [color=rgb(29,33,41)][font=Helvetica] Yeah, it works pretty fast.[/font][/color][/quote] I can proudly say that I learned more than I need to know about Google. GameDev.net started as a labor of love, and 18 years later it continues to be a labor of love. While I remain as the only founding member, I know that the founders who are no longer with the site hope it continues to provide value for the game development community to learn, share, and connect with others for many years to come. But the amazing thing to all of us continues to be the community. I may be biased, but for 18 years I have not come across a better community than the GameDev.net Community. We are a passionate, knowledgeable bunch, and we love discussing, sharing, and learning from others about the problems, technologies, and challenges of game development and the games industry. Throughout GameDev.net's history we've watched so many of you grow into the games industry, often starting as hobbyist or student developers with a thirst and desire to achieve your dreams. It's been our greatest pleasure to provide the platform that has helped so many, and we love to learn about your own journeys in the industry. In the meantime I want to thank the amazing GameDev.net community, again, for these 18 years. On to the 19th! p.s. The site upgrade is happening this weekend, finally! Stay tuned.
  2. 12 points
    1) The article you're referring to was D3D9 vs OpenGL 2.x... and it was not a benchmark. People who report those numbers as if they're benchmark results are grasping as straws, or don't know anything about profiling code... 2) They're the same. 3) They're the same. 4) Win95 and WinNT both had their own graphics teams - one backed GL and one made their own API, and neither shared, so Windows ended up with both! OpenGL dropped the ball with 2.x and D3D10/11 won the API war, it's just hands down better :P Don't let GL's "portability" argument fool you. NVidia's driver, AMD's driver and Intel's driver all provide the same GL API, but their implementations are completely different. Unless you thourougly test your code, you can't be sure that it will even run on a different GPU, let alone a different operating system!! Things get far worse in mobile land, where there's hundreds of different phone manufacturers using different drivers / implementations. 5) No, if anything, GL has more features because each GPU maker can add whatever new features that they like (but these features may only work on certains GPU's/drivers). Everyone uses D3D11 because it's a simpler API, runs faster, and way more stable across different kinds of hardware (better hardware portability!). 6) Here's a table of different "feature levels" in D3D11, which corresponds to different hardware capabilities ("d3d11 capable", "d3d10 capable", etc): https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
  3. 11 points
  4. 10 points
    It's been a little bit of an art push lately. First of all, I started work on a dungeon tile set. Up there is my first stab at it. I created a couple different wall variations, a door and a hex-pattern tile ground texture (used in conjunction with existing sand and gravel textures). Don't have anything in the way of doodads or decorations yet. Doors are still kinda tricky. I had a conversation with riuthamus about it. The gist of doors in this game is that a door needs to work with any configuration of walls around it, so trying to do artwork for a traditional-looking door and choosing alternates to match up with the surrounding walls was getting to be too difficult. I had already implemented doors some time ago that utilize portcullis-like behavior: when you open the door, it slides into the ground. Closing it brings it back up again. The door in the above shot works the same. The issue lies in creating a graphic that looks door-like, even though it doesn't look like a traditional door. I'm not sure there's a perfect solution for it. But at least when you hover over a door, a popup appears with the label 'Door'. Hopefully that's enough of a clue for people to figure it out. I've also started experimenting with MakeHuman. The ogre in this shot is a result of that experiment: It was a quick effort. I just used some of the clothes provided with MakeHuman (hence the jeans and button-up shirt, articles of clothing that would be quite difficult to obtain in the Goblinson Crusoe universe) and ran some of the various sliders for the mesh deformation all the way to 11 to try to get an ogre-ish form. The experiment worked pretty well, I think, certainly well enough to warrant further experimentation. As a bonus, MH will export a skeleton rig to fit the mesh, though I still have to rig it with IK and animate. As it turns out, I'm still terrible at animating. Who knew? I spent some more time doing miscellaneous cleanup. Fixed a bug that caused creatures to die multiple times if they died in a round with multiple dots on them. (They would die once for each dot because I wasn't checking for isdead in between dot applications.) Formalized the construction of summoning spells, so that a flashy spell effect is played when things are summoned. Added some flashy effects for things dying. Moved and rearranged some data tables again. You know, crazy shit like that.
  5. 10 points
    Game rules are specifically excluded from copyright - they can't be protected. Specific implementations of algorithms can be patented, but this doesn't really allow you to protect game ideas. Design-patents allow you to protect the look of a product, such as the shape of a coke bottle or the UI layout of Tetris... Patents are also horribly expensive, need to be written by expert lawyers (again horribly expensive) and if anyone violates your patents, you'll need to wage legal war against them (sue) which is again, horribly expensive. No one bothers with that stuff in the games industry. The extent to which your ideas can be protected is not worth the cost of that protection. As for trying to sell it, nobody buys ideas. Most people wont even let you pitch an idea to buy as (1) It's a waste of their time and (2) it opens them up to legal liability - if they're already working on a similar idea, you'll complain that they've stolen it from you. The real value is in the implementation of ideas, not the idea itself. Ideas are only a starting point of a very long an expensive journey. Game designers do not just write down an idea and then go home for a year while it's created for them. Game designer is a full-time job for the entire duration of a project - constantly guiding the development team and refining the idea as implementation of it exposes rough edges that could not have been predicted at the start. Companies don't buy ideas, or hire idea-people, they hire designers. The exception is is you have an idea and lots of money. In that case you can hire a studio of designers and developers and give them your idea... If you don't have money, you could take the idea to investors first, to convince them to give you the money... But you will need way more than an idea - you'll need an entire business plan and enough business acumen to put a realistic value on your company (which has nothing but a valueless idea and no ability to execute it,a very risky investment). You can try and do the kickstarter thing, but it's the same deal - just an idea and no ability to execute does not inspire confidence... Plus you'd have to disclose the idea. Alternatively if you want to extract some value from it, you can just go ahead and start refining the idea further in public (on forums, blogs, etc). In the unlikely event that someone steals your idea, at least you'll be known as the inventor / first person to publish the idea,which, if it actually is revolutionary, is a great thing for a future career as a designer. Chances are that no one will steal it though as everyone has way more ideas already than they have the time/money to create
  6. 9 points
    I have to respectfully disagree here. Every device with a GPU supports OpenGL. DX is only supported on Windows and XBox. OpenGL wins portability by a country mile. Most big games ship for XBox, Windows and Playstation - D3D works on two of those and GL works on just one :lol: A FOSS developer might support Windows, MacOS and Linux, in which case GL is a must :wink: Different developers will find GL mandatory or useless. You'll find a few blogs on the net that say that the Wii or the PS3, etc, support GL, or I've even seen one that said that the PS4 supports D3D... They don't. Consoles almost always have a custom API designed specifically for them. The argument I was making though wasnt about OS/Platform compatibility, but hardware compatibility. OpenGL is just a text document, not a library. AMD, NVidia, Intel, etc all create libraries that (hopefully) behave according to that official text document. Any non-trivial game will discover that this isn't true, and wil have to debug their game on three desktop GPUs to ensure that it's actually portable. The situation is much worse for mobile developers, who usually have a library of dozens of devices plugged into a CI server in order to continually test their game on as much hardware as possible. Even if two different phones use the same GPU, they will often use different GL libraries if they come from different manufacturers :o Writing GL|ES code for a broad range of mobile devices is hell. That's why you have to beware of GL's portability argument -- the spec is portable in theory, but in practice every implementation of the spec has a few unique behaviors. D3D wins hardware portability by a country mile, while GL / GL|ES / WebGL together have massive platform portability. D3D solves this by having a single implementation of the core that runs on all hardware, and then they actually test/validate/certify implementations of the HW specific parts. GL's central body doesn't do anything to keep their driver authors in line like this. If Khronos actually did the same thing as MS here, then GL could be king. Maybe with Vulkan they'll take a few steps forward this time... So, while D3D only works on Windows, it works exactly the same on NV/AMD/Intel... Whereas in GL it's all too easy to accidentally make a game that only works on NVidia hardware... Personally for stability and ease of development, I would use Metal on Mac/iOS, D3D on Windows and console-APIs on consoles, which leaves GL for Linux, GL|ES for Android, and WebGL for web... and those are the three platforms that gamedevs hate to support :lol: Another concern for console developers is that the Xbox and Playstation shading languages are very close to Windows HLSL (close enough that you can hide them with a few defines). We've managed to compile a massive shader codebase for Windows D3D9, Windows D3D11, Xbox360, XboxOne, PS3 and PS4... But compiling it for GL would've meant rewriting it, or using a HLSL->GLSL translator. The business people's projected sales for Windows were low enough for us to have to push really hard to get them to even release a Steam version, and Mac/Linux projections were like 1% of Windows sales so there's no way they were going to let us do a GL port :lol: Vulkan is also a step forward here, as I'm going to be able to simply compile my HLSL code-base to SPIR-V.
  7. 9 points
    There is std::this_thread::sleep_for() and std::this_thread::sleep_until().
  8. 9 points
    1. Unity uses C#, so there are a lot of game developers that use it. There is no equivalent for Java. 2. C# has a gamedev pedigree dating back 10 years, to XNA and Monogame. The Java game development community did not have any library as widely accepted as those. 3. C# has a popular open source implementation (Mono) so people don't feel locked in to a specific runtime. Java also has alternative implementations available but Oracle have been known to take action against companies that implement their standard library so this tends to have a chilling effect.
  9. 9 points
    As you've pointed out, on any recent hardware/API there's nothing stopping you from doing fully programmable vertex fetch. There's 3 things you should keep in mind though: The performance between programmable and fixed-function vertex fetch may not be the same. There's still GPU's out there that have dedicated hardware for vertex fetch, and using it could possibly be the fastest path depending on what you're doing. On the other hand, some hardware (for instance anything made by AMD in the last 7 years) has no dedicated vertex fetch, and will generate shader code that implements your input layout. But even then there can be differences depending on what types of resources you fetch your data from (structured buffer vs. formatted buffer vs. textures), and your data layout (AoS vs. SoA). For an example, here's what happened when someone benchmarked a bunch of different ways to fetch vertex data on their GTX 970. GPU's will typically tie their post-VS cache to indices from an index buffer, so you'll still need to use a dedicated index buffer to benefit from it. You may want to look through this thread for some ideas on how to do interesting things within the limitations of standard index buffers. Input layouts let you have some decoupling between your vertex buffer layout and your actual vertex shader, which can be convenient in some cases. However it's possible that different input layouts will cause the driver to generate different permutations of your VS (or different VS preludes) behind the scenes.
  10. 8 points
    PS4s contain a GPU, but doesn't support OpenGL natively.
  11. 8 points
    This has obviously stopped being productive. JohnnyCode, language is important. Programmers of all people tend to rely on exactness and unambiguous terminology to communicate, because we typically have to include very simple-minded computers in our communications. The terminology you are using is "incorrect" and obviously this is vexing to people because your definition of "reference" is not the generally agreed-upon definition. We have those agreements for a reason, and it's to prevent confusion. When you insist on using an atypical definition for such a ubiquitous word, you're just promoting confusion and arguments. Now let's stop harping on this and go write some games.
  12. 8 points
    So, lately I've been working on the DoTs/HoTs mentioned in the previous entry, as well as the framework for ground effects: ignited ground, lava, etc... And in the process I have yet again stumbled upon exactly how weird a turn-based game really is; or, at least, one done in the manner in which I am making this one. Here's the setup: Goblinson Crusoe is built on an Action Points-based turn system. A Turn consists of 10 Rounds. Each Turn, all entities that want to act are gathered into a list, then each are given an opportunity to act for 10 Rounds. Moving, casting spells, attacking, harvesting loot, etc... these all consume Action Points until all points are used up, or until the unit chooses to end its turn early, at which point the next unit in line is given the chance to act. When all units have acted, the next Turn is started. So, while the units perform their actions consecutively, the abstraction is that these actions are ostensibly happening "at the same time". That's the weirdness of a turn-based game. You take a turn, then I take a turn, but it's supposed to be like these turns happen all at the same time. The abstraction really breaks down upon analysis, and there's really no way to make it better outside of moving it to a real-time simulation. One way that this flawed abstraction bit me in the ass is with these DoTs/HoTs and ground effects. You see, in this system, time only really passes for a unit if that unit actually acts during a Turn. For example, control passes to the player who moves 10 hexes. That's 10 rounds worth of time, and at each step an event is fired to indicate a round has passed. DoTs, HoTs and time-based ground effects wait for these events in order to know when to do their thing. After all, you can't have an over-time effect without the "over time" part. The problem I ran into is that while mobs such as enemies, GC, GC's minions, etc... are all active, acting objects, some things that otherwise can take damage are not. Things such as walls and doors, which have no active combat capability. They block tiles until destroyed, that's it. And the weirdness that resulted is that these units were effectively immune to DoTs. No time passed for them, so no ticks of damage were ever applied. That's not what I wanted. I mean, obviously, a burn effect should burn a wooden door down. It took a little bit of figuring to come up with a workaround that didn't completely break the system. The workaround is that walls and doors and such ARE active objects, but they have a different aggro component and an ai controller that does only one thing: ends its turn. The normal aggro component collects damage events and tracks them according to various damage sources, and if any damage was taken or any proximity events occurred, it signals that the unit is ready and willing to act that Turn. The fortification aggro component, however, only tracks DoT/HoT and ground effect events. If any of those are applied to the unit, then the unit wants to act. If they all expire, then the unit no longer wants to act. In the case of fortifications, "acting" means to simply end it's turn without doing anything. End Turn will cancel out any remaining Action Points, add them up, and send off a Time Passed event for the amount remaining, meaning that an entire 10 Rounds worth of time will be sent for the unit at once. The result is that if any fortification is hit for periodic damage in a Turn, then the camera will pan briefly to that unit while the damage numbers tick off, then will move on. It doesn't really feel optimal, but I guess it's about the best I can do. The turn-based system in GC is fairly zippy, and simulation speed can be increased if desired, but it's still not great that the player has to spend some few seconds of a combat Turn watching DoTs hit all of the walls engulfed by the last Inferno spell he cast. But still, it seems to work okay. It's always nice when I get these relatively large, relatively unbroken blocks of time in which to get things done. And it's always sad when they come to an end. Night shifts at work start tonight, and I'm working some extra days in the next couple weeks, so this thing'll probably be put back on the back burner once again. :(
  13. 7 points
    Born from a passion to have a quality farming game on the PC, we bring you "Valley of Crescent Mountain". However, why stop with farming when you can add espionage to the mix, throw in some magic and perhaps a dastardly deed or two and what you have is our game! As a newly graduated Spy, you have been dispatched into the world to make a difference and benefit the kingdom. Your first post is to the north near a neutral town settled deep within Crescent Valley. The village is in the middle of the only mountain pass between your kingdom and the neighboring nation. A small plot of land has been purchased on your behalf for you to establish your deep cover identity as a new farmer to the area. Your mission is to engage with the locals, watch for incursions by the opposing kingdom, sway opinions to your advantage and find new opportunities to push your country's agenda. Amidst all of this, unsettling signs of darkness are making themselves known. WHERE CAN I FIND OUT MORE ABOUT THE GAME? FACEBOOK: https://www.facebook.com/vocmain/ TWITCH: https://twitch.tv/riuthamus YOUTUBE: https://www.youtube.com/user/riuthamus TWITTER: https://twitter.com/riuthamus INDIEDB: http://www.indiedb.com/games/vocm WHAT IS THIS GAME ABOUT? Inspired by previous games such as "Neverwinter Nights", "Harvest Moon", and "Witcher", we wanted to bring a game to life that did justice to the Farming genre and its RPG elements. This is where our game comes in. We are putting a heavy focus on roleplaying events that will define and change how you play the game. Add a unique starting point for the storyline and you have what I call "winner winner, chicken dinner!". Speaking of chickens: WHAT ARE SOME THINGS WE CAN DO IN THE GAME? FARMING: In our game you will be farming on a grid. This grid based system will notify you via visual cue on the status of your crops and the tiled land. Everything from water saturation level to plantable tilled land. If you want to know the status of every tilegrid on your entire farm you can press q and it will quickly show you the status of all tiles on the farm you own. Want to go back to less information, just press the tab key again and it will all be removed and brought back to normal. You will gather seeds from quests, events, the world, and from other plants. Use these seeds on the tilled land to start creating the birth place for your plants. Once your crops have been brought to adulthood you can harvest them. If you are unhappy with the crop you can throw it away, or if it fits your needs you can store it in your backpack.
  14. 7 points
    It's been a busy few days. We upgraded the GameDev.net software and servers this weekend, and while there are plenty of problems to still fix the whole process has exceeded expectations. What's new? Quite a bit is new, actually. It wasn't just a software and server move. It was also an opportunity to change a few things. Here's a list of the big changes. Article and Forum Category Changes We merged quite a few of the article and forum categories, which now better align. If you remember, we had top-level categories of Technical, Creative, and Business. These were fine 18 years ago but the taxonomy of game development has changed a bit. These are the changes: Top-level categories are now: Programming, Visual Arts, Business, Audio, Game Design, Community, Affiliates, and Topical Graphics and GPU Programming now includes Graphics Programming and Theory, DirectX and XNA, OpenGL and Vulkan General and Gameplay Programming includes Mobile Development APIs, Middleware, and Tools is now Engines and Middleware Visual Arts is now a top-level category with 2D and 3D Art as the forum Breaking into the Games Industry is now Career Development Game Design is now a top-level category with Game Design and Theory as a forum Writing for Games has moved to the Game Design category, from Creative Virtual Reality moved to Topical, which is intended for topics that span multiple categories New GDNet+ Benefits Be sure to check out all the GDNet+ Benefits that come with the upgrade. The list is much bigger! Calendar Now you can keep track of industry events with the calendar. We'll also create a community calendar in the near future. Blogs Blog navigation is now better. You can theoretically read every single blog post that has ever been submitted. On the old version you could only view the latest posts. Activity This is one of my favorite. The Activity stream is like "Latest Content" but much more powerful. The default is to be able to see all activity across the entire site, but if you don't like that you can create your own Activity Stream. You can subscribe to an RSS feed of the streams. Careers Freelancers are now a GDNet+ perk. If you're a freelancer wanting to broadcast your services to the GameDev.net audience I recommend you check it out - it's 1/6th the cost it used to be. Jobs are now powered by our new job portal, GameDev Jobs at https://gamedev.jobs. We'll be making more changes here, but GameDev Jobs allows us to do much more with job seekers as well as employers - you can even upload your resume for employers to search. As with the GameDev Market, we'll be using GameDev Jobs to power job listings on GameDev.net. Easily Add New Content You'll notice a "+" sign on the menu. This is a shortcut to add new content. Start a blog, submit news, start a new or topic quickly and easily. Realtime Notifications and Messages You might have noticed already, but you'll receive realtime notifications as activity happens around the site. If your browser supports it, you can receive the notifications on your desktop. Login Integrations For a while our Google, Facebook, and Twitter logins were broken. Not anymore! Now you can login to GameDev.net with your Google, Facebook, or Twitter account, and if that isn't enough you can also login with your Microsoft, LinkedIn, and Discord accounts - the latter of which will also integrate your GameDev.net account with our Discord chat room. Support Having a problem with the site? Now you can use the support link at https://www.gamedev.net/support which is available in your Profile menu under "Support". What are these Pixel things? Some members have noticed a new attribute in their profiles called "Pixels". It's time to explain what those are, but first we need to talk about Reputation. In our old system, reputation was awarded for up votes and down votes as one would expect, but it also awarded reputation for activity - things like logging in, posting a blog, upvoting someone, and so on. While it encouraged activity it didn't help with knowing which members were knowledgeable, helpful, or produced interesting content - basically the things that would define a member's reputation. With our new system, reputation is exactly as it sounds. It is calculated entirely off of a member's up and down votes, which I encourage everyone to use. Not only do up/down votes let the community know about the reputation of the member, it also lets the community know the quality of the contribution. Enter the Pixel. The Pixel is our way of valuing all the other stuff and more. Pixels reflect your activity as a member - you earn pixels by doing things on GameDev.net, such as posting a topic in the forums. If reputation is a measure of a member's helpfulness and quality, then pixels are a measure of a member's activity. In fact, if we gamify GameDev.net, then pixels are your score. But be aware, you can also lose pixels. One way is simply through decay. If you stop using GameDev.net then your balance will decrease. If you get warned, you'll lose pixels. Basically, do something that's not conducive to the community and good content, and pixels will be taken away. Pixels are a neat concept. We're excited about what we can do with them. As for current reputation, we're going to see if we can normalize reputation to real upvote/downvotes. I'll make another blog post about this when we have a solution. We need some kind of reset so the new definition of reputation matches members' values. What's next? We have a running TODO list and will be busy for a few more weeks to get the upgrade where we really want it to be. I don't want to spill too much on that, but we'll be bringing back the Image of the Day, improving the GameDev Marketplace and GameDev Jobs integrations, adding ways for you to showcase and get feedback on your projects, support for contests, and more. We're excited because this upgrade marks a new beginning for GameDev.net, and we hope you agree. As always, please leave your feedback in the comments below! And if you have any problems please let us know through the Support portal.
  15. 7 points
    I saw this image days ago, I liked how didactic it is:
  16. 7 points
    Literally clicked on the first Google result.
  17. 7 points
    ATOM MyRegisterclass(HINSTANCE hInstance)  should be ATOM MyRegisterClass(HINSTANCE hInstance)
  18. 7 points
    While people have covered the social side of things, I'm going to jump in and claim that C# is overall a better technical choice of language than Java. Yes, I went there. Java was designed first and foremost as safety scissors, a tool for people who couldn't be trusted not to hurt themselves. And honestly, that's true for most developers, particularly in the web and client/business app space. There was absolutely no desire to expose any "system level" functionality. It was meant to be a simple, sandboxy, safe environment to do most of the boring every day software development that makes the world tick. While C# partly shares this worldview as well, both the language and the underlying runtime were designed with the option to step outside that box, as long as you do it explicitly. (Notably, VB.NET was not designed this way.) There's a lot more capability in C# to manipulate memory, integrate with native libraries, control allocation, and do a lot of the direct manipulation of buffers that is inappropriate for most types of apps but is crucial for graphics code in particular and to some extent game code in general. It's the relative ease of doing many common game and graphics programming tasks that has made C# preferable here and in the industry in general. It's not that you can't do things in Java, but it always feels like you're fighting the language, working through kludges like FloatBuffer to get things done.
  19. 7 points
    Yes, you should process all events in the queue, instead of one per frame: while (!quit) { // if (win.pollEvent(ev)) { while ( win.pollEvent(ev) {
  20. 6 points
    A derived class can never renege on features provided by the base class; doing so is an violation of OO's LSP rule, so this approach is invalid. OO would force you to use composition instead of inheritance here. Make your own class from scratch which contains a vector within the private implementation details.
  21. 6 points
    If the scripts performing movement are purely cosmetic, then their state doesn't need to be saved to disk. If I'm playing a chess game and the rook is moving from A1 to A8 and I quit while it's animating somewhere between A4 and A5, I expect to reload and either see it at A1 where it's still my turn, or A8 where it's the opponent's turn. (I'd prefer the latter.) The underlying game state is one or the other - the animation state, where the piece is moving from the old position to the new, is purely visual and doesn't need to be saved anywhere. If you do have long-running actions that need to persist - e.g. it's an RTS game and you commanded a unit to walk across the map - then usually the command is attached to the unit that is executing it, and that would be saved out along with all other in-game state (which would reflect the visual position, as that is a valid game state, unlike in the chess example). The main thing here is to have a clear idea of what is actual game state that absolutely has to persist across sessions, and what is just a visual representation that can be recreated from the game state and which doesn't need saving at all.
  22. 6 points
    The questions are getting lazier as the conversation grows. Recommended reading. Your question is trivially answered with a web search. In current versions of the format it is not in the header, it is calculated:  stride = ((((infoHeader.biWidth * infoHeader.biBitCount) + 31) & ~31) >> 3); You're supposed to read, understand, and follow the documentation. That's why MSDN has gigabytes of stuff for your reading pleasure, with feedback and comments fields that allow for corrections and warnings, which eventually make it in to the documentation, allowing the docs to become better and better over time.
  23. 6 points
    Hey, long time no see! A full year since last entry. Kind of a weird year. I started freelancing as a web-developer so now I've been working from home, and it's surprisingly nice, although a little monotonous, but the positives far outweighs the negatives so I'm sticking to it. Also, I got a new cluster headache attack which, again, lasted three full months, and man, I really I don't wish that to anybody. Finally, I realized that, even though I'm not overweight, I was in terrible shape, so I decided to exercise more by buying a bicycle, and man, walking to the store was some damn good exercise. Of course buying a bicycle was not enough, I also had to use it, and I guess I started way too enthusiastically because on my first month riding the bike, after riding for over an hour, I passed out in the middle of the night near my home. I woke up on the floor with the bike next to me, and some dude came, asked me if I was OK and said: "man, your face looks fucked up!". I got home, went to the bathroom, looked in the mirror and, surprise, half my face was covered in blood. I basically faceplanted the floor with all my body weight while moving at (thankfully, low) speed, I'm lucky I didn't lose any teeth. The next day my mother saw me and was totally convinced that I got into a fight: "No, I'm telling you, I passed out while on the bike!" - "You're lying to me". It took a while to convince her. Besides that little incident, using the bike has done wonders, I don't get tired as easily now. I'm still in bad shape though, but not as bad as before. Oh, and yeah, I've been working on the paper game. Sloooooooowly. It kinda looks the same as before, but I added some particle effects, I cleaned up a little bit the HUD, I added ammo pickups (no more infinite bullets anymore), changed some colors to more "cheerful" ones, added some quality of life improvements like checkpoints and item indicators, phew, lots of stuff. Here's a little GIF showing some stuff. I have no idea how to embed Gfycat, so I'll just leave the link: https://gfycat.com/GracefulFlimsyAustraliansilkyterrier As you can see, particles fly everywhere. Oh, and I also made seeker missiles, which took me more time to implement that I'm willing to admit. Yay, rain effect! It doesn't make a single bit of sense with the art style, but eh! A ransom note generator! Useful for the mission titles, the game logo and stuff like that. Apparently it can also be used to make ransom notes, but don't quote me on this. Besides the above, I also wrote the outline of the story and how the missions will play out, but I still need to write the details, like define the personalities of the characters, write all the dialogue, things like that. Writing is surprisingly difficult to do, I've never done it before. Finally, a few months ago I uploaded a gameplay video showing a full, although short, level: This it how I want the final game to be: big maps with multiple objectives that you can do in any order while managing your ammo, health and fuel. It's an homage to the Strike series after all. This has been the closest I have ever been to making a game after many abandoned projects. I still don't know if I'll ever finish it, but I'm happy with the attempt so far, and surprisingly, I haven't lost interest in the project yet, so I guess I'll just keep at it. Thanks for reading!
  24. 6 points
    They can do most of that with C++ too, it's just a bit harder, and requires different tools. It should be the least of your worries, to be honest. Most games will never be popular enough to inspire cheats. Any singleplayers that are popular enough don't matter, because the player is only cheating themselves. And if it's a multiplayer game, you would protect against cheating by other means (such as running the main game on a server, or by checking that all players are synchronised).
  25. 6 points
    I don't have any data, but I assume that C# is much more popular in games? Unity uses it as the main scripting language, as do a few other engines. Not that many major game engines use Java as their main gameplay language, and it's quite hard to embed it as a "scripting language" like Unity has done. java is a perfectly capable language for gamedev though - there's plenty of people here who use LWJGL, libgdx, jmonkey, etc... I learned C++, then Java, and then C#. I still use C++ and C# regularly. My personal feeling at the time was that initially C# and Java were extremely similar (after all, C# only came into existance after Microsoft's proprietary version of Java - J++ - got shut down via lawsuits, and then magically hey, C# exists now and is in no way related...) but that C# fixed a lot of Java's terminal design issues and was basically "Java done right" :lol: The initial versions of Java came into being at the height of the 90's OOP-done-by-people-who-don't-understand-OOP craze, and were quite terrible... I actually haven't gone back and learned modern Java since that time, so I can only assume/hope that it has kept up with the pace of development that C# has had.
  26. 5 points
    I've long grown out of playing games. Coding games and tools is a different thing all together, I remain fully interested and stuck with coding mobile games and wouldn't choose a different hobby/career (well apart from the fact that I long to improve my coding skills, and my maths and physics knowledge) But playing games, these days (unlike over a decade ago) genuinely bores me to death. I guess I always feel I am coding for the younger generation, similar to enjoying making toys for kids but not enjoying playing with the toys yourself I'm coding mobile games at the moment and I look at and play some few just for gameplay analysis and checking current standards and features but not because I enjoy playing them I know this certainly makes me an odd-ball here, but just wondering how far an odd-ball I am. Is there a few... maybe just one more person like me here OR just me? (if the latter then I have to make sadder clown face )
  27. 5 points
    What it looks like you're trying to do is draw the first sprite, and then "wait" (is this why you were asking about Sleep()?) and then draw the second. This won't work. The "wait" call you are attempting to make here will just halt everything for the duration of the call, giving the program the appearance of freezing for a second or however long you are waiting. The correct way to handle this kind of thing is, unfortunately, more complicated. What you can do is keep track of how much time has elapsed between the last time you called drawScene() and this current call to drawScene(). There are various ways to do this, using various platform-specific or platform-agnostic timing APIs that can give you the "current time" in some fashion. std::chrono::high_resolution_clock is probably a reasonable place for you to look at (specifically, the now() function). void drawScene() { auto timeStampNow = std::chrono::high_resolution_clock::now(); auto elapsed = timeStampNow - timeStampPrevious; // ... timeStampPrevious = timeStampNow; } Here, you get the current time, subtract it from the previous time (which you are storing elsewhere, in a member variable perhaps) and compute the elapsed time since the last call. At the end of the function, you set the "previous time" to the current time, so it's correctly set up for the next time drawScene() is called. Once you have this elapsed time, you can use it to "count down" until the next time you are supposed to do something. If you have another member variable that is, say, "timeUntilSecondSprite" initially set to some value corresponding to how many seconds until the next sprite show up, you might do timeUntilSecondSprite -= elapsed; if (timeUntilSecondSprite <= 0.0f) { // Counter has run out, draw the sprite now. } You can implement as many time-based effects as you want with this approach, optionally resetting the counters when they hit zero if you want them to occur (for example) every N seconds.
  28. 5 points
     They're basically just saying "we're not going to say anything about how your perform your lighting. Maybe you light your scene with point lights, or maybe an environment map? We don't care. We're going to compute a number that you can multiply your lighting with, no matter how you've calculated your own lighting.
  29. 5 points
    On some older consoles, C++ exceptions either were not supported at all, or were not supported by default with a huge recommendation not to enable support for them with a compiler flag as it would be very detrimental to performance. e.g. on Wii you had this slow CPU with a tiny instruction cache. Enabling support for exceptions resulted in your compiled code being way larger (even if you never throw or catch anything!!), because it has to generate all the automatic-stack-unwinding code... and this meant that you'd end up with way more instruction-cache misses, which meant your game ran slower (even if you never throw or catch anything!!). That goes against the C++ mantra of only paying a cost when you use a feature... So in game-dev, many studios have outright banned the use of exceptions in C++ for all time. I'm one of those people - I use them freely in C#, but I pretend that they don't exist in C++. The typical implementation of C++ exception handling on x86 is pretty bloated. The typical implementation on x86-64 is waaaay better, but still super bloated compared to the normal ways of passing around information. I would only recommend using them if you actually need to throw a bit of information from one function to another that is far, far up the call-stack (and automatically unwind the call-stack in the process). If you're only going to be returning information one level up the call-stack, use pass-by-reference or return values like normal.
  30. 5 points
    ... and if you would like a reasoned, documented policy to help you make your decision, you could do worse than to follow the C++ Core Guidelines on the subject, developed by the same people who develop the language and its compilers.
  31. 5 points
    Nope. BMP files have huge variations.   Pulling the data from the official source: 7 different header types from different eras, you need to know which one you've got and complain about headers that are a higher version than you know how to process. Many types of bit encoding. We already mentioned 1-bit bitmaps, there are other numbers of grayscale bits. There are indexed colors with various palette lengths (usually 8, 16, 20, 236, or 256 colors, but any 32-bit number is valid), RGB8, RGBA8, BGR8, BGRA8, also encodings with 444 (4 bytes per channel), 555, 565, 676, 685, and other sizes. Many of these must be packed together, so 565 takes 2 bytes, 444 takes 1.5 bytes for 1 pixel, 3 bytes for 2 pixels, 4.5 bytes for 3 pixels, and so on. Color palettes, or not, depending on bit encoding Variable sized gaps for pixel alginment The pixel array that you mentioned, that encodes all the bits mentioned above.  They may be packed, for example the 444 formats must be packed for 2 pixels per three bytes. They may be 8 pixels per byte for a pure black and white image, or 2.6 pixels per byte, 2 pixels per byte, 1.6 pixels per byte, 1 pixel per byte, 1 pixel per 1.87 bytes, 1 pixel per 1.5 bytes, 1 pixel per 2 bytes, 1 pixel per 2.5 bytes, 1 pixel per 2.75 bytes, and so on all the way up to 1 pixel per 4 bytes. They need to be properly packed to match the format. The pixel array may also be encoded in color planes, where all the red components are in a row, then all the green components, then all the blue components.  Also, potentially blue, then green, then red. The pixel array may also contain compressed data, including JPG and PNG encoded data. Neither operate on a fixed byte-per-pixel size. The pixel array may have a stride, a gap and the end of each row, or maybe not. There may be another big gap of variable size There may be a color profile to indicate things like gamma values. There may be a link to a file containing additional color information. If so, that file must also be processed. As you can hopefully see, the bitmap format is far more complex than the basic forms the two of you believed it to be.
  32. 5 points
    [color=#000000][font=arial]Procedural grass level of detail[/font][/color] [color=#000000][font=arial]The world outlook from farther distance kind of felt boring and dull. Some games just increase the fog level just to hide this dullness. There was zero detail in the distance so I started increasing draw distance for trees and rocks. I have created a new simple mesh (actually a rectangle with two triangles) and populated it with a simple grass cutout texture. I proceeded with creating procedural LODs, placing both simple mesh and complex in one spot, baking the same ones together in patches and adding UnityaEUR(TM)s LODGroup on top of that. The distance is busy now which enables us to decrease the fog level. LOD levels (for world objects) and other settings (such as shadows) are going to be tweakable via config file.[/font][/color] [font=arial][color=#444444]Busier look in the distance aEUR" more grass at the back, but with less detail.[/color][/font] [color=#000000][font=arial]Terrain Shader[/font][/color] [color=#000000][font=arial]I have also managed to create a color variety on the terrain itself by writing a custom terrain surface shader. The shader enables us to input three different colors aEUR" one for the lowest points of the island, second one is meant for middle/ground heights and the last one is meant for hills and mountain tops. To interpolate colors smoothly I have transformed the colors from RGB to HSL space and used this code bit for interpolation (_Middle is a float [0, 1] that sets the aEURoemiddle groundaEUR? height):[/font][/color]float3 interpolatedHSL = lerp(bottomHSL, middleHSL, h / _Middle) * step(h, _Middle);interpolatedHSL += lerp(middleHSL, topHSL, (h - _Middle) / (1 - _Middle)) * step(_Middle, h); fixed4 tintColor = fixed4(hsl2rgb(interpolatedHSL), 1); [color=#000000][font=arial][/font][/color] [font=arial][color=#444444]Terrain shading with 3 different colors[/color][/font] [color=#000000][font=arial]Drone[/font][/color] [color=#000000][font=arial]Me and Andrej added a new kind of non-hostile NPCs to the world that actually have no purpose as regards to gameplay aEUR" they will only make skies more busy and immersive. They are called Prospecting drones. They will fly around the island, stopping at the rocks and try to mine them with their laser. Yes, you can destroy and scrap them, but why would you do that to these beautiful robot creatures? [/font][/color] [font=arial][color=#444444]Non-hostile Prospecting drone in action[/color][/font] [font=arial][color=#000000]Domen Koneski[/color][/font] [color=#000000][font=arial]Randomized human NPCs[/font][/color] [color=#000000][font=arial]Since there will be a lot of NPCs that will populate various settlements, we decided to make a system that randomizes the characters by using shape keys (blend shapes / morph targets, whatever your software calls itaEUR|) on the face to change different facial features of the character and effectively makes each character have a unique face. Of course the character will also have a variety of different outfits. [/font][/color] [font=arial][color=#444444]Randomized human characters[/color][/font] [color=#000000][font=arial]I started out by making a model with about average features and then modeled the extremes for every feature, so the game can blend between individual shapes, Then I made a script that randomizes the features and chooses a random combination of an outfit, shoes, a hat and facial hair. I also made a brand new animation rig for the human NPCs that will support the variety of animations that I have already started making for them. At the beginning of the week I concluded the work on aEUR~techiesaEUR(TM) buildings by finishing up the shop model. [/font][/color] [color=#444444][font=Roboto]Techies shop[/font][/color] [color=#000000][font=Roboto][font=arial]Andrej Krebs[/font][/font][/color] [color=#000000][font=arial]Adding lamps[/font][/color] [color=#000000][font=arial]Every device that we have in our electricity starter pack needs proper implementation. Previously I worked on repair and charging stations, but this week I focused on bringing functionality to light lamps, actually two types of those lamps aEUR" wall lamp & standing lamp. A quick preview in the picture below: [/font][/color] [font=arial][color=#444444]A wall light lamp & a standing light lamp.[/color][/font] [color=#000000][font=arial]We have improved the indicators, so those basic electric components are considered done for now. In this example I filled up the generator with fat, and it started to generate electricity. Very easy! [/font][/color] [color=#444444][font=Roboto]Filling up the generator.[/font][/color] [color=#000000][font=Roboto][font=arial]Vili VolA?ini[/font][/font][/color] [color=#000000][font=arial]Icons for electric devices[/font][/color] [color=#000000][font=arial]We are slowly finishing up the electricity which will be an exciting new addition to enhance the gameplay. The newly added electric devices will need icons to display them in the players HUD. Below you can see a set of new icons, including bolts which will have a special use in the game. [/font][/color] [font=arial][color=#444444]Icons for electric devices, wheat and corn.[/color][/font] [font=arial][color=#000000]Mito Horvat[/color][/font] [font=arial][color=#000000]More about Floatlands: website, facebook, twitter, instagram[/color][/font]
  33. 5 points
    Hello everyone! I've been pretty silent for a while again... I really dislike this, because I'm usually open and post a lot about my progress, but sometimes it just slows down and I end up in a spiral of "awkwardness", when I'm not progressing too much and I really don't want to talk about that :mellow: . Oh well, I'm preparing for the beta, some tiny fine-tuning left before I'm ready to upload a build, but before that, I share this update with a teaser. Menus, menus everywhere! I completed most of the menus. Some minor stuff (few more characters) are still missing but I will finish those during June. I included myself as the inn keeper :) . Interacting with the guy brings up the help screen and he also tells the "story" of the game in the teaser. Your journal I went for a journal look for the classic focus driven menus and your inventory. I think it turned out good looking and it fits the game well. For item pickup notifications I made a fancy scroll too. Animated box-art While preparing the trailer and other marketing materials, I had this urge to animate something related to the game :) . The in-game sprites are all static and I wanted to keep it this way, so I made an animated box-art. Some say it's a better attention grabber on storefront pages :wink: . Dungeon templates I made a bunch of new dungeon templates for the generator. Not enough for the final build, but there are already plenty and they provide good variety for a full beta play-through. Progress, balance First balancing pass over the item, monster and pickup power levels is also done. Nothing major, but you can complete the full 30 level deep dungeon now, encountering a new set of monsters and a new tile-set after every 3 or 4 levels and generally fighting stronger enemies as you progress. It is going to take days of tweaking to make it engaging though. I'm planning to devote a full entry to this topic soon. Teaser trailer teaser Yes, the following is just a teaser for the teaser trailer :D , a sneak-peek so to say. I'm working on a lengthier one which showcases gameplay features too with music, flashy texts and everything one would expect from a proper game trailer. So this is just the first 20 seconds of the real teaser, but I thought I should share it in this form and ask for some feedback/opinions about it... Thanks for reading! Take care.
  34. 5 points
    Java will be fine for the type of game you suggest. You can probably use that with LibGDX for what you want. https://libgdx.badlogicgames.com/
  35. 5 points
    Not sure what you mean by "memory security", but you can technically do that with pointers, too. It's still undefined behaviour in both cases.   int* naughty() { int x = 5; return &x; } So... uh, don't do that.
  36. 5 points
      It really sounds like you don't understand the difference between references and pointers.   Can you, without testing, tell me what the following quick code would output? Be as specific as you are able to. #include <iostream> void myFirstFunction(int &value) { std::cout << value << std::endl; } void mySecondFunction(int *value) { std::cout << value << std::endl; } int main() { int myInt = 7; myFirstFunction(myInt); mySecondFunction(&myInt); }
  37. 5 points
    Gaming with real money is highly regulated by hundreds of laws and licenses. You need to hire a lawyer that is familiar with the gambling laws for each country that your game is accessible from, or you could end up in prison.
  38. 5 points
    Your questions about what YOU should do in YOUR game, and what AAA Studios do in AAA games, those are different. People in AAA studios doing AAA games have budgets of tens of millions of dollars, and have over a thousand development-years to build their stuff. The studios rely on tools that are old and well-established, as well as tools that are new and heavily customized.  While the teams can use the standard c++ threading libraries if they choose, generally there are enough small details they want to control that they don't use it.  It isn't because the general-purpose libraries are bad, instead it is that they need more specific control than the general purpose libraries offer. But YOU working alone or with a small team on YOUR game probably do not have a budget of tens of millions of dollars or thousands of work years.  You probably have a budget of a handful of dollars and less than a single work year.  You cannot afford to do the customization.  So for you and your game, probably the standard library will be the easiest tool available, the least error-prone, and the most portable.  You should probably use the ones in the c++ standard library, or the ones provided in another higher-level library of your choice.  It isn't because the specialized libraries are bad, instead it is that you probably don't have resources to invest in the nuanced specialized details and the general forms are adequate.   Note that this is true of many features of the standard library.  The standard library provides a wide range of general purpose functionality.  It is what you should use in most cases for general purposes.  However, there are times when you need special purposes, and that's when you need to use a special purpose library. Whenever game developers tell me they won't be using the standard libraries, my first question is to ask what specific issue they are trying to overcome.  For example, not using the standard library's container system because it doesn't provide intrusive containers or containers with pre-established memory buffers needed for a specific task. Other times people let their lack of knowledge or their fears dictate using a non-standard library, which is usually a poor reason.  If you are on a large team and can spend the time and effort on customized versions for specific problems, then you can do so to save those few precious nanoseconds.  But if you don't have the resources, the general purpose libraries are probably the best thing for your code.
  39. 5 points
    There are numerous "leak checkers" available in various flavors for different platforms. I'd suggest starting with that.
  40. 4 points
    Ideally shaders would always be precompiled. Shaders are pre-compiled for a particular target / shader model -- e.g. SM5 shaders for FEATURE_LEVEL_11. If you try to load these on FEATURE_LEVEL_10, they won't work... So, you have to precompile your shaders once for each target that you wish to support. e.g. if you want to support D3D10, D3D10.1 and D3D11 hardware, then compile your shaders for SM4, SM4.1 and SM5, and then load the correct set of precompiled shaders at runtime.
  41. 4 points
    Reddit user Wafflyn made useful Blueprint and C++ cheatsheets for anyone using UE4. From the post: UE4 Blueprint Cheat Sheet: http://uecasts.com/resources/unreal-engine-blueprint-cheat-sheet UE4 C++ Cheat Sheet: http://uecasts.com/resources/unreal-engine-c-plus-plus-cheat-sheet
  42. 4 points
    I am stunned. How are the heck are people saying that the upgrade has been good? - Old articles are broken. The value of gamedev.net tumbles. So now I need to set up an activity list? I'd rather the older option where the forum topics are bumped up upon a post. The live feed was what I'd consider a majorly interesting part of the site. Over the past several updates gamedev.net has been getting more and more bloated. Design has also taken a turn for the worse. For example, when I'm reading a forum post I don't have a need to see Game Job's or Ads at the right side of the post. It makes information harder and harder to read and to find. Color contrast looks really bad imo, light grays and whites.
  43. 4 points
    This is looking better, and better. I really like the warm color pallet.
  44. 4 points
    First, a bit of introduction to work with source control. Details depend on the system you are using, but in a nutshell, there is a server with the master version of the code (as, for instance, github.com). Everybody who needs to work with the code, downloads a copy of the code from that server into their computer and work on that local copy in their computer. Once they are done working on a particular feature, they update the code in the server with their changes, and now the master version has their changes available to anybody that's going to work with that code in the future. The good thing about source control systems, is that they allow multiple people to work on the same codebase at the same time. When two people have been working on the same codebase at the same time, they didn't see one another's changes because they were working on their local copies. They will see one another's changes when they try to update the master version with their changes, and someone will have to merge both updates. One of them is going to be lucky and update the master version before anybody else, so the master version will be the same that they downloaded. No trouble. The next person that tries to update the master version with their changes, will find that the master version is no longer the same code they have been working on. Then, that person will have to download the changes and make sure their code works. If they are lucky, the previous person won't have touched the same code as them, the source control system will be smart enough to merge their changes and everything will work out. If not, they will have to go over their code and make sure that the recently updated master version works with their changes before updating again the master version. In my experience, you usually try to avoid working on the same part of the code. If I'm working on the same feature with another developer, we either sit together in front of the same computer and work together (that's usually known as pair programming, by the way) or work on different parts of the code. It happens, however, that you end up touching the same part of the code as somebody else that is working on a different feature. In those cases, if the person modifying the code sits close to you, you just sit together and review the parts of the code that you both have changed to make sure that both features work properly. Otherwise, the other person has hopefully written tests to make sure their feature works, so you fix any compilation issues, run the tests and fix anything that is not working. Debugging has nothing to do with source control. When you debug, you use the copy of the code in your computer, so you don't use or affect the master version of the code at all.
  45. 4 points
    Agreeing with those above. It usually needs to be an either/or decision across your entire code base.  Either everything is const-correct, or nothing is.   Const is 'viral'. As you start adding them, the functions they call also need to be marked as const. Their calls also need to be const. Repeat all through the code base. As you start adding const you end up requiring them in far more places than you might have expected.  Sometimes they become awkward, but in those cases you know you are violating good practices within the code base. If you cast away constness that is a code smell that you're probably doing things wrong. Deciding to leave them out generally means removing them from the code base when they are discovered. As the code grows any pesky const elements will be discovered and eliminated. The standard libraries are written to work either way, but many third-party libraries favor one way or the other. In those cases you'll need to write appropriate shims, either to make things const or to cast away constness.
  46. 4 points
    [color=rgb(29,33,41)][font='Helvetica Neue']Hey everybody, the making of Towards The Pantheon part 3 is up now on Youtube![/font][/color]
  47. 4 points
    Where to start when thereaEUR(TM)s so much to begin with? My name is EdenAeternum, formally known as Fallen14894. The project I have been working on is a code name titled aEURoeInfinite Odyssey.aEUR? YouaEUR(TM)ve probably seen a variety of meshes across the title picture and perhaps it caught your eye. Maybe it was the art style, maybe it was the colors, hell, maybe it was the unusual interface design. Regardless, youaEUR(TM)re probably wondering WHAT this is. Infinite Odyssey is a fantasy sim love child that is a weird hybrid between Stardew Valley, Animal Crossing, Zelda, and several RPG elements. I am not ripping off Stardew Valley or any other game, but rather IaEUR(TM)m taking the elements I loved about each of these series and shaping them into my own. Imagine a farming system similar to Stardew Valley, with a villager system similar to Animal Crossing, with Dungeon exploration similar to Zelda, only more RPG based instead of puzzles. That my friends, is what Infinite Odyssey is. Take a look at the sub sections and IaEUR(TM)ll break things down to make it easier to focus on. General Breakdown Infinite Odyssey starts with a short tutorial and then you are subjected to live your life the way you desire the moment you cross the last stone on the bridge. From here you are now in the village of Valorfel (The name CAN be changed by the default is Valorfel for lore reasons). Grow crops to sell, go fishing, run dungeons for items, craft gear, craft items, interact with NPCs, build friendships, expand your estate, or run through the storyaEUR"this is all your choice to do as little or as much as you want. Your character can stay awake for 72 hours at a time so explore town at 3am on Wednesday and youaEUR(TM)ll see things you didnaEUR(TM)t see on Tuesday. Turn in quests for some extra friendship renown and an extra item or two, and turn that item into something else. Maybe you just want to run a business empire and build up your farm. I wonaEUR(TM)t stop you. Want to run dungeons for rare materials- I wonaEUR(TM)t stop you. The idea is to give you features and incentives so you WANT to do these things but you wonaEUR(TM)t be forced to do anything you donaEUR(TM)t want to do. Featured below: Some of the crops in their "lootable" stage, and a well that is being built. Structures get built in phases so you can watch them grow! Story synopsis At the end of the tutorial you are trapped within the mists where time has suspended you for over fifty years. When you emerge, you havenaEUR(TM)t aged a day but the world you remembered is gone. You cross the bridge leading into the new prospering human settlement Valorfel, only things donaEUR(TM)t look the way they were supposed to fifty years ago. The once prospering village has been destroyed twiceaEUR"once by beasts lead by dwarves, and again by a cataclysm. Your former Caravan captain Wilhelm, the young and humble soldier is now an old man torn by the events of the years gone by. Wilhelm gives you a new place to begin your life anew. Discover why the mists held you and what secrets they continue to hide. Or say screw it and build up your farm. Again, the freedom is yours to pursue ;) Villagers At the beginning when you reach Valorfel, itaEUR(TM)s a small settlement. There are only about seventeen villagers and itaEUR(TM)s obvious everyone has their own struggles. Every character has their own story, and you are free to pursue all of them however, know your actions will have permanent effects! Each villager has a friendship rating from 0-15. At around tier three, most villagers will have a cutscene that introduces a bit of their past and a small crisis in their life. Some are strictly comedic, others are more severe. Around tier six youaEUR(TM)re introduced to another cutscene. Around this point you will have to make a choice. At tier ten or so youaEUR(TM)ll have to turn in that choice and at tier twelve youaEUR(TM)ll see a resolve that shows the results of your decisions. At tier fifteen you are introduced to one final cutscene that depicts the characters in their original life. (More on this later). Again, your decisions are impacting AND final! HereaEUR(TM)s an example from the BlacksmithaEUR(TM)s quest line aEURoeLonely Hearts.aEUR? At tier three, the Blacksmith Ahrmen is sitting outside alone. He spends the majority of his days alone working so he doesn't have much time for socializing. He is shy of people. At this tier you have a conversation and he opens up about how he envies the animal handler because of the time she spends with all the animals. At tier six we have another conversation with Ahrmen, only this time we're not alone! At the end, Serah, the animal handler schemes an idea to get Ahrmen a pet so he doesn't have to be lonely. You now have branching options. You can decline getting him anything, you can get him a dog, or you can trap a wild animal. At tier twelve we have a resolve for the decision. If you brought him a dog, the dog lives in his home and you will get different dialogues. His hours and schedule may change too, leaving him to leave work early some days to play with the dog. If you did nothing, he will continue working late, depressed and having different dialogue sets. If you trapped a feral animal you get a much more comedic scenario where he often sleeps outside in a bloody mess because the animal took the bed and he walked in his house without knocking first. He will be in an abusive relationship while maintaining denial about the experience. You get a sense of comedy but you also get different results because the action you took (or failed to take). When your friendship is ranked you get your final cutscene where we see Ahrmen in his original life. Ahrmen actually lived in the house on the edge of town where his only friends were the animals he cared for. It gives a sense of understanding about his current world shyness and his envy of Serah who works doing what he loved. In his original life, Ahrmen wanted to do something to help people which is why in our "dream" world he is a blacksmith, creating gear to save lives. Villagers will move in over time as you perform actions or as time passes. Rebuild the abandoned house and a new family can move in. Rank your friendship up and another family member might move in. Thirteen days pass, a new villager moves in. Take a certain action on a quest and someone may MOVE OUT. (The last one is limited to an event which will warn you before they leave on limited characters.) The point of this is I want a dynamic world where you donaEUR(TM)t instantly feel overwhelmed. Just start small, see how things flow and in time everything will sort itself. In times of crisis I believe everyone has a small handful of people we can trust and rely on. In this project I don't see why that should be any different. I want to reward you for taking the time to make friendships and bonds. Every NPC holds a different piece of the puzzle, all building a stronger heart. By building those bonds, you will do two things: You will be introduced to a character's personal story with a branching effect, and you will be rewarded for the outcome. Featured below: Your "neighbor." His house will change with the seasons and you'll see him either blowing bubbles, napping, raiding your trash bin, or any other series of cutesy behavior. Combat and Dungeons So I mentioned something along the lines of Zelda for dungeons, although that may not be the most accurate description. At this time IaEUR(TM)m planning on eight to twelve dungeons. The first time you run a dungeon you run it in a aEURoestory modeaEUR? similar to Guild Wars 2. When you return to the dungeon (There is a small number of days that have to pass before the mists let you return) you have an explorable route. Most dungeons have three to four paths with a combination of randomly generated and structure generated rooms. Once you start on a path, you are forced to resume that route, however along the way you will often be able to make a jump to a different route! Imagine starting in the dungeon on the first path, around the midpoint you can continue along or switch to the midway of path 2. Nearing the end you can finish on path 2, or move another direction. This leaves me plenty of room for various bosses and loot tables! Combat is an important aspect! I want this to be fun and I want YOU to have more flexibility! You have access to both Weapons and Deities/Heroes. Let me break each of these down to avoid confusion. Weapons are broken into four groups: Swords, Bows, Axes, and Lance/Spears. Each weapon comes with a small variety of skills. You have a regular attack combo and three additional abilities. Three doesnaEUR(TM)t sound like much but I would rather go on a smaller end with a better variety of useful abilities than offer a lot of no value. ThereaEUR(TM)s another reason for this, the deity system! When you access the church you have a choice to follow a deity, or follow a hero from the lore. These can be swapped at any point so youaEUR(TM)re never stuck with one as they round out your abilities. You can follow Saosk the Human Paladin, Thane Bloodhammer the evil Dwarf Berserker, or any of the other six options and those grant you access to new abilities. You can swing your weapon (left click) use your deity secondary ability: Paladin's Bastion, Druid's Vine Wrath, etc (right click) either of your 3 weapon skills and either of the three deity skills in your 1-6 interface (ThereaEUR(TM)s a button to switch between two interfaces so youaEUR(TM)ll have 12 slots to start. IaEUR(TM)ll possibly try for a total of 18). At any given time that gives you access to 8 different attacks/abilities. We will most likely add a few extra to those if we need but again: start small and get it balanced and right THEN add as needed. In a way that sounds like a small number but with 4 weapons with 3 unique abilities a timed attack combo (2-3 hits), and 8 deities with 3 moves each plus a passive ability thats just around 50 different moves. There's also a small talent tree with the deities so you can modify some of the moves to adjust they're utilization. You've got an HP bar featured in the interface with an hourglass icon, when it runs empty you pass out and several of your consumable items will be missing in addition to gold as your penalty for falling. Weapon abilities run off of cooldown timers. I'm not penalizing anyone with mana requirements. Deity spells work a little different. They run a timer and an adrenaline buildup. As you give/take attacks your adrenaline builds up. At that time you can choose to fire away at some of your stronger abilities, bank the adrenaline so you can spam them as needed, or just store it for a tight scenario. At this time only the last deity spell will have a small cooldown so you think before using it. The others should just need a little adrenaline. This leaves weapon skills as quick attacks with the deity spells being your real damaging effects. Combat is going to be fairly fast paced, couple of hits drops most enemies, but a couple of hits on you and you get dropped. The main benefit of this method is you can optimize your character as you see fit. If you want to be a bow using Paladin, have at it. If you want to be an axe using druid for irony, have at it. By being able to swap around you can experiment and try builds for fun, optimize for the most damage, or optimize for the most survivability. This present a new problem: Character's DO NOT have an individual level. We're not throwing a bunch of stats at you like dexterity, strength, etc. It's a simple system: You have health, a weapon, and your player skill. Combat has its own experience tree, farming has its own tree, fishing has its own tree, etc. That is one feature I greatly enjoyed in stardew valley and I want to build a similar structure and redesign it differently. So what about armor and defense? This is where the larger struggle comes in at: I don't want a defense stat. I would rather make enemies have moves that do a fixed range of damage, say 2-3 for attack B or 10-15 for attack C. If they're enraged attacks do 1.5x more damage etc. There's two benefits to doing this. For starters I can balance ALL dungeons. The goal for the start is eight to twelve dungeons: 4 accessible once you do the prerequisites and 1 thats only accessible for each season. If I make defense a stat and you don't realize how to unlock the spring dungeon until summer when its no longer accessible: 1 game year can take up to 36 playhours depending on how you choose to play and how often your character sleeps. That is a LONG time to outlevel the stats of a particular dungeon so the next game year it may not have anything of use other than for collecting purposes. The other addition to doing things a bit differently is if I kill the defense stat you're now encouraged to dress your character however you want! Sure, your starter armor will be simple, but what if you really like a druid helm, or an assassins mask? Shouldn't you be able to just enjoy looking however you'd like? Yes you could just do armor skins and then actual gear but then whats the point in that? Why not give you absolute freedom to look like a Pirate, a Paladin, a Druid, a Rogue, a fisherman, or whichever other set or combination of suits you? By that logic we can have unique dungeon armor sets so you have a purpose to keep running the multiple paths so you can find sets that will last as long as you remain interested in them. From there we can also do some armor bonus perks where wearing three pieces of a fisherman's outfit boosts your fishing ability, or 3 pieces of rogues gear can grant a small bonus to crit. It helps round out some extra utility without breaking the game to where you don't feel penalized for not having that particular set but you do feel rewarded for using it for a purpose. Closing Thoughts The last small section I want to touch on is the interface. I am just one man and I never really considered myself an artist in the past. I understand several of the basics and I've been doing pixel art for years now but I know I have a long ways to go and much to learn. With that being said, I want the interface to be fun! That's why each year your seasonal interface design will be different depending on the season, and your chat text bars will also be different. Some people have said the art is top notch, others have called it "High Res stardew valley." I'm trying to create something beautiful for you guys and I want it to be fun and full of small details. That in my opinion is half of the excitement. Those of you who are following will get some of that stuff spoiled but imagine your first time walking out in summer and your interface is now completely changed, the music is different, the maps look different: it's an exciting feeling and when we have some real progress and playable work I want to showcase this at some of the conventions and see your faces as you get to experience a lot of this first hand. I don't want the traditional long interface display with just 1-12, I love the small circular ones that frees up your screen view, and the time clock is reminiscent to the HP bars of Earthbound. It takes a lot of time but I'm happy to do it because there's so much that can be done and I want to give you guys the best that I can put out! This is a lot of information to start on so IaEUR(TM)m going to leave this here and update it again in a few days and try to answer any questions that you may have. If you took the time to read all of this, thank you! You guys are part of what makes crossing every one of these stones a worthy adventure of my own. Featured below: a small example of some of the water effects and some of the different trees. Final feature, an unfinished test map where we were testing crop growth. Note, the blacksmith house is not finished! I just needed to get some stuff up so we could start working on things.
  48. 4 points
    There are many unknowns here. If there's literally only one role and you know you have other candidates are good, then sure, you might reject them based on one single question if you felt it was a super important one. But for many roles, it's not a really important question. And in many studios, you're not just hiring one position, you're hiring anyone that is good enough and paying them commensurately. So I still find the idea of rejecting a junior entirely because they didn't answer that question to be odd. There was probably a time back in university when I could explain in detail what every part of the matrix meant and all these other details, but I've been in the industry a decade and I can't remember that stuff now because it doesn't matter. I don't think I've heard the term homogeneous transformation matrix for years except for this thread. It doesn't come up in practice because most of us can just use whatever functionality the engine provides to build and manipulate the matrices. e.g. If I need one in UE4, boom, FRotationTranslationMatrix::Make to the rescue. Like Hodgman said, the matrix can essentially be a black box unless you want to dig a bit deeper. Personally, I've always seen far too many people getting bogged down on rendering minutiae while neglecting gameplay, networking, and AI, so I specialised in those instead. No regrets.
  49. 4 points
    void function(const std::vector<std::unique_ptr<Base>> &v) {     // ... } void calling() {     std::vector<std::unique_ptr<Base>> v;     function(v); }
  50. 4 points
    Whenever I'm writing old-school C-style memory management code in C++ these days (i.e. raw pointers, not 100% RAII, no "smart" anything), I now use a template like this that asserts when you forget to clean up properly. It also greatly helps to annotate which raw pointers are users of an object, and which raw pointer is the actual owner of an object: template<class T> struct Owner { ~Owner() { ASSERTMSG(p == 0, "Leak detected"); } void Release() { if(p) p->Release(); p = 0; } T* Relinquish() { T* copy = p; p = 0; return copy; } explicit Owner(T* data=0) : p(data) {} Owner(const Owner& o) : p(o.p) {o.p=0;} Owner<T>& operator=(const Owner& o) { ASSERTMSG(p == 0, "Leak detected"); p = o.p; o.p=0; return *this; } Owner<T>& operator=(T* data) { ASSERTMSG(p == 0, "Leak detected"); p = data; return *this; } operator Ptr<T>() const { return p; } T* operator->() const { ASSERT(p, "null dereference"); return p; } T& operator *() const { ASSERT(p, "null dereference"); return *p; } operator bool() const { return !!p; } T* Raw() const { return p; } private: mutable T* p; }; //e.g. struct Foo { //int* m_A;//bad //int* m_B;//bad Owner<int> m_A; Ptr<int> m_B; Foo() { m_A = new int; } ~Foo() { delete m_A.relinquish(); }// if you forget to write this part, you'll get an assertion failure! }; And I use this one for non-owning pointers to ensure that uninitialized pointer bugs don't ever happen: template<class T> struct Ptr { Ptr(T* data=0) : p(data) {} operator T*() const { return p; } T* operator->() const { ASSERTMSG(p, "null dereference"); return p; } T& operator *() const { ASSERTMSG(p, "null dereference"); return *p; } operator bool() const { return !!p; } T* Raw() const { return p; } private: T* p; }; In optimized builds there's basically no overhead compared to actually using raw pointers, but in development builds they catch all sorts of bugs. I've had similar templates forced onto me during several game projects in the past and I really didn't like them at the time... however, 5 years of fixing stupid bugs later and now I'm converted and will recommend this practice to others :D I haven't looked into it fully, but I believe that the C++ Core Guidelines project supplies similar templates to mine (except probably much more robust!).