Leaderboard


Popular Content

Showing content with the highest reputation since 05/27/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: 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. <Mike> I have another thing to mention <Mike> Google.com wants to do our search <TheAgnostic> ?!? <TheAgnostic> They contacted us? <Khawk> who's google <Mike> They want to be our search engine for the site <geoffh> k - a search engine, like AltaVista, but nicer in some ways <geoffh> mike - how do you feel about it? <Mike> Well.. their results are unique <TheAgnostic> 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. <Khawk> wow, i've never heard of them [/font][/color] <Mike> We'd have a search page at [/font][/color]www.google.com/gamedev <geoffh> will they go down/work slow, etc?[/font][/color] <Mike> No idea.[/font][/color] <TheAgnostic> 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] <geoffh> you think itd be better than our own deal? <geoffh> didnt you do a kick ass search engine mike? <Mike> Yeah, it works pretty fast. 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'story 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. 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.
  3. 9 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
  4. 9 points
    http://www.gamasutra.com/view/news/128569/Opinion_No_One_Cares_About_Your_Cool_Game_Idea.php
  5. 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.
  6. 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.
  7. 7 points
    I saw this image days ago, I liked how didactic it is:
  8. 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.
  9. 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.
  10. 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 )
  11. 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.
  12. 4 points
    Extending a standard library container class is almost always the wrong approach. There are very few things in the standard library designed for extension, and those are clearly indicated. It is possible to extend some of them, but it usually comes with unexpected ramifications. Your desire to mix smart pointers and raw pointers, as well as trying to describe what can be copied all reek of a common problem. Controlling the lifetime of objects is a critical aspect of software, especially true in games. What you describe sounds like a symptom of not understanding what code owns the lifetime. What is the REAL problem you are trying to solve here? You came up with a solution of trying to do complex things with a vector, but what problem drove you to that solution?
  13. 4 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.
  14. 4 points
    Game developers use licensed engines for the same reason I use a web browser made by someone else. It's faster and easier if someone else has already done the work. In theory I could code up a functional web browser and it might even work better for me in some ways but why waste that time?
  15. 4 points
    Hello again, I'm going to be presenting a 40 Minute Talk at SIGGRAPH 2017 as part of the Advances course again. I am going to cover the noise generation and weather system as well as our authoring approach and some other updates. If it is allowed, I will share the Houdini tool that I made to generate our noise with the public. This way you can also experiment with other configurations. Hope you can make it or review the slides when the come out. Andrew PS this is awesome!!!
  16. 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
  17. 4 points
    Your constructor is wrong, and you are using uninitialized data. When you draw, you're copying the uninitialized values from the member into the rect, and then you attempt to draw. x = x will assign the value of argument x to itself -- it will do nothing. To refer to the member's x value, you need to write "this->x". This is because when you just write "x", there's no way for the compiler to guess which "x" you want to refer to. Because of this, it will always pick the values passed into the function. Thus, you need to write "this->x = x;" -- and similar for the other lines. In case you're wondering, all class and struct instances have a "this" pointer, which is what we're using to solve this problem. Another solution would be to rename the argument values to something else. Either will work, but it's important to understand why the current code is broken.
  18. 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.
  19. 4 points
    This is looking better, and better. I really like the warm color pallet.
  20. 4 points
    Simply interpolate between the old and new positions in the grid and ignore input during the animation. Perhaps something like: void Player::update(float dt) { if ( this->move_state == MoveState::STOPPED ) { int2 dir = this->process_move_input(); if ( dir ) { this->move_state = MoveState::MOVING; this->move_timer = this->move_speed; // in tiles per second this->old_pos = this->pos; this->pos += dir; } } else if ( this->move_state == MoveState::MOVING ) { this->move_timer -= dt; if ( this->move_timer <= 0 ) { this->move_timer = 0; this->move_state = MoveState::STOPPED; } } } void Player::draw() { int2 pos_px; if ( this->move_state == MoveState::MOVING ) { // move_timer goes from 1 to 0, so math on positions is reversed from the traditional A→B interpolation pos_px = this->pos + float2(this->old_pos - this->pos) * (this->move_timer / this->move_speed) * TILE_SIZE_PX; } else { pos_px = this->pos * TILE_SIZE_PX; } // draw avatar at pos_px }
  21. 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.
  22. 3 points
    It's also not as quickly searchable Several programmers I know have used various note-taking applications for exactly this purpose. Writing down gotchas, important bits and pieces, etc. Of the ones I remember being mentioned are EverNote and OneNote.
  23. 3 points
    To follow on from what Hodgman said, it can be useful for the 'enter' phase of a new animation state to be able to query the animation state that it is replacing, so that it can set itself up better. For example, when you go from a run to a stopping state, the stopping state could ask the run state which foot hit the ground last and how far through the cycle it is, allowing the stopping state to pick a frame that most closely matches that position. Another way to handle this is to allow transitions to 'push' data into the new states. But some sort of generic and simple communication during transitions is useful.
  24. 3 points
    You should be able to provide a null source box, which is equivalent to applying the whole source subresource to the specified offset in the dest (which should be (0, 0, 0) if you're copying the whole mip). In general, you should always round up the size of the copy to block dimensions, even if the texture doesn't have the logical dimensions to support it. So a 1x1 BC3 mip would be copied as if it was 4x4.
  25. 3 points
    We can't really tell you or we wouldn't be here, as Tom said. Secondly, what works for you is personal, and we don't know your preferences or desires or likes and dis-likes. I'd suggest think for yourself (and write down honestly) what you like, your strong and weak points, and go from there. Maybe a closer friend can give you insights? Other options would be some form of career counseling.
  26. 3 points
    I think the reasoning is actually pretty straightforward. Basically, the complexity of what consumers expect in a game is continually increasing, meaning that engines also need to become increasingly complex. That means the cost of maintaining a custom engine even through a single development cycle is also going up. Meanwhile, accessible third-party engines are not only keeping up with this complexity, they're also becoming much more mature (and generally less expensive, too) than they were even a few years ago. All in all, in a lot of cases, it just costs less time and money to use a third-party engine. Furthermore, there's no reason I can think of that this trend won't continue. Even if a custom engine seems like a good idea for a project now, it probably won't be for some future project, so using a third party engine now means you'll already have valuable experience with the engine you will use in that future project.
  27. 3 points
    I'm sure this question will get nabbed by the mods quick-fast, and in a hurry, but I'll still try to give you a sensible answer. It sounds like you're expressing an opinion more than asking a question. The fact is that engines are hard to write. For some individuals / studios, the economics are a no-brainer: using a ready-made/licensed engine can be far more cost-effective than writing a custom one. And yet, some studios still do write their own engines for one reason or another. The decision has nothing to do with "custom engines starting to become irrelevant"; it has everything to do with cost-benefit analysis.
  28. 3 points
    The default case is to work by value: void doThing(int num) { num++; } In this case 'num' is a copy of whatever you pass in when calling the function. int derp = 1; doThing(derp); //derp still equals 1 because it was a copy that got incremented If you want to be able to modify the original value then you can pass by reference: void doThingByRef(int& num) { num++; } Now 'num' is effectively a direct alias of whatever you pass in: int derp = 1; doThing(derp); //derp now equals 2 There's another case to consider... What if the thing you're passing in is large, but you don't want to modify it? You don't want to do an unnecessary copy, so you may use a reference, but that suggests that you're modifying the item within the function. In this case you could use a const reference: void doThingByConstRef(const BigThing& thing) { ??? } This lets you read 'thing' but not modify it (you'll get a compile error). These are the basics of reference semantics. Pointers are similar, but they have some additional properties: 1) A pointer is "nullable". That is, it can be set to 'nulllptr' in order to indicate that it doesn't actually point to anything. 2) A pointer is "reseatable". That is, it can be modified to point at something else. A note about pointers and constness: int* num; //the pointer can be changed and the int that it points to can be changed const int* num; //the pointer can be changed but the int that it points to can not int* const num; //the pointer can not be changed but the int that it points to can be (probably use a reference instead in this case) const int* const num; //neither the pointer or the pointed-to int can be changed (probably just use a const reference instead) Be careful about returning pointers and references from functions. If the thing that you're referring to is destroyed or moved then you end up with a dangling reference/pointer, and that's no fun at all. So the basic rule of thumb here is: Use value semantics by default. Use references when you want references. Use pointers when you want references that are reseatable and/or nullable. Cheers.
  29. 3 points
    This behaviour sounds exactly like what I'd expect if the GPU was throttling back its frequency because you aren't giving it enough work to do to warrant being clocked at peak frequency. By turning off VSync you're giving the GPU as much work to do as it can manage. With VSync enabled you're restricting it to 60 frames worth of work per second which it can easily deliver at reduced clock speeds.
  30. 3 points
    It's important for you to understand how regular, "non-smart" pointers work, so I do encourage you to learn. But once you learn how, it should illustrate just how much more useful smart pointers are when it comes to the actual management of object lifetimes. There are very few cases where "having additional control over when to free the pointers" is worth the trouble, and none of them are applicable to a beginner. That said, smart pointers are not a magical bullet and I disagree with the common dogma that says a regular pointer should never appear in one's code. Generally I use smart pointers such as std::unique_ptr (I rarely have a concrete need for std::shared_ptr) where I need to use a pointer to manage lifetime. I use a bare pointer where I need a nullable reference and lifetime management isn't involved. Another way to say that is that systems that own objects might keep smart pointers referring to those objects, but hand out bare pointers to client code if handing out a C++ reference ("Thing&") isn't feasible. If this seems like too subtle a distinction, then I encourage you to simply use smart pointers until you are more comfortable with the ins and outs of lifetime management in code architecture, and then revisit the topic with your improved understanding and experience at a later time.
  31. 3 points
    this creates a d3d device, and d3d points to it. and then this sets d3d to NULL, then checks to see if d3d is zero or non-zero, and executes the code block if its non-zero. Since it was just set to NULL (ie zero), its never non-zero, so the code block never executes, and you are always NULL-ing out your d3d device pointer. A guaranteed show stopper there. this is because evaluating expressions inside the condition statement has a higher precedence (IE gets done first). In the end its simply a typo quite common to c/c++. lesson learned: always double check those == statements. its a typo that syntax checking can't pick up, which leads to a logic error. it can only be found by code inspection or testing (or both ?).
  32. 3 points
    It's totally normal, if you consider a character as being an entity with a well-defined set of skills. If you believe that skills are separate entities unto themselves, and they come and go (rather than the character just raising/lowering/enabling/disabling them) then, yes, you need a separate table to join characters to skills. I would recommend that you do NOT go for flexibility right now, because making just your first game is going to be hard work enough -- you're not going to have lots of time to try many different things, at least not to the point where you will put them into the database. That being said, if you really believe this is an area of quick iteration, then just slam 'em all into a single JSON blob and call it good! Separately, I would advise NOT to use an ORM. Ever. For any application. Objects in RAM behave differently from rows in a database, and the impedance mis-match that happens when you try to join them, ends up killing projects. And, what's most insidious, is that this kind of death only happens towards the end of the project, where scale makes itself known. Projects that manage to pull out of this, typically re-code their ORM integration in raw SQL, and exactly how painful that is, depends on how heavily they relied on the ORM "magic" before then. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern Programming with relations in memory is actually, in general, a better model than programming in "rich" objects, anyway -- this is the learning from the "data oriented design" movement that's basically taking over high-performance gamedev in the last 15 years or so.
  33. 3 points
    There is also the possibility that the bug itself is non-deterministic. For example, many forms of memory corruption manifest differently depending on where in the address space individual objects happen to be allocated. For a bug of that type, exactly reproducing the steps doesn't offer any guarantee that the bug will reproduce. You may have to fall back to stressing out the system in the hopes that it reoccurs randomly. Or, if you can't reproduce the bug, then the programmer may have some luck running Valgrind (or an equivalent tool) to chase down buffer overruns and other common causes of memory corruption.
  34. 3 points
    This is a terrible idea on any well-architected project of any scale, though. If you only compile a single TU which is effectively token-pasting (via the preprocessor) every other source file, then you're effectively recompiling the entire code base on any change. In other words, you're throwing away one of the very few advantages one can capitalize on in the C++ compilation model: separate compilation and linking. On modern platforms, discarding separation of TU compilation also tends to discard the ability to distribute compilation, further increasing compilation times. This is a reasonable approach for small projects that want a simple (source-only) distribution mechanism to avoid binary file format distribution problems (a description that fits most of Sean Barret's libraries which you are referencing). Once a project grows beyond the point where any change should cause a full-recompile, it starts to become exponentially less of a great idea.
  35. 3 points
  36. 3 points
    Much like a normal hash map, there's no particular requirement that a bucket in a spatial hash represent exactly one location in the world. It is required that nearby objects hash to the same bucket, but not that all objects in the same bucket are nearby to one another. You can trivially define the buckets to repeat across the world (i.e. by adding a modulo to your hash function), and then when checking for nearby objects, you first find the matching bucket, and then check the actual distance of each object in the bucket. This matches the behaviour of a normal hash map a little more closely, and removes the need for arbitrarily large cells, or other complicated datastructures.
  37. 3 points
    Unity sucks this way. It has to do with Unity's coordinate, then there is also the fact that it can't import normals correctly, it's scale has problems, it imports smooth groups wrong... In short: there isn't any format, mesh type or 3D software than Unity imports correctly. So here is what you do: You import your 3D software file, if you use Blender that means importing the .Blend. Remember to delete everything in the scene you don't want to import. Once you have imported this file you will find it is attached to a container, a empty 3D object. Apply movement to this object instead of the character. The character is attached to this object and will act with it, this object has the correct rotation for Unity. No matter if you use Blender, Maya or Max; Unity will import the mesh as a .FBX, so there is no downside to doing things this way; in performance. Although if you give someone the editor files they also need the same 3D software. Check that Unity calculates the normals and tangents, instead of importing them. Don't bother with smooth groups, they increase the vertex count, limiting the batching Unity can do with a object. Always build your material in engine, no matter what engine you use. Importing the 3D software file is only a short term solution, you will need to make the proper adjustments at some point. To do this make a axis in your 3D software and align it with Unity. If you want I can explain more about this.
  38. 3 points
    First, you should not keep updating networking in a time loop. Drain all incoming packets until recv() returns nothing, and then process all incoming packets until the incoming packet queue is empty, and then go on to perhaps step the world again. Second, I don't see your code subtract anything from the "dt_sys" and "dt" variables inside the loops. You'd never break out of the loops. Third, I don't see your code increment "dt" and "dt_sys" variables outside the loop. Given the description you suggest, it sounds to me as if you are perhaps not managing that correctly, and building up "wrong" dt values? Fourth, what timer are you using to measure time? If you're using Windows GetTickCount(), or even timeGetTime(), those are terrible for resolution. You'd want something based on QueryPerformanceCounter(). On LINUX, you want something based on clock_gettime(CLOCK_MONOTONIC_RAW). On both systems, gettimeofday() is also not particularly stable and should be avoided. So, if you rip out "dt_sys" from your code and just run the code that's inside that while() block once per outer loop, that's a good first step. Then, show us the code that increments and decrements "dt" and the code that reads the clock. Then, if you're still having trouble, we might be able to meaningfully help with details.
  39. 3 points
    Here goes one problem if (d3ddev = NULL) { MessageBox(hwnd, "Error creating Direct3D device", "Error", MB_OK); return 0; } Use '==' to test for equivalancy. Which explains why you make it to the exception being thrown. I'm guessing this call is failing here. Make sure the values you are passing to this function are valid d3d->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &d3ddev);
  40. 3 points
    Still getting the hang of where things have moved to, but other than that everything looks and feels great!
  41. 3 points
    Are you sure that you enjoy programming? Programming as a job is very different from doing it in school or for side projects, you really gotta be fine with mundane problem solving to stick with it. Taking your current skills and working for a year might help you make a more informed decision. I can only speak to the U.S., but getting a 4-year Computer Science degree is really the best bet (if you're sure that you want to program). From there, you can either get a regular programming job and work on games on the side, or do games-related side projects during the degree and go straight into the games industry when you graduate. Also, you'll always have the degree as a fallback if you do go straight into games.
  42. 3 points
    The game industry is relatively forgiving in substituting experience for a degree - but not just any random work experience. If I have an applicant who doesn't have a degree, I need to be assured of a couple things: There's a good reason for not having a degree. Money (in the US) is a valid one. "I didn't think it was useful" is not. The work experience and independent projects are sufficient to produce a capable engineer in general. The actual abilities and skillsets are directly relevant to the job at hand. There is intellectual potential for continued growth and advancement. In that light, I have some comments. "It's two years of formation, VERY practical, it doesn't enter into abstract things like algebra." Red flag. Algebra (and linear algebra) are not abstract nonsense, they're absolutely foundational. If you can't demonstrate basic mathematical competence then I have zero interest in hiring you for any programming position. "Right now, I'm doing a 1 month Unity course in my city, organized by an university, very solid (I was given a scholarship)." While this is a perfectly good way to achieve personal growth, it has no relevance to employment. "The design teacher (a really good professional) told us that he can help us to get a job as QA tester in a videogame company." While I have some friends who have followed this route, I don't advise it. In general, I'd rather see someone doing non-game programming work than spending time in the QA trenches just to say they were in games. QA is a better route for those who have minimal relevant skills of any sort. "Also, I've given a job offer for Java Programmer in a consulting company. It's not videogames, but it's programming experience. That's a safer route." Unfortunately, Java consulting is very unlikely to get you into the game industry. It's a good way to make ends meet while doing independent projects that can demonstrate your abilities, though. To be candid, I get the distinct vibe that foundational Java programming is all you know. That is not even remotely sufficient to get a games job. While both the university and job experience routes are ultimately viable, neither one automatically gets you there. In either situation, you're going to need to do substantial independent work to be considered qualified for a game programmer job. Generally the university path is much more likely to give you a smooth entry into the industry, as it raises less questions about your abilities and decisions. The main reason for not doing so in the US is related to the financial challenges of going to a university. If you're going to attempt to use job experience instead, it should either be because you need to make ends meet or because the job experience is strongly relevant to the game industry.
  43. 3 points
    I agree with everything Avalander said. Additionally, I would also stress that if you are working in a team and you are doing something which might affect the workflow of others, communication is vital. Whether it's a quick check to make sure you're not both trying to fix the same bug without knowing that the other person is doing the same, or for planning out more large-scale tasks. It's also important that, when (not if) things don't go exactly as planned, you are able to communicate with others and quickly find the best way forward.
  44. 3 points
    I want to start a project with RPG Maker, but I want to do it unforgettable. I want to do this game has very interesting story. Like Mad Father,Ib.. I am an artist, so I can only draw. I still need a programmer,musician and a writer for story. Can you help me for this journey?Contact me! I can't paid you.I will just be thankful.
  45. 3 points
    Hello all, 1 month ago I had released my 2nd game on Android and WebGL. It’s a simple clicker/idle game, in which we gather funds and we buy upgrades, from time to time, we make decisions. I must say, that creating this game, was very fun. „Tree Tap – Money Idle Clicker” Was downloaded by 539 users, WebGL version got 13500 game plays, those numbers are not big, to be honest, those statistics are really weak, but I’m glad that someone had played my game. 141 users had download game from Amazon Store, 398 from Google Play. The Biggest number of downloads (in one day) was 72. Game is downloaded 12-14x/per day. As a curiosity, record of my first game (downloads in one day) was 30. Actual number of downloads of my first game is 427. How does earnings from „Tree Tap – Money Idle Clicker” looks? $19.46 (Kongregate) $2.37 (Unity Ads) $0.61 (Chartboost) I can’t withdraw those cash, it’s too small. I was ready for those earnings, I don’t hope too much on earnings, I still learn, I think, that my games are too weak, to earn some cash. For marketing, I had use: Twitter, Facebook, Reddit, Wykop(Polish website) and I had written to many youtubers, sites. I was also frequently updating game, based on players requests. As a next curiosity, my game is frequently used on those devices: Some Data, about users of my game: Google Nexus 6P - 4.5% Samsung Galaxy S7 Edge - 4.5% Samsung Galaxy S7 - 2,8% Google Pixel XL - 2.0% A lot of Samsung Devices ( 60-70% ) What are my plans? I plan to make new updates for „Tree Tap – Money Idle Clicker”, then I will learn new things in C# and I will make next game. I think, that it will be next clicker, but I plan to make a other mechanic for it, it won’t be boring clicking. If You got any questions, feel free to ask them, threat this as a curiosity, I got 18 years, I’m still weak newbie. Tree Tap – Google Play Tree Tap – Amazon Store Tree Tap – Online Version, Kongregate Facebook Twitter
  46. 3 points
    You could post it on Git. I always view these paste it things as just for sharing throw away code snippets, not for entire projects. In Visual Studio (I don't know what environment/IDE you're using) you can synch up with a Git repository, and commit your project, and it's directory structure. This makes it a lot easier for sharing, and even working with other devs (You can branch off the main project and work on smaller features in a way that won't destroy the build when something goes horribly wrong). I'd recommend creating an account if you haven't already: https://github.com/ I just think more people will be likely to dig through 11 source files in a nice repository than 11 separate hyperlinks.
  47. 3 points
  48. 3 points
    Home: https://www.khronos.org/vulkan/ SDK: http://lunarg.com/vulkan-sdk/ AMD drivers: http://gpuopen.com/gaming-product/vulkan/ (Note that Vulkan support is now part of AMD’s official drivers, so simply getting the latest drivers for your card should give you Vulkan support.) NVIDIA drivers: https://developer.nvidia.com/vulkan-driver (Note that Vulkan support is now part of NVIDIA’s official drivers, so simply getting the latest drivers for your card should give you Vulkan support.) Intel drivers: http://blogs.intel.com/evangelists/2016/02/16/intel-open-source-graphics-drivers-now-support-vulkan/ Quick reference: https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf Reference: https://www.khronos.org/registry/vulkan/specs/1.0/apispec.html GLSL-to-SPIR-V: https://github.com/KhronosGroup/glslang Sample code: https://github.com/LunarG/VulkanSamples https://github.com/SaschaWillems/Vulkan https://github.com/nvpro-samples https://github.com/nvpro-samples/gl_vk_chopper https://github.com/nvpro-samples/gl_vk_threaded_cadscene https://github.com/nvpro-samples/gl_vk_bk3dthreaded https://github.com/nvpro-samples/gl_vk_supersampled https://github.com/McNopper/Vulkan https://github.com/GPUOpen-LibrariesAndSDKs/HelloVulkan C++: https://github.com/nvpro-pipeline/vkcpp https://developer.nvidia.com/open-source-vulkan-c-api Getting started: https://vulkan-tutorial.com/ https://renderdoc.org/vulkan-in-30-minutes.html https://www.khronos.org/news/events/vulkan-webinar https://developer.nvidia.com/engaging-voyage-vulkan https://developer.nvidia.com/vulkan-shader-resource-binding https://developer.nvidia.com/vulkan-memory-management https://developer.nvidia.com/opengl-vulkan https://github.com/vinjn/awesome-vulkan Videos: https://www.youtube.com/playlist?list=PLYO7XTAX41FPg08uM_bgPE9HLgDAyzDaZ L. Spiro
  49. 2 points
    It's instructive in cases such as this to examine how the compilation process actually works. Under D3D compiling a shader is a two-stage process. Stage 1 compiles the text-based HLSL code to hardware-independent binary blobs and this is the stage that is carried out by fxc.exe or D3DCompile (which are actually the same thing but I'll get to that in a moment). Stage 2 always happens in your program and this stage takes the hardware-independent binary blobs and converts them to actual shader objects (i.e. ID3D11VertexShader, etc); this stage is exposed by the ID3D11Device::CreateVertexShader/etc API calls. The point I made above is that fxc.exe and D3DCompile are actually the same thing; fxc.exe actually calls D3DCompile to compile it's shaders, and this is something you can confirm by using a tool such as e.g. Dependency Walker. You can also infer that D3DCompile and D3DCompile2 are hardware-independent by the fact that they don't take an ID3D11Device as a parameter (in other words Direct3D doesn't even need to be initialized in order to compile a shader; this is a pure software stage). Microsoft's own advice on this matter is given at the page titled HLSL, FXC, and D3DCompile and I'll quote: This page then goes on to discuss scenarios in which you may, despite this advice, still wish to compile at runtime, such as for development purposes; runtime compilation is particularly useful for shader development if you're able to quickly reload and recompile your shaders while the program is running, and see the effects of code changes immediately. Finally, and this may not be immediately obvious, but you can actually compile your shaders for a lower target than the D3D device you end up creating and ship a single set of precompiled shaders that way. For example, if you set a minimum of D3D10 class hardware, you can compile your shaders for SM4 and set up your feature levels appropriate, and they'll work on D3D_FEATURE_LEVEL_10_0, D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_11_0 or higher.
  50. 2 points
    I'd also recommend turning on the compiler warning that will catch this, by increasing the warning level to 4 in Visual Studio. You could even go as far as turning that warning into an error by doing: #pragma warning(error : 4706)