Jump to content
  • Advertisement

frob

Moderator
  • Content Count

    11618
  • Joined

  • Last visited

  • Days Won

    25

frob last won the day on October 14

frob had the most liked content!

Community Reputation

45766 Excellent

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

Recent Profile Visitors

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

  1. frob

    Bare bones AAA team

    There's no one-size-fits-all, but it is something you can estimate: Look at similar projects and use them as a guide. These days a AAA game costs on the order of $500M to create, with about $200M spent on development costs. Full-sized big games (that aren't quite AAA) cost on the order of $50M-$100M in development costs. If you want to say "a game like ${A} or ${B} or ${C}" you can get closer, go do some research on those titles. If you can't find firm numbers, look at the size of development teams and multiply by salaries, look at published operating budgets for publicly traded companies, look at financial statements you may find online, look up estimates from aggregators like VGChartz. If all three are similar to what you want to make and they cost $75M, $45M, and $60M each, then you can use that for your own estimates. Don't forget that a startup has additional costs since they don't have a large library of resources to rely on nor existing piles of hardware, nor a history of working together in productive ways. Each of those has more costs. Game credits can be quite revealing.
  2. There are an enormous number of websites and there are some book references, but as you point out, every game is different and has different needs.Further, networking technology is constantly evolving. Practices that were ideal in the era of dialup were replaced as broadband became more common. Practices common as broadband started were replaced again as networks evolved. And different game styles lead to different networking models; a slow turn-based game where a single event crosses the wire every few seconds is radically different from a Battle Royale style game with a hundred players and potentially thousands of objects where visibility, distance, cheating potential, and other rules all come into play for what gets transmitted and what stays put. These days games tend to rely heavily on existing libraries rather than writing raw socket code themselves, so brush up on those. If you're using an engine like Unreal or Unity or tools like GameMaker:Studio or GameSalad or similar, they all have networking components built in you should learn about. You might need to learn the underlying technologies as well if you're involved in network programming long term, but in the short term learning how your current game engine does things is generally enough.
  3. frob

    Github and Viruses

    The classic rule is 3-2-1 for data backups. At least 3 copies that are true backups. At least 2 media. At least 1 off site.
  4. frob

    Delayed shots Concept

    Requiring you to lead your shots has been a staple of game design since the 1970s. Entering into the early 1980s games like Missile Command were entirely based around the mechanic. Some games use it quite effectively. If you're on the defensive, the lead time can allow you a moment to escape unharmed. If you're on the offensive, the lead time can let you block predicted escape routes. For non-gameplay purposes, the delay can help mask network latency or data loading delays. It isn't always fun, so you must try it out and see how it helps or hurts your specific game.
  5. Find the mechanics that make your game fun and stick with it. Is your game about strategy, about skilled decision making? If so, stick with that. Is your game about rapid twitch response or precise aiming? if so, stick with that. A few years ago games tried to mix gameplay with some "skill and action", resulting in QTEs. Several games had QTE-or-die events that proved HUGELY unpopular. Instead of adding an element of skill, they forced players to memorize a series of button mashing that served no gameplay purpose at all. Several games that were accessible to players with limited mobility were otherwise wonderful, except the limited mobility players would always fail the QTE. Thankfully these days games have mostly abandoned them, as designers (as well as players and journalists) are returning to the fact that games should stick with their core mechanics.
  6. frob

    What is MTO?

    Looks like an interesting project. I'd beware of "massive", because massively multiplayer DOES have a meaning. There is a transition point, somewhere between 10,000 and 100,000 concurrent players online, where the infrastructure transforms. Below that number it is something a small team can handle. After that number it is something requiring multiple data centers scattered around the globe, with truly impressive infrastructure that cost a fortune to keep running day to day. Below that transition point is not massive, but instead a regular multiplayer online game. It may be online, it may feel large to the players and developers, but that's not what the first M in "MMO" refers to.
  7. frob

    Need Feedback on Portfolio?

    I'd make the title area and the contributions labels links as well. If you're looking for visual changes, the labels for what you used has color changing backgrounds and change the mouse cursor, yet do nothing. I thought they were links. You've got an overuse of fonts, colors, and visual styles that screams of amateur design, but since you're applying as a programmer it doesn't hurt TOO badly, and it's better than the opposite problem of a flat text page.
  8. For the entry level, build some simple games on your own. Very small completed games are better than major projects that are incomplete. Building your own games and posting them on your own web site shows potential employers that you have strong interest, and it shows that you can do the job. It isn't strictly necessary for programmers to build a portfolio, many people are hired without them. It allows you to explore the field on your own so you can verify yourself if you fit in the industry, and it lets employers see a few small projects that show what you can do as a beginner. Feel free to use tools. Unreal and Unity are both free for this type of work, and they greatly simplify your work. And finally, make sure you know C++. Many schools have dropped it from their programs, but it remains the core language for systems-level work.
  9. frob

    Need Feedback on Portfolio?

    The site is visually busy. I certainly wouldn't call you back if you were applying for a job as a graphics designer. It tells me enough relevant information, and would help if the interviewer actually opens it up before the interview. Few will do that.
  10. frob

    Fractals in games

    Historically in the late 80's and early 90's many projects relied on fractals because they had tiny resource requirements up front. Many demoscene programs relied on fractals for long-running visuals. These days there are many brushes for textures and many modeling program features that use fractals to generate interesting elements in game resources. Sometimes they appear as part of the textures used in plant foliage, or in feathers or fur or hide. Sometimes they make up part of the wood textures, or stone, or clouds in the sky. Sometimes they provide fine variation in reflection maps and surface normals, or assorted other visual effects. They aren't the same as a deep zoom on a Mandelbrot image, but they do provide visual distinctiveness in the finished assets.
  11. frob

    What makes a game an "indie" game?

    Yup, "indie" and "independent" are thrown around casually and can mean many different things. An independent studio generally means a full-fledged business that is not affiliated with a major company like EA or similar. They can be small with just a few people, or they may be large with several hundred people. Often these companies do ports or help provide assets and development support for larger projects. Hobby projects are people working on their spare time, making a project because they want to. Generally they have no money, no resources, and engage in many legally risky practices like not having a corporation set up, not assigning rights so everybody maintains their own ownership of their contributions, and more. When someone says "a group of us are making an indie game", I generally assume they're working a hobby project that is unfunded and will never see the light of day. When someone says "We're an indie studio working with (some publisher)", I assume they've got a multi-million dollar budget and are working on a low-budget professional project. Another term people have used but don't typically use recently is "homebrew", which has it's roots in sometimes-illegal liquor production. Homebrew games were often developed to run on unauthorized hardware, often requiring exploits, possibly-illegal hacks, possibly-illegal reverse engineering, and possibly-unlicensed software and hardware. It was neat to see someone's game play on a GameBoy Advance or similar systems, or programs that only run on console emulators for devices from yesteryear, but they were always somewhat of a murky area.
  12. Is this part of your system going to be cache constrained? Somehow I doubt it. It looks like you're working on a physics system that relies on ECS. What you've got there is an all-to-all test that presents the worst case of collision detection. How is your system open to extension? You've got several types of colliders, you've mentioned a circle collider and a line collider. There are many other natural collision objects, since those are 2D probably rectangle, triangle, general polygon, and sprite/shape based collision objects will show up as well. In the first code block at least you're working generically, an entity could use any arbitrary collider object. You could implement that as objects derived from a common base, or as an index to the type of collision objects in your system, that doesn't particularly matter. You should probably verify that it actually has a collision object, and if not, automatically fail the collsion test (if it has no collider it cannot collide). You'er also testing each comparison twice, once is an A-to-B test, then again as a B-to-A test. Regardless of the collision objects, you're working with an all-to-all test. That's only going to work for a relatively low number of items. Physics systems usually use a broad phase (as a very fast general-purpose filter) and then a narrow phase (testing the actual items). I'd start out with a proximity based process that only tests things that are immediate neighbors. For most games, most items have 0 collision neighbors so they don't get tested at all. A few items have the potential to collide. That test is often run with the spatial grid, never touching the details of the objects. My guess is that you're over-thinking it. Modern machines have about a billion instructions available every frame. First write something then works. Then make it work well. Then, only if necessary, make it faster. Assuming you only have a few hundred objects you could probably have a naive solution that runs the all-to-all test you've written, although you should clean it up to not test against itself and not duplicate A-to-B and B-to-A. Adding a broad phase test to only test items that are neighbors could likely handle many thousand collision tests per update without any further optimization.
  13. Just based on specs, the Compaq looks like a computer from 2009 (10 years ago), the Acer looks like one from 2015 (four years ago), so you can bet that assorted hardware will also be newer. The Compaq looks like a computer from 2009 (10 years ago), the Acer looks like one from 2015 (four years ago), so you can bet that assorted hardware will also be newer. The Acer's got a much better processor with double the cores plus much better i7 cache, and double the memory. Couple that with being half the age, so likely having faster memory, faster bus, and faster drives. Neither is a stellar machine, and the memory looks low even for the years they were released. Back in 2009 machines we were buying at 16GB or 8 if saving money, in 2015 we had transitioned to 32GB at work for just about everyone.
  14. Regarding the choices on data types, all data types have tradeoffs. Linked lists are no different. By far the biggest advantage of linked lists (and container types that use them) benefit from stability of objects. You can continue to use pointers/references to objects without worrying that the objects will move as the container is modified. There are drawbacks, such as cache inefficiencies and overhead for maintaining the links, but those can be reduced through implementation details like using memory pools and indexed chains of nodes, and if you are willing to work with special case code instead of the general purpose standard library, in some cases it can be eliminated. The C++ vector, an implementation of a dynamic array, should generally be your data type of choice. This shouldn't be a surprise to anyone who has studied computer science or computer architecture, as the linear format has extremely low overhead and very high predictability for the cache. However, it comes with drawbacks, perhaps the most significant is the difficulty with resizing when elements are added, and the space wasted when elements are removed. And note that there are data structures designed for the behavior in between, in the C++ standard library this is the deque class. While implementations vary, It is frequently implemented as a combination of the two, a linked list of dynamic arrays. The array is divided up into pages. Adding and removing items tends to modify only that page. When a new page is added or one is removed, they are removed from the linked list of pages. Advancing beyond the boundaries of a page will --- behind the scenes --- move the iterator to the adjoining page so you can continue immediately. It gets many benefits from cache friendliness and reduced overhead from the dynamic array parts, and gains significant stability (though not absolute stability) through the linked object parts. And if those built in types from the standard library aren't enough for you, you are free to implement your own custom functionality rather than relying on the general purpose functionality. In games I generally try to look for the standard library first, and only when there is an actual reason I turn to non-standard container types and non-standard algorithm implementations. The standard library is good and full featured in the general case, but the library creators knew even at the outset that special cases meant general purpose would be a bad fit. General purpose libraries are not universally good. But the general purpose libraries are generally good, and in most general programming you should use them when they fit.
  15. I think the interface used by the standard library is quite solid for it's stated purpose: It provides a general purpose library of functionality. It does that quite well. The deep templates-of-templates-of-templates that some implementations use is an implementation detail. There are implementations like STLPort and EASTL that do not follow that detail. Further, many implementations use those deep nestings to take advantage of a feature of C++ not present in the other modern languages: Extreme levels of eliding optimizations. The biggest reason you don't get introspection features in C++, features like reflection and properties, is because the c++ language was designed to strip out EVERYTHING that wasn't used. In order to provide many of those modern features the original code must be available, especially when implemented as templates or otherwise work with replaceable types. When dealing with the C++ standard library and if you debug in to nested type after nested type just to ultimately resolve down to a single function call or a single lookup, if you look it up in the optimized release build you typically find it vanishes completely, the nesting doesn't exist, it is replaced only with the function call or the lookup directly. This would fail terribly with many modern features that would allow runtime systems to swap out or modify behavior of those intermediate layers.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!