Jump to content
  • Advertisement

SyncViews

Member
  • Content Count

    261
  • Joined

  • Last visited

Community Reputation

752 Good

About SyncViews

  • Rank
    Member

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. SyncViews

    Alternatives to tiered gear

    A lot of games just recolour the same items for tiers / variations for armour, swords, arrows, etc. This can be done quickly in any image program, or at run time (also less images to store/load, not that important for most 2D games these days). A way to recycle them is one option, but I still don't really like it in many contexts, especially if boss/reward items become obsolete and can just be traded in for a few insignificant $. Another option though is horizontal scaling. There may be some basic mass produced "starter" items that are made completely obsolete by a second tier perhaps, but otherwise generally everything should have its own value. Likely far less items in total, with more specialized things being harder to get/make. e.g. taking firearms, rather than just a MK2, MK3, etc. or Silver, Gold, etc. of essentially the same thing, open up more options, and don't just have any straight upgrades that would make what came before completely obsolete. For example to take general firearms like SMG's and assault rifles. One option to increase "damage" would be a faster muzzle velocity from a more powerful charge, but that gives you increased recoil and there are various material limitations, meaning added weapon weight, etc. Another option to increase "damage" would be larger bullets. But that also means more energy so increased recoil, and you need a larger gun so more weight, and the bullets are bigger so maybe smaller magazine, or to counter that a physically bigger magazine and you either carry less or even more weight. A 3rd option would be specialized bullets. Many are only practical for larger projectiles, are expensive, and may be less effective against certain targets than regular solid ones. For general magazine loaded weapons, switching types mid battle would be problematic, a round is already in the chamber, you have a bunch of partially used magazines, need to keep track. Alternatively increase rate of fire, more bullets rather than better ones. But high rates of fire has its own issues. Weapon overheating Magazines don't hold as much in time terms, or must be large and heavy (drum or belt feeds) Less accuracy than single shot due to recoil Rifling works well to increase accuracy of certain projectiles, but is not compatible at all with others Longer barrels are also generally more accurate and higher velocity, but add weight Higher capacity (or larger bullets) magazines are heavy, and generally slower to remove and insert (reloading). Adding scopes, lights, etc. is a lot of weight Attempting to max everything would result in a very heavy weapon, with uncontrollable recoil, and needing lots of ammo to be hauled around. Completely impractical if anyone gets you in close quarters, and maybe more suited for a tripod or vehicle deployment (as most heavy machine guns are). Working on damage only however would be like an anti-material rifle, accuracy and decent damage a sniper, rapid fire a SMG and a combination an assault or battle rifle, and all of those are useful and not complete replacements for each other. When it comes to graphics I do not think all aspects need to be visual, and if you only have a limited number of "steps" then its not too much. Have a base image, than overlay one for the barrel length, one for the scope, magazine, etc. For Armour similar things apply and I don;t think as many options are needed. Lightweight kevlar may stop knifes, handguns, smg's, shotguns etc., but wont do much against the more powerful snipers, rifles and machine guns. Heavier armour is will seriously impede mobility and not much good for stealth. A basic helmet will again only provide very limited protection, but large helmets covering the face etc. are heavy, likely to reduce field of vision, hearing, general head movement, etc. There are less options than with weapons, and those are visually different enough to want unique graphics anyway. For graphics that would mean separate sprites and animations for headgear and body, but maybe only 5 or so of each.
  2. SyncViews

    Checking if a DLL is present

    Static linking seems the easiest choice. You could have a separate launcher program that verifies the installation before running the main program. Or you could do dynamically loading. I cant remember if delay loaded DLL's avoid the startup check, but if they do that is simple, just try a LoadLibrary before you call any function in the DLL. If not you would have to not link with it at all and GetProcAddress everything which is a pain unless you have an interface based design with minimum exported functions (similar to COM, so just a "CreateFactory" or such to GetProcAddress). I would question why this is needed though? A user should almost never be able to get into a situation that a DLL is missing and if your trying to cover "all things" then that is basically never ending.
  3. SyncViews

    C++/WinRT

    C++/WinRT is more a replacement for the older Windows APIs in Windows.h, hence "any standards-compliant C++17 compiler" rather than one with special managed extensions. Language integration is done by sticking with plain C calls (like PInvoke) or COM "do the vtable and other c++ features this way" (which I don't think the C++ language specifies but OK...). They do seem to be trying to hide the COM though in the header classes. https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt I don't see any performance claim on that linked Microsoft page (https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/) in regards to normal C++, only that C++ is faster than "any other language option for the Windows Runtime" (C#, etc.)? The only performance gain maybe is if the newer API's made some improvements (less calls, avoid extra buffer copies, std::string/etc. integration) or complete replacements (not sure if there are any. Not seen any plan to replace Direct3D, XAudio2, or even force people off Vulkan etc. in favour of some new WinRT low level API). EDIT: Pretty sure it actually is just another COM API.
  4. Been trying out the sorted array of each component type, think I figured out most things. Is there any functional examples, I just went from bits and pieces? Dealing with deleted entities in a post update sweep means potentially mem moving everything once each frame. Guessing ahead of time the maximun number of each type of component is difficult. Right now I just reserved some very large ranges with VirtualAlloc, which is OK for x64. But I think this is bad practice and not sure every platform has VirtualAlloc equivlant? An entity must create all it's components upfront, so that they just append to the arrays. For references to other components I keep a direct pointer/reference since the memory is never freed this is safe. On access I check the entity ID and if matches great, otherwise I can reverse linear search. Even with short lived entities like projectiles should only be a couple of steps. Something like: T* ComponentManager::get(EntityId id, T *hint) { if (hint->id == id) return hint; auto i = hint; while (true) { if (i == data || i->id < id) return nullptr; --i; if (i->id == id) return i; } }
  5. You have to remember that an LCD screen is literally a grid of pixels, it only has one resolution. So the scaling needs to happen somewhere, better where you can control it. Chances are it upscales until one dimension matches the monitors, then fills the other sides with some sort of background. But you have no control over this (there are settings somewhere in the AMD/NVIDIA/Intel control panels, plus I believe the monitor itself if it gets a wrong sized signal). The algorithms used for upscaling blur the image, since the scaling is often fractional (e.g. 2.25 for 480->1080), and will be visible at any normal display DPI. As such most of these will also do some form of scaling as well, so you need to decide what you want. To keep the games "viewport" the same size, you either get some blurring, or scale only integer amounts with a border around it. Visually the best result would be to change the viewport size to match, if you are say following a player character moving around a larger level that is easy, for some others it is not really practical. Also as a player, most of the time I prefer borderless fullscreen, because alt-tab is instant that way, while switching exclusive mode is fairly slow. Switching resolution also tends to mess up my other displays with chat, browsers, etc. for some reason.
  6. SyncViews

    RTS Unit Production

    Pretty situational even then. I certainly do not want an auto built harvester that just goes and dies again, and assuming I have some other harvesters remaining there is a reasonable chance in the short term I want combat units first to deal with the problem.
  7. You will need to use the Android API BroadcastReceiver and registered with SMS_RECEIVED_ACTION (can be done statically in XML). For Unity you should be able to access those by using a plugin, see https://docs.unity3d.com/Manual/PluginsForAndroid.html. However, Id note that as a Android user, generally Id not give some random game off the app store the RECEIVE_SMS permission required for that. Is your purpose to validate the phone number of a user account? You can get the number with TelephonyManager but again it needs a permission (READ_PHONE_STATE). Both RECEIVE_SMS and READ_PHONE_STATE are considered dangerous permissions and may be denied and even revoked after installation.
  8. The fact people in the games industry a job do not just reject job offers with such terms, demand changes, or quit existing jobs, already tells the business that the employees are happy with those terms. This is especially true in many development roles where replacing someone that quit has a significant cost to the business, as both finding a suitable replacement and getting them up to speed can easily take months, so a business will seek to avoid high turnover. And I can certainly say if I got the sort of salaries I saw, or they routinely exercised the contract for unpaid overtime, weekends, etc. I would certainly not stay in my current job. The business knows this and so does offer a good pay deal, perks, and almost never exercises the contract to demand unpaid overtime (for all of their developers and other technical roles).
  9. Like I said, id look at it as getting paid more to do something you don't really want to do. If the deal I got was not significantly better than what the game jobs offered at the time, and other things (location, career opportunities, etc.) were equal, Id leave for a games programming job. Or similarly for something in the tv/film industry, middle ware, or various other things I have seen around. So my employer has to offer a better deal to stop me from doing so.
  10. While that is true, they are doing something they (hopefully) like doing so it balances out. And it is generally still way above the national averages. Id think of it more as people doing things they don't like doing as much, demand better more in order to do so. Certainly if I didn't feel my current deal and career options were competitive, I could easily find projects Id be just as interested about elsewhere, which in turn means my employer will offer better terms to retain staff since replacing people that leave with new hires is slow and costs the business a lot.
  11. SyncViews

    RTS Unit Production

    I can't really think of a game where that is suited. Some RTS's do have near continual production of something or other, but generally Id still want a certain number and prioritise shift rapidly. I wouldn't use such an automatic production method in a turn based game either, plus I generally have more time there to consider what to do with my resources. One thing however I have liked in a few games is when things can be queued without the resources being ready at that time. For example to take the grunts, I could just queue 6 even if I only have 200 gold right now, and they will be built as resources become available. Its generally better to start production as soon as possible (in games where unit recruitment takes a notable amount of time), and stored resources are not doing anything useful, but at the same time Id rather not have to keep going back repeatedly to queue the next one manually. The ones I can think of right now (Supreme Commander, Homeworld for RTS, for turn based stuff like Civ works this way on a per-city level, research, etc.) would take resource during production rather than upfront, but pausing the queue until there is enough resources in one go would also technically work. Id note that even in those games, it is always best to not queue more in parallel than you have resource production, because getting 1 unit now and another later is generally better than getting 2 units slowly.
  12. Location, experience, full time/contract, QA vs developer, different platforms/languages, etc. is relevant to any industry. But from what I have seen while looking around, opportunities for game developer jobs were substantially less than what I get (enterprise software), with most other things similar. The fact I even considered them I think speaks a lot for that difference being because people in those roles are prepared to do so for less, while people working on boring software that almost nobody really cares about unless they are complaining are more likely to take a "highest bidder" approach. Maybe people going into games also hope to do their own thing rather than just what the corporate bosses feel is important, but having looked at some jobs, done some interviews etc. I'm not sure they actually would generally get more freedom.
  13. I did think of some of that (see my code in https://www.gamedev.net/forums/topic/698453-recommended-implementations-or-examples-for-entity-component-system/?do=findComment&amp;comment=5388060 ). A deletion list is fairly straight forward, and something I've often used (to avoid invalidating array iterators during iteration). It would work for 3 or more arrays as well. But how exactly are you handling the deletion in this case? I figured it would have to be done by shifting all the other items along, which could be a big memory move and invalidates any pointers. Putting something else in that location makes it unordered which would break my loop. Do you have a clever scheme for when entities need to reference each other? I thought about it and the "exceptional case" seemed to actually be "most interesting objects". e.g. a homing missile/projectile needs to get its targets current position (and maybe velocity, etc.), likewise anything doing the shooting. Repair/logistics units also have a target, infact I think most units will have a target they are doing something with most of the time. The best I came up with was to binary search each relevant component every frame. Some things might also deal with sets of entities. For example a group of units (e.g. formations). But think that can be made fairly efficient. The idea I had there being to keep the set ordered, then for each needed component binary search for the lowest and highest entity ID, then loop through that subrange.
  14. I think that matches pretty well. But also, on several projects I have worked on (not on the DB side unfortunately) the same sort of things have been performance issues with indicies/foriegn keys and the performance of insert/delete, and selects with many joins. It is for an RTS type game, so can't really deactivate (non-decorative) stuff just for not being on screen. My original OOP code did however track entities on a per chunk (e.g. 64x64 tiles) basis, to aid with entities locating each other, projectile collision detection, etc. and provide a quick pass to get relevant objects to render, so will likely be wanting to keep something similar. For now to figure ECS out though just thinking do a quick Space Invaders like game so things going off screen can generally die. So a component can have the entity id sure so that physics.entity != ai.entity is OK, but doing some `component_manager->map.find(entityId, componentId) or similar (map per entity, map per component, etc.) is expensive, which is what I have been wanting to avoid. e.g. how in that example do you get the data from physicsComponents so that renderComponents can render in the right place? How does aiComponents effect physics stuff, like turning and accelerating? This seem like maybe an OK compromise, although it still seems to require a lot of map lookups and prevent optimisations people talk about. What are you thinking of with this flag? Best idea I had was to say that once an entity of components <A,B,C,D> had been created, that that entity Id was fixed forever to have exactly components <A,B,C,D>, and could then be reused later (and thus be in the right place in any lists). But not sure that is a good idea as being able to have varying combinations of components seemed to be a major point of doing it this way in the first place. At least conceptually in an RTS things are getting created and destroyed pretty often, but yes this does not have to mean "new"/"delete". I came up with something based on the system caching idea that was mentioned and I have seen in a few places, not really convinced though since it seems to have many short comings. The basic idea is that when an entity is created, each system is informed. The system can then see if this new entity has the relevant components, and if so, store that entity and its component references for later use. Not cache friendly. Even if components are allocated in big sequential blocks, as soon as some entities get destroyed and new ones created will be shuffled. Because each entity is now many components rather than a single OOP class (where some Entity::update() might get one cache miss but then the whole Entity is in cache), this seems like it could be a bigger issue as access will be to random locations to read or write a small number of bytes. Generally all the components for an entity seem to be multiple times more memory. I don't think the total amount of memory should be too important though. There is a lot of map look ups to create an entity. Creating the entity itself needs 2*number_of_components map accesses. One set to get the component object, and another set to store in Entity. Every system needs to make 1 or more map accesses to see if the new entity matches that systems requirements. Normal problems with deleting an entity. Could be solved by a dead flag, and then processing post-update, but removing the entity from the list in every system is a lot of work. On the plus side: Components for existing entities are never moved, so it is OK to store a reference/pointer to them to avoid the component map. Accessing a component map on every update is avoided.
  15. Presumably you are already using the depth buffer to allow drawing out of depth order (rather than sorting everything back to front perfectly)? If you render the opaque parts of the scene with the normal/default D3D11_COMPARISON_LESS without a pixel shader, you should get all the final depth values without doing all the heavy work a pixel shader would normally do. Then if you use D3D11_COMPARISON_LESS_EQUAL and do your normal scene draw anything that would have been hidden by a later draw (overdraw) will fail the depth test. For this to be beneficial, the GPU time saved by skipping the pixel shaders and output in the 2nd pass will need to be greater than the extra cost of doing all those draw calls, vertex shaders, etc. twice (e.g. if you did render your scene front to back, a depth pre-pass would reduce performance since there were was no overdraw in the first place).
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!