Popular Content

Showing content with the highest reputation since 09/14/17 in all areas

  1. 5 points
    Tons of commercial games are already being made in C#. If you're more focused on lower-level languages that can be direct replacements at the system programming level, then I'd say that since the demand for that is dropping, C and C++ are adequate. Maybe Rust/Go/Swift will be a worthy competitor in future, but I don't think there is enough critical mass.
  2. 5 points
    Because, as mentioned, scenes can vary widely, the common way to decide how many shadows you will have is derived from a performance goal on a specific target spec. In other words, determine how many shadows you can have while maintaining X FPS on Y hardware. The reason you should be using an algorithm like this to determine your own metrics is because not only do different scenes in different games come with different performance compromises, your own implementation of shadows may perform very differently from others'. Your question is useful for allowing you to consider how optimized shadow maps must be in other games and for you to consider how much you have to do to get there, but if you were asked right now by a boss to estimate how many shadows you can use you would use the above-mentioned process. To give you actual stats and an idea of the optimizations used, here is what I did on Final Fantasy XV. We had a basic implementation likely matching what you have, with cube textures for point lights and different textures for the rest (4 textures for a cascaded directional light and X spot lights). The first thing I did was improve the culling on the cascaded directional light so that the same objects from the nearest cascade were not being needlessly drawn into the farther cascades. If you aren't doing this, it can lead to huge savings as you can avoid having your main detailed characters being redrawn, complete with re-skinning etc. Next I moved the 6 faces of a cube texture to a single 1X-by-6X texture. So a 512-by-512 cube texture became a single 512-by-3,072 texture. Although you must write your own look-up function that takes 3D coordinates and translates them to a 2D coordinate on this texture, it comes with a few advantages in caching, filtering, clearing, filling, and most importantly it prepares for the next big optimization: a shadow atlas. Now that all shadows were being drawn to 2D textures, I created a texture atlas for all the shadows except the cascaded ones. A single large texture for all the point and spot lights. It was 2,048-by-2,048 first but could grow to 4,096-by-2,048 if necessary. Putting at the point and spot shadows into a single texture was a huge gain for many reasons, but one of main gains was that we had access to all the shadows during a single lighting pass, which meant we could draw all the shadows in a single pass instead of many. At this point our limit was simply how many shadows could be drawn until the texture atlas got filled, sorted by priority largely based on distance. As mentioned by MJP, an important aspect of this is to cull all six faces of a point-light shadow. Any shadow frustums not in view meant less time creating shadow maps and more room for other shadows in the atlas. Next, I wanted the shadow maps to have LOD, as the smaller shadow sizes would allow faster creation, and smaller shadow maps meant more shadows could fit into the atlas. Each shadow frustum (up to 6 for point lights and 1 for each spot light, where each shadow frustum at least partially intersects the camera frustum—any shadow frustums fully outside the view frustum would be discarded prior to this step) was projected onto a small in-memory representation of a screen and clipped by the virtual screen edges. This sounds complicated but it is really simple. The camera's world-view matrix translates points into a [-1,-1]...[1,1] space on your screen, so we simply used that same matrix to transform the shadow frustum points, then clipped anything beyond -1 and 1 in both directions. Now with the outline of the clipped shadow frustum in -1...1 space, taking the area of the created shape gives you double the percentage of the screen it covers (represented as 0=0% to 2=100%). In short, we measured how much each shadow frustum is in view of the camera. Based on this percentage, I would drop the shadow resolution by half, or half again if even less was in view, etc. I believe I put a limit at 64-by-64. If you play Final Fantasy XV, you can see this in action if you know where to look. If you slowly move so that a shadow from a point light takes less and less screen space you might be able to see the resolution drop. Now with the shadow-map LOD system, most shadows are drawn at a lower resolution, only going full-size when you get near and are looking directly at the shadowed area. Because this actually affects so many shadows, the savings are significant. If you decide to keep the same limit on shadows as you had before you will find a huge gain in performance. In our case, we continued allowing the shadow atlas to be filled, so we were able to support double or more shadows with the same performance. Another important optimization is to render static objects to offline shadow maps. A tool generates the shadow maps offline, rendering only static objects (buildings, lamp posts, etc.) into them. At run-time, you create the final shadow map by copying the static shadow map over it and then rendering your dynamic objects (characters, foliage, etc.) into it. This is a major performance improvement again. We already had this for Final Fantasy XV, but since I added the shadow LOD system I had to make the offline static shadows carry mipmaps. It is important to note that the shadow mipmaps are not a downsampling of mip level 0—you have to re-render the scene into each mipmap, again with some lower limit such as 64-by-64. All of this together allowed us probably around 30 shadow maps with the ability to dynamically scale with the scene and without too many restrictions on the artists. Shadow maps were sorted by a priority system so that by the time the shadow atlas was filled, the shadows that had to be culled were distant, off-to-the-side, or otherwise unimportant. L. Spiro
  3. 4 points
    Both or niether, as needed. Cache coherency is great, but it's trivial to design cache-coherent algorithms in a vacuum ("oh, just put all the components in a big array, update them in a loop, DONE"). It's much harder to design cache-coherent algorithms that adapt to actual practical use ("oh, it turns out that this component needs to read the position, which means now we might be blowing cache coherency to read that from a different component now, or blowing it to copy it into this component earlier," et cetera). What you want to do is design how you store your data in memory in a fashion that is efficient for the way you will access and transform that data. "Access," importantly, includes more than just how the memory will actually be fetched by the CPU, but how you will actually get at and use, connect, et cetera, that data in your APIs. If you bend over backwards to make some components stored in a big cache-coherent array, but you never actually need to update all those components at once, have you really gained anything? Worse, if by doing so you've made it vastly more complex to use those components at the API level, have you actually improved anything? The reason that there are no generalized, broad, great answers to this problem is that the devil is in the details. So consider the purpose of each component or other piece of data or functionality you're adding to your system, and how you want to interact with it at the API level, and how you need to interact with it at the implementation level, and weigh the pros and cons of every available approach with that in mind. And make a decision for that problem that might be different than the decision you'll make for the next. In general, I'd aim for cache coherency when I can, as long as it doesn't sacrifice usability in any fundamental way.
  4. 4 points
    No, that is not necessarily the spiral of death. Most games require far less time doing the update than it takes for the time to pass. Your numbers show this quite well, if you think about it. In your example the fixed update is 0.5ms where it runs as many fixed updates as needed to catch up. Also the rendering takes 4 ms. Because rendering takes at least 4ms you will always need at least 4 simulation steps for every graphical frame. But in practice you've probably got much longer than that, especially if you're using vsync for as a frame rate limiter, which most games do. On a 120Hz screen you've got about 8.3 milliseconds per frame, so you'll probably need to run 16 or 17 fixed updates, and they must run within 4 milliseconds. On a 75Hz screen you've got about 13.3 milliseconds per frame, so you'll probably need to run 26 or 27 fixed updates, and they must run within 9 milliseconds. On a 60Hz screen you've got about 16.6 milliseconds per frame, so you'll probably need to run 32 or 33 fixed updates, and they must run within 12 milliseconds. In these scenarios, it is only a problem if the number of updates take longer than the allotted time. The worst case above is the 120 Hz screen, where an update processing step needs to run faster than 0.23 milliseconds; if it takes longer then you'll drop a frame and be running at 60Hz. At 75Hz the update processing step must finish in 0.33 milliseconds before you drop a frame. At 60 Hz the update processing step must finish within 0.36 milliseconds. Your frame rate will slow down, but as long as your simulation can run updates fast enough it should be fine. If it drops to 30 frames per second then a 0.5ms processing step has more time, up to 0.44 milliseconds. If it drops to 15 frames per second then the 0.5 ms processing step has up to 0.49 milliseconds per pass to run. As long as your simulator can run a fixed update in less than that time the simulation is fine. You ONLY enter the "spiral of death" if the time it takes to compute the time interval takes longer than the values above. Since typically the simulation time is relatively fast it usually isn't a problem. If the time it takes to compute a fixed time step is longer than the times above, and if you can't make it faster, then it may be necessary to change the simulation time step. Usually the only issue with that is the games feel less responsive, feel slower. Many of the older RTS games had a simulation rate of 4 updates per second, even though their graphics and animations were running at a much higher rate. Even that may not be much of a problem. It all depends on the game.
  5. 4 points
    Unfortunately it's lacking a lot of stuff which most programmers want. It's fascinating that one of the statements in the Jai Primer is "Automatic memory management is a non-starter for game programmers who need direct control over their memory layouts" when it's increasingly clear that game programmers are demanding that level of control less and less often. Unreal and Unity are garbage collected! I'm sure Jonathan will be very productive with it, and it has many good aspects, but I don't see it ever seeing serious use by more than a double-digit number of developers.
  6. 4 points
    In the past, I never bothered with marching different meshes for different terrain materials. I just marches the terrain as a single mesh, then used vertex colors (generated after marching the surface, using various techniques) to blend between terrain textures in the shader. Something like this (very quick example): With a tri-planar shader that displays different textures for the top surface than what it displays for the side surfaces, then you can just paint the v-colors (either procedurally, or by hand if that is your wish, in a post-process step) for different materials, and the shader will handle blending between the types and applying the tri-planar projection. A single color layer provides for 5 base terrain materials, if you count black(0,0,0,0) as one material, red(1,0,0,0), green(0,1,0,0), blue(0,0,1,0) and alpha(0,0,0,1) as the others. Provide another RGBA v-color layer and you can bump that to 9. Doing it this way, you don't have to be content with sharp edges between terrain types, since the shader is content to smoothly blend between materials as needed, and you don't deal with the hassle of marching multiple terrain meshes.
  7. 4 points
    The letter/digit keys have no constants because their value are the ASCII values, so you can just use a character literal 'A' etc.
  8. 4 points
    I would probably use the entity ID as a foreign key inside the component structure. That's also what most of the "ECS" dogmatic blogs like T-machine seem to talk about doing. e.g. struct DamageOverTime { int entity;//foreign key float damagePerSecond; float timeLeft; }; struct DamageMessage { int entity; float damage; }; struct HealthSystem { void Process( const std::vector<DamageMessage>& ); }; struct DamageOverTimeSystem { std::vector<DamageOverTime> components; void Process( float deltaTime, HealthSystem& health ) { std::vector<DamageMessage > results; results.reserve(components.size()); for(auto c = components.begin(); c != components.end(); ) { results.push_back({c->entity, c->damagePerSecond * deltaTime}); c->timeLeft -= deltaTime; if( c->timeLeft > 0 ) ++c; else // fast erase { std::swap(*c, *(components.end() - 1)); components.pop_back(); } } health.Process(results); } }; You can put as many components in there as you like for the same entity, and they will stack additively (two 3-damage-per-second components will do 6 damage per second). If you wanted to change the game rules so that they stack multiplicatively (two 3dps components results in 9dps), that's a simple tweak: void DamageOverTimeSystem::Process( float deltaTime, HealthSystem& health ) { //group components by entity std::sort(components.begin(), components.end(), [](const DamageOverTime& a, const DamageOverTime& b) { return a.entity < b.entity; }); std::vector<DamageMessage > results; results.reserve(components.size()); //multiply together all the damage values for each entity int groupedDamage = 1; for(auto c = components.begin(); c != components.end() ) { int entity = c->entity; c->timeLeft -= deltaTime; groupedDamage *= c->damagePerSecond; if( c->timeLeft > 0 ) ++c; else c = components.erase(c); //end of a group of entities if( c == components.end() || entity != c->entity ) { results.push_back({entity, groupedDamage * deltaTime}); groupedDamage = 1; } } health.Process(results); } In this example I've not given the DamageOverTime components their own component-ID. If you can somehow cancel these effects (e.g. killing a vampire removes every life-drain spell that they've cast) then you'd probably need component ID's too so that you can keep track of them. Also note that you don't need a big framework to do ECS. I just did it in plain C++ in a few minutes and IMHO, writing ECS style code manually (without a framework) results in cleaner, more maintainable code and a better understanding of the data flow in your program
  9. 3 points
    So after coming across this thread about JAI, I got to thinking why haven't more people embraced D as the programming to use, especially over/instead of C++? But just in general, will any language ever replace C and C++? Or is the amount of inertia and legacy code too insurmountable for any other language (of that sort) to be fully embraced (ie. not be a niche language)?
  10. 3 points
    Languages don't really make you a better programmer, concepts, techniques and algorithms do. Different languages are a proxy for this, as they bundle up opinionated implementations of a selection of concepts, techniques and algorithms. What you want to look for are different languages that espouse complimentary sets of concepts and techniques, and solve challenging problems using similar algorithms in them—so that you get a sense for how different languages (again, as proxies for concepts and techniques) occasion different implementation strategies. Good question, though.
  11. 3 points
    Hey guys, long time no post! Funny sequence of events that led to me checking in today. My take: nothing will ever "replace" C++, because nothing will ever have the same degree of critical mass/hegemony that C had and C++ inherited. The language ecosystem will be more diverse and varied, with individual languages and their code being more generally portable, and practitioners more able to switch toolsets because the norm today is to have high-quality, cost-free, often open sourced implementations. My other (and hotter!) take: JavaScript already "replaced" C++ as the language in which the largest subset of user-facing applications, and even server-side infrastructure, is written in.
  12. 3 points
    C++ is also a replacement for C and it already exists. I don't think it's worthwhile looking at any language in a vacuum where other alternatives are ignored.
  13. 3 points
    Wake me up when it actually ships.
  14. 3 points
    Asking if people want better anything they will always say yes. If you know how to make a game with better writing and linear elements then I really recommend making it. Just don't be surprised if what you thought was a better story is disliked by players, sometimes people have a different idea of what is better. I for one would like to see more story based games, so you already have my interest. What ever you can safely afford and a bit more. Different experiments have different costs, emotional stories can often lead to the player feeling depressed when playing a game, up to the point where they just stop. So if you plan on doing these I recommend testing the game often on test players to see how they are impacted. This war of mine is a good example of a game where a heavy emotional story limits game play, most people I know didn't play the game more than a few tries. It's a good game but they pushed the emotions of the player past the breaking point.
  15. 3 points
    Important distinction here: The DeWitters game loop actually uses the 'interpolation' to extrapolate a view position. This is easier to implement, as it doesn't need to buffer past states, but is basically rendering things slightly in the future based on their current velocity, which can result in some marginally incorrect renderings when objects change direction, which are usually not visible. The Gaffer On Games game loop uses proper interpolation, but that requires keeping both the old state and the new state, and the view position is the interpolated value between them. This doesn't produce wrong renderings like DeWitters, but it is more complex, and it basically renders things slightly in the past. Both have a similar idea of tracking how far they are through the 'next' update step when rendering in order to reduce visible temporal aliasing, but both have significant differences, and their own pros and cons.
  16. 3 points
    Easier is extremely important in the starting phase. In the 15+ years I've been programming, majority of those years has been devoted to game programming and it wasn't an easy ride by any means. I've noticed that a lot of books, and tutorials will over complicate the process of game programming by either over engineering from the start, or using methods that are not beginner friendly causing even more confusion. There is a good reason that many new programmers never finish a game, or even stick around for a long period of time. I've known people who've quit programming all together because it was just too much of a struggle to wrap their head around all the many concepts to what goes into creating a full game. It didn't matter if they read the 1000 page book, or watched the "best" YouTube series showing them how to create games because they still couldn't wrap everything together in their mind on how it works, and why it works. When it comes to learning not everyone looks at the same material and can see and understand what is going on. Some people take much longer to grasp the material, while others understand quickly what is occurring. Game programming isn't easy, this is why we see a market for things like GameMaker, and other such tools. There is a market to create games, but many people are not willing to put the many years into learning. One of the main suggestions I've always said is that the more you code, the more you'll learn. Truth be told I got most of my knowledge from doing, and learning from other people. I would learn a basic concept and code several little programs, and move onto the next concept repeating the same process until I understood how to use it. If I had questions, I could ask seasoned programmers for help to understand the problem. This takes a lot of time and devotion to the craft, and will pay off if you progress through. I'm still going to stick with my initial suggestion, keep it simple. You're better off creating different classes for what you need as opposed to getting into a big web during the starting phase. I've never had an issue in which I couldn't make an RPG, World Designer, or any other project because I didn't use components. This is a misconception that it's required. In my prior example, you can create a basic enemy class with general attributes, and even abilities, without doing any of this. I've created classes that would pass through enemy IDs that would determine which states the creature would obtain on object creation, and in the attack function, depending on the monster ID, it might double attack, triple, or add poison, ect... You don't need components to do this. Keep it simple when starting out.
  17. 3 points
    "Easier" is important because programming is hard, and learning is hard. Tutorials do stuff like "using namespace std;" not because they think you need insulating from scary knowledge, but because that knowledge is not directly relevant to the thing being taught at that time. Composition as a concept is not hard. However, component-based-entities are a very specific and opinionated use of composition where there is no consensus at all on how it should be done. I'd argue that makes it a very poor paradigm for anyone who doesn't already have a strong opinion on how to proceed.
  18. 3 points
    Well, my book of course :-). It is titled "Development and Deployment of Multiplayer Online Games" (planned at 9 volumes, currently Vol. I is printed, and Vol. II - Vol. III are available as early beta). E-book versions are available on Leanpub: https://leanpub.com/b/development-and-deployment-of-multiplayer-online-games-part-arch, and paperback Vol. I got to Amazon a few days ago. A bit of bragging - "Early Praise" page within the book includes references by such people as Glenn Fiedler, Matt Pritchard, two GDC speakers, and CTO-like guys from more than one billion-dollar company...
  19. 3 points
    I don't think you should have two different transform components, no. You shouldn't implement the physics using the ECS-transform-component eigther. Physics is a vastly complex system that requires (or at least should have) a separate implementation. So optimally, you'd just use the transform-component to communicate between the different system, which keeping a separate view of the physics-world: struct PhysicsComponent { RigidBody* pBody; // pointer to a body aquired from the physics-world upon initialization => could also be queried instead }; struct PhysicsSystem { void Update(double dt) // just to showcase... { world.Tick(dt); for(auto entity : EntitiesWithComponents<Physics, Transform>()) { auto& physics = entity.GetComponent<Physics>(); entity.GetComponent<Transform>().SetTransform(physics.pBody->QueryTransform()); } } private: PhysicsWorld world; }; (This is just some pseudo-code to get the idea across). So essentially Transform becomes a point for communication between different systems. What the physics-system wrote in, you can later read out ie. in the RenderSystem; also your gameplay-systems can just set the transform as well. Entities just register new rigidbodies to the physics-world, but the world doesn't know that an entity even exists, which keeps your physics separated & more flexibel. For example, its pretty easy in this system to exchange your physics with say bullet at some time, while what you originally do creates a sort of tight coupling between those independant modules. As a general consensus, you should only implement the bare minimum required functionality inside the ECS, if possible. Do not use ECS as a basis for physics, rendering, HUD, ... but instead implemented those systems separately, and use the ECS as the high-level intercommunication-layer. At that, it really excells IMHO, but everything more will just result in many of the reasons why people despise ECS. Hope that gives you a rough idea.
  20. 3 points
    A long time ago, it used to be cheaper to sample from a cubemap than to normalize a vector... so there was a potential optimization where you create a cube-map that contains normalized normals, and then to normalize a vector, you use it to fetch a value out of this cube map! These days this would be a terrible idea... But yeah, cube-map lookups have always taken any vector and have normalized them internally as part of the lookup process.
  21. 3 points
    C++ objects are not just a pile of bits - you can't just cast them to another type and do bitwise operations of them. This is undefined behaviour. You may be able to get it to work by accounting for all the details such as vtables, but, it will still be undefined behaviour and your compiler will still be allowed to fuck you over. Either use plain old data structures that can safety be bitwise modified, or, implement a "delta compare" virtual function.
  22. 3 points
    Except that code doesn't find "abac" in the string "ababac". Correctness matters.
  23. 2 points
    The whole point is that you're saying "here is the image I want you to show, and I want you to show it when the graphics system is ready to display it with no tearing or other potential visual artifacts". The graphics system has to wait. You're right in saying that the CPU doesn't have to stop doing anything at that point, and that it can start getting on with the next frame. And that's usually exactly what happens. The interesting part is when that second frame is finished - has the graphics system finished that first frame yet? If not, we either have to wait for that first frame to be displayed before we can send the second, so eventually, the CPU does have to wait on the GPU. Most graphics APIs allow you to tweak this various ways - such as opting to discard and replace a queued frame instead of waiting for it to render, or using extra memory to queue up additional frames so that things are smoothed out if certain frames take much longer than others to be generated. But ultimately any synchronisation involves something waiting for something else. That's what you're asking for when you enable VSYNC. Regarding your actual problem, the thing that I see being wrong is that you're thinking about "when we actually execute the game state update", which is completely irrelevant. All that matters is "how many updates we should have done by now". Your interpolation function should not have the current time in it, because this interpolaton method is not designed to be a function you can call from arbitrary parts of the code. You should be storing the time at the start of the loop, running as many updates as you can to 'catch up' to that time without running any partial updates, and use that remainder - i.e. how much of a partial update you'd have to perform - to inform the rendering system to improve the smoothness of the rendering.
  24. 2 points
    My general recommendation is that to stay relevant developers should learn one new programming language every year. Even better if it is a departure from things already comfortable with, but the key factor is that you keep learning. Right now as a general recommendation, new programmers should first learn ALL of these languages: C++, Java, C#, C, JavaScript, Python, and SQL, and also learn markup languages including HTML, XML, and JSON. In all these languages a programmer should be fluent enough that if handed some code they could read it and expand on it, even if it isn't their primary programming language. In practice an entry level programmer will probably know two or three of them, but they should still learn those they don't know, and continue learning at about one per year. I see it as much the same a doctor must stay current on medical research, or the way a lawyer must stay current on new laws and new precedent, or the way an architect must stay current on architectural codes.
  25. 2 points
    I've seen that type of uptick from web crawlers like search engines or archive snapshots, and from people doing mass captures or mirrors of the site. Usually Google and the big players are careful to rate-limit their requests, it is generally the people doing dumps and mirrors that cause the issues. There are several good Apache modules to help. Two immediately come to miund. First, mod_ratelimit is supported by Apache, and limits transfer rates per connection. A third party mod_limitipconn limits the number of simultaneous connections by a single address, which can also help. Between the two, most of the bulk pulls can have their impact softened. Few will use distributed tools, sometimes they'll be pulling through AWS but even then it is uncommon to see more than 5-10 IP addresses pulling at once.
  26. 2 points
    This has come up periodically in the GDNet forums. My opinions are essentially unchanged since the last time this thread happened. Jai may well represent the pinnacle of productive programming languages for Jon Blow, I don't know and I frankly couldn't care less. I'm not Jon Blow and I don't like his style. I will not adopt Jai personally. Merits (or lack thereof) of the actual language aside, I have a strong problem with Blow's personality and attitudes towards other programmers, and I find a lot of what he says in the videos (and elsewhere) distasteful. To me this just compounds the problem of trying to learn more about the actual project. In the end, I think it's easier to just leave it all alone.
  27. 2 points
    "If you have an "updatePhysics" method on your entity, how does it know about the other entities? It needs something else." - An entity can ask the world, or the physics manager, or some other interface of your choice, for a list of other physics entities. That's one extra object, the same as you'd need if you had a standalone System. Nobody is seriously suggesting that, for a complex physics based game, you'd have your complex physics in Entity::Update or Entity::UpdatePhysics. You'd have a PhysicsSystem that handles it. But that does not require that all your data lives outside of the Entity. Even if you did want your physics data outside the Entity - i.e. the way that most games do, with it tucked away inside PhysX or Havok - that's completely unrelated to how the entity itself is structured. You do not, and never did, require an 'ECS' in order for there to be additional systems that help with complex parts of your gameplay. Entities in old-fashioned systems were never expected to handle absolutely every part of behaviour that affects an entity. They have their own methods and data and they collaborate with other objects to get things done, just like pretty much all software does. The main problem is the constant use on these forums (not by you, but by a series of people) of strawman arguments to support following these entity/component patterns, suggesting that they solve problems that often don't exist, and often just by moving the problem anyway.
  28. 2 points
    Smart pointers and automatic memory management in general. I think C and C++ are pretty much the only major languages that force manual memory management on the user. Even Rust, which has the user manually allocate memory, can still automatically free it for you. Exceptions are another. Return codes are not ideal. And polymorphism. It's not entirely clear to me whether Jai has polymorphism since the writing on it is unclear, and one example seems to rebrand function overloading as polymorphism, but object polymorphism is a useful tool that most game developers use in some way. I also can't find out if there's any sane way of handling Unicode, or whether there's a useful standard library included. It's difficult to talk very meaningfully about the language when most of the information is locked up in very long videos.
  29. 2 points
    Wow, I leave a thread for a few hours and it goes well off the rails. I think Unity is the only game engine I've seen that has separate FixedUpdate and Update functions. Unreal likes to just have a single Tick. And not every engine uses explicit Updates - sometimes they expect you to register a callback on a timer, which gives you more control over your updates. Since low level stuff such as physics and animation is usually being handled separately (probably with fixed timesteps), this makes a lot of sense. Marcus, you're still insisting that Vsync is messing up the interpolation value, and I think I told you right back on page 1, twice, that it's not. You're just measuring it incorrectly, at the wrong time. The only time that interpolation value needs to be calculated is immediately after the fixed update loop ends, and that tells you how the next render call needs to be adjusted. It doesn't make sense to calculate it again after the rendering because obviously more time will have passed. That will be taken into account on the next loop iteration.
  30. 2 points
    Nowadays there are so many walkthroughs on the Internet that cheat codes seems useless. Just pull up your favorite site and have it tell you exactly what to do. If you still need cheat codes after that, either it is stupidly difficult or you just suck.
  31. 2 points
    I recommend learning the UI system. It becomes trivial once you run through a few tutorials. If you don't want a UI, you can use Input.inputString to get the string of characters that have been pressed since the last frame, and append those to a StringBuilder until the enter key is pressed. I've used this for developer cheat codes (think of cheat codes from pre-Quake days) in a game I worked on.
  32. 2 points
  33. 2 points
    I ended up writing my own. Use clang format to format the ugly generated code too Makes my life a lot easier
  34. 2 points
    Lag Compensation is indeed the right term here, at least as it's commonly known based on the old Source Networking document: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation The purpose of lag compensation in this sense is to make the game feel more accurate for the shooter or viewer, by attempting to simulate the results as they would have appeared to that player. This is important in any situation where game entities move very fast relative to the latency between clients and the server, and where that difference between each side's perceived position for a given entity has a significant effect on gameplay. So: typical first person shooter: players and weapons move very quickly, often across the field of vision - lag compensation is useful battleship simulator - it's still first person and shooting, but there's no chance of a battleship getting out of the way in 200 milliseconds - lag compensation is unnecessary online RPG - usually 3rd person, where aiming and timing is not critical and the area of effect can be fuzzy - no lag compensation necessary at all Lag compensation is different from "input prediction" which is a bit of an awkwardly-named term for allowing a client to control its own entity's movement without waiting for full acknowledgement from the server. As this helps the player feel like the input is more responsive, this is much more widely employed, probably on almost every game type, except strategy games.
  35. 2 points
    Ok I thought if I planned 4 weeks to get all the stores I want to release on ready to go, it should be plenty of time as I knew STEAM would be a week or 2 before it was ready to release. STEAM's website informed me it would be a few days to approve the games store page and a few days after that to approve my builds that I want to release. After I started getting into setting up my game on STEAM I realized it's going to take more time than that. After a week of working on getting my game ready to upload to STEAM I found out I will have to push back my release date as there is more waiting that is not made clear when setting up your first app. Store page and game build have been reviewed and approved Store page has been visible as 'Coming Soon' for at least two weeks Minimum of 30 days since the first purchase of an app credit The bottom 2 are not made clear when you set up your very first game on STEAM. At least I never saw anything about those two while setting everything up. So after you purchase your very first app credit which allows you to upload one game, you must wait a minimum of 30 days after that. So now STEAM is telling me the earliest date I can release on is October 1st. I am posting this in the hopes that anyone looking to release a game on STEAM and has not done so yet, take this information and make sure you plan for this delay when picking a release date.
  36. 2 points
    As for "can decompile" - yes (though more accurate would be to say "can decompile, given sufficient time"). As for "simply don't matter" - I certainly cannot agree with it if speaking about MOGs. If speaking about single-player games - the cause can be indeed lost, but with MOGs the situation is drastically different. First - for MOGs it is not about the fact that our game was broken, but about the number of cheaters (who will break the whole game ecosystem if not kept in check, scaring away honest players). Moreover, for MOGs it is not necessary to "run faster than the bear", it is enough to "run faster than the guy next to you". As a result - when dealing with cheaters, every bit counts (this includes Client-Side obscurity). Way too many serious MOGdev companies did realize it too late - and are spending LOTS of time dealing with this problem now (one publicly available example is DaysZ which even had a talk about it IIRC on GDC2016, but there are LOTS of such efforts out there). Second - for MOGs we can count on server being always-present-while-playing. This, in turn, allows to attack that "given time" clause in the "can reverse engineer" statement above. Very very roughly - we can automatically change protocols on each build - forcing attackers to break protocol obfuscation on each build; throw in intra-Client obfuscation - and it can become extremely difficult to get past the defences within the 3-4-weeks time (and after the update - the process starts pretty much from scratch). Detailed discussion of this process is going to be a central point of upcoming Vol. VIII of my "Development and Deployment of MOGs" (with chapters of "1st beta" of Vol. VIII scheduled to appear on my ithare.com in October, they should be enough to get the idea; actually - I plan to publish 20-page outline for "Bot Fighting" chapter as early as next Monday, Sep 25). Overall: - sure, Authoritative Server is a strict prerequisite for dealing with cheaters. - however, just having an Authoritative Server is NOT sufficient, and LOTS of things has to be improved on this way to deal with bots (all kinds of them, from aiming bots to grinding bots, with whatever-we-can-imagine in between). This leads us to such things as encryption (to prevent self-MITM class of attacks which facilitate fundamentally-undetectable proxy bots) - which, in turn, implies hiding a certificate within the Client (hey, this is already security by obscurity!), obfuscation of data structures within the Client to prevent bots from reading the data from RAM easily, and of course, all-popular (but not nearly as efficient-as-advertised if taken alone) "code encryption" (actually, scrambling), debug detection, etc.
  37. 2 points
    Hello there! I'm still alive and working on the game so I jump right into what I worked on in the last month or so. Even though I was pretty silent a lot has "changed". The topic will be polishing, because it never stops , some input handling tricks and another pretty complex one: game balance. Polishing During a series of play-test sessions with friends, family and old colleagues I gathered some really valuable feedback on how to enhance the user experience. Thankfully the game itself was well received, but the mentioned "issues" really bugged me, so I sat down for a week or two to further enhance the presentation. Cost indicators This was a tiny addition but helped a lot. Now the color of the chest and shop item cost texts reflect the state whether you can open/buy them. Animated texts I went into an in-game UI tuning frenzy, so I added a "pop" animation on value change, besides the existing yellow highlights, to gold and attribute texts. Health bar The health bar got some love too! I implemented a fade-in/out effect for the heart sprite slowly turning it into a "black" one when you are low on health. I also added a maximum health indicator and the same value change "pop" animation I used for the gold and attribute texts. Battle events Battle events and various skills (hit miss, dodge, fear or cripple events etc...) got many complaints due to their visibility being insufficient, leaving the player puzzled sometimes why a battle didn't play out as expected. Besides using the existing sprite effects I added text notifications, similar to the ones used with pickups. No complaints ever since . Critical strike This one was an "extra". I wanted to beef-up the effects of the critical strikes to make them look more ferocious and better noticeable. Level transition Play testers shared my enthusiasm towards having a better level transition effect, so I slapped on a black screen fade-in/out during dungeon generation and it worked wondrous. Input handling I knew for a long time now, that the simple input handling logic the game had will not be good enough for the shipped version. I already worked a lot on and wrote my findings about better input handling for grid based games, so I'm not going to reiterate. I mostly reused the special high-level input handling parts from my previous game Operation KREEP. It was a real-time action game, so some parts were obviously less relevant, but I also added tiny new extras. I observed players hitting the walls a lot. Since the player character moves relatively fast from one cell to another this happened frequently when trying to change directions, so I added a timer which blocks the "HitWall" movement state for a few milliseconds towards each walled direction for the first time when a new grid cell is reached. Again, results were really positive . Balancing My great "wisdom" about this topic: balancing a game, especially and RPG, is hard. Not simply hard, it is ULTRA hard. Since I never worked on an RPG before, in the preparation phase I guesstimated, that it will took around 2 to 3 days of full-time work, because after all it is a simple game. Oh maaaaaaan, how naive I was . It took close to two weeks. Having more experience on how to approach it and how to do it effectively I probably could do it in less than a week now with a similar project, but that is still far off from from 2/3 days . Before anyone plays the judge saying, I'm a lunatic and spending this much probably wasn't worth it, I have to say, that during the last 6 months nothing influenced the fairness and "feeling" of the game as much as these last 2 weeks so do not neglect the importance of it ! Now onto how I tamed this beast! Tools and approach Mainly excel/open-office/google-sheets, so good old-fashioned charting baby . And how? I implemented almost all the formulas (damage model, pickup probabilities, loot system etc...) in isolated sheets, filled it with the game data and tweaked it (or the formulas sometimes) to reach a desirable outcome. This may sound boring or cumbersome, but in reality charts are really useful and these tools help tremendously. Working with a lot of data is made easy and you get results immediately when you change something. Also they have a massive library of functions built-in so mimicking something like the damage reduction logic of a game is actually not that hard. That is the main chart of the game, controlling the probabilities of specific pickups, chests and monsters occurring on levels. It plays a key role in determining the difficulty and the feel of the game so nailing it was pretty important (no pressure ). If balancing this way is pretty efficient why it took so much time? Well, even a simple game like I Am Overburdened is built from an absurd number of components, so modeling it took at least a dozen gigantic charts . Another difficult aspect is validating your changes. The most reliable way is play-testing, so I completed the game during the last two weeks around 30 to 40 times and that takes a long while . There are faster but less accurate ways of course. I will talk about that topic in another post... Tricks and tips #1.: Focus on balancing ~isolated parts/chunks of your game first. This wide "chest chart" works out how the chests "behave" (opening costs, probabilities, possible items). Balancing sections of your game is easier than trying to figure out and make the whole thing work altogether in one pass. Parts with close to final values can even help solidifying other aspects! E.g.: knowing the frequency and overall cost of chests helped in figuring out how much gold the player should find in I Am Overburdened. #2.: Visualization and approaching problems from different perspectives are key! The battle model (attack/defense/damage/health formulas) wasn't working perfectly up until last week. I decided to chart the relation of the attack, defense and health values and how their change affect the number of hits required to kill an enemy. These fancy "damage model" graphs shows this relation. Seeing the number of hits required in various situations immediately sparked some ideas how to fix what was bugging me . #3.: ~Fixing many formulas/numbers upfront can make your life easier. Lot of charts I know, but the highlighted blue parts are the "interesting" ones. I settled on using them as semi-final values and formulas long before starting to balance the game. If you have some fixed counts, costs, bonuses or probabilities you can work out the numbers for your other systems more easily. In I Am Overburdened I decided on the pickup powers like the + health given by potions or the + attribute bonuses before the balancing "phase". Working out their frequencies on levels was pretty easy due to having this data. Also helps when starting out, since it gives lot of basis to work with. Now onto the unmissable personal grounds. Spidi, you've been v/b-logging about this game for a loooooong while now, will this game ever be finished?! Yes, yes and yes. I know it has fallen into stretched and winding development, but it is really close to the finish line now and it is going to be AWESOME! I'm more proud of it than anything I've ever created in my life prior . Soon, really soon... Thanks for reading! Stay tuned.
  38. 2 points
    Good advice. This something to get started on earlier rather than later. Sometimes changes take days to weeks before Steam handles them. Once everything is approved and ready, you can set your release date farther out. As you mentioned, it must be at least two weeks, do it a month or more if you can. When the time comes to finally flip the switch don't change ANYTHING. Don't change wording, and absolutely do not change the ratings, permissions, or costs. It can take time for the "powers that be" to review the changes, so don't risk it. Also, flip the switch early. Schedule the date that it goes on sale at least a week in advance, then resist the temptation to change anything for a week.
  39. 2 points
  40. 2 points
    While I also use "p" for pointer, I used to do "b" for bools as well, but now I find it rather distracting. I instead tend to prefix my booleans based on the use-case. "isConst", "wasCalled", "hasAttribute" ... all make it pretty clear that its a boolean, and IMHO easier to read then "bConst", "bCalled", "bAttribute", especially in combination with member-variable prefab "m_bConst" vs "m_isConst".
  41. 2 points
    The demand for mobile applications is at an all-time high, and every Android app development company is striving to get its brand to the front row of the industry. On the Android App Store alone, there are over 4million mobile apps, and more are added almost on a daily basis. There has never been a better time to invest in app development. However, the fact that you have built and launched your mobile app is not a guarantee that you would be smiling to the bank anytime soon. If your app is not “good enough” it will be deleted in a matter of seconds. And there goes all your hard work, time and money. The sad thing is that users barely re-install an app after deleting it. Is there a way to ascertain that your app is functional in all ramifications? Of course, there is. It is called ‘Quality Assurance (QA) test.' The possibility of building a perfect app the first time is very slim: there will always be a few bugs here and there. For this reason, Android app developers and other experts put their apps through different types of tests to ascertain the quality of the app. Here are the different kinds of tests your app should undergo to make sure the end-user loves it: Functional Testing Every app is expected to undergo a basic functional behavior test to ensure that it is working according to defined requirements. In addition to finding out whether a user can complete a task, functional testing is an attempt to know whether or not a particular feature is working. The user interface and flow of the app are mostly considered when carrying out this test. For example, if someone who wants to buy shoes on your e-commerce app has a hard time moving to the next slide, the previous one or even exiting the app, it is obvious that it has failed the functionality test. The diversity of mobile devices and Operating Systems make functional testing a complex, expensive, time-consuming and a strenuous activity, especially if it is manually done. This is why more organizations opt for automated functional testing tools like Appium, MonkeyTalk, IBM rational test Workbench. For even better results, some organizations combine both automated and manual testing methods. Performance Testing As the name implies, this test is carried out to check the client application performance, server performance and network performance of your mobile application. The test attempts to find out how adding one more feature to an app would affect its overall performance. The focus is on the speed, battery performance and responsiveness of the app with the addition of new features. Performance testing tools like IBM Rational Performance Tester and many others will help you to identify the bottlenecks associated with the performance of the app; low battery power, poor network, bandwidth issues, changing internet connection mode, broadband connection, less memory, etc. The test should cover front and back-end performance of the app especially if the application is a hybrid mobile application. A client-focused performance test is for user experience optimization (app responsiveness to UI)). Application’s server can also affect the performance of the mobile application, so testers should consider both sides of the application. Memory Testing Memory leakage is responsible for slowing down the process of transferring files. It can also cause mobile devices to switch off while trying to alternate between apps automatically. Because mobile devices have very limited memory, mobile operating systems by default stop apps with poor UX and excessive memory. It is very important for Android app developers to carry out memory testing on apps to ensure that they optimize memory usage and prevent memory leakage. Interrupt Testing A lot of things could happen while using a mobile app; you could get an email or an SMS, see an incoming call, get a Facebook notification and you could even need to connect the charger to a power source, remove or insert the battery, etc. Mobile applications are supposed to handle these and every other interruption properly without affecting the functionality of the app. Apps typically stop and restart afterward. Thus, Android app developers conduct an Interrupt Test for their apps just to be sure they meet the standard. Testers use emulators and actual devices for the tests. Usability Testing A usability test focuses on how useful, flexible and User-friendly a mobile app is. Testers are concerned about two key areas (Efficiency and Satisfaction) First of all, they consider ‘App Efficiency.' Testers want to ensure that the app accurately and completely meets the specific needs of the end-user. Satisfaction is the second consideration: The user accepts the app in its entirety and derives maximum satisfaction and pleasure from using it. Some mobile app development companies make the mistake of waiting until the application is completed before carrying out usability test. The end-users have a major role to play in usability testing, the results may completely alter the app design, and changing the design later may be a futile effort. The best time to carry out the test is at the beginning stage of the mobile app design. Installation Testing All mobile devices come with two kinds of applications. The first type of apps are system apps in the device’s Operating System and the second type are those that the user downloads and installs from the app store. Mobile app developers and testers conduct installation checks to ensure that their apps can be installed, uninstalled and updated as many times as possible without hitches. Operational testing: Operating systems have built-in functions that make it possible for Smart Phone users to back up and recover their lost data, files or documents on mobile apps. Mobile app developers conduct operational testing to confirm that the backup and recovery process is working according to specification. Load Testing Every mobile app or web page has a limited number of people it can accommodate at the same time without slowing down, or crashing. The figure is determined by the server. They begin to malfunction when they exceed the server limit. Load testing is very important, especially for popular websites and apps because it shows the breaking point of a mobile app or web page. App developers carry-out load testing to know the number of users that an app can conveniently accommodate. With this information, app developers may choose to upgrade their server and other features of the app to attract more users. Conclusion Conducting the various types of testing on your mobile app can be very expensive and time-consuming. However, since the benefit outweighs the cost, in the long run, app testing is definitely a step in the right direction.
  42. 2 points
    When you say "100%", you have to define what that means. 100% of what? Obviously if you're choosing 1 card out of 2, it's simply not possible to have "100% chance of card 1, 5% chance of card 2". Probability doesn't work like that. If you were implementing a booster pack system, e.g. of 7 cards, then I suppose you could say there is a 100% chance of getting a certain card... unless, for example, you had 8 cards each "100%", which means that again it's impossible. A more workable concept is to think in terms of relative frequency. You might decide that a common card is twice as likely to be selected as an uncommon card is, and an uncommon card is twice as likely to be selected as a rare card. But even here, there are 2 interpretations: For every card selected, it's twice as likely that it is common than it is uncommon. For any given common card, you're twice as likely to select that than you are to select any given uncommon card. It's easy to see how these 2 definitions can work differently. Examples: (ignoring rare cards for now) Pick one at random from: "Common1", "Common2", "Common3", "Common4", "Uncommon1", "Uncommon2" - this fits definition 1. You're twice as likely to pick a Common card. But you're just as likely to pick Common1 as you are to pick Uncommon1. Common3 is as frequent as Uncommon2. So although this fits one definition, it probably isn't intuitively what you expect. Example 2: pick one at random from "Common1", "Common1", "Common1", "Common1", "Uncommon1", "Uncommon1", "Uncommon2", "Uncommon2". Here, you're twice as likely to select Common1 than you are Uncommon1. You're also twice as likely to select Common1 than you are Uncommon2. And yet, half of your selections will be Uncommon, just as many as your Sommon selections. Again, this is unintuitive. Because there are more types of Uncommon card, the individual infrequency is balanced out by the overall frequency. So, what you will probably want is a system that tries to balance both of these concepts. You will probably want to attach a weighting to each card individually, but you also need to manage the size of the relative categories and ensure they are of similar proportion, so that both the rarity interpretations hold true. Then, selecting is a case of a standard weighted random sample. (e.g. https://medium.com/@peterkellyonline/weighted-random-selection-3ff222917eb6 or, use the cumulative frequency and a binary search.)
  43. 2 points
    I dont understand why most people here, de-recommend the handmade hero series. Its the only series/man i know of teaching the core fundamentals from the very beginning without forcing himself to any programming paradigmas at all: - He simple doesn´t care about any programming rules, patterns, whatsoever. - He just writes it down in the simplest straightforward way and extend it or compress it as he goes. - He produces working code doing real work, while explaining everything he is doing. So just write it down in the most stupid simplest way you can imagine - without forcing yourself to restrictions, managers, classes, any patterns, whatsoever. Extend it when you need it, abstract it when there is actually a need for. Thinking about how should i design my classes, how should i interact with them, how i can extend them in the future, how to abstract X to solve problem Y is just a trap most programmers will fall in - always. Unfortunatly even the most talented ones falls into this trap as well.
  44. 2 points
    Here's my suggestion (although I am a programmer and rarely get to hire artists): focus on a concept art portfolio. Make it totally game-focused, and show some concepts for environments, characters, and ideally vehicles, weapons, objects, etc. Consider things like: different themes for the same character or object (this is the kind of work that is common during the pitching/preproduction stage when the team is trying to agree on an art direction) consistent theme across several different pieces (e.g. a character and environment from the same setting - this is the kind of work that you'll do as a project progresses) add in a smaller amount of other 2D work to show some versatility, maybe some of the following: UI mockups (don't get too focused on UX - chances are, you're limited by the tech anyway) splash screens icons logos I'm not going to comment on 2D environments and 2D characters, because the market for that is pretty small and mostly limited to the indie market, which generally is not hiring many people, and is rarely "financially stable" or has "3+ people doing art on the project".
  45. 2 points
    You can only pre-bake a shadow map if neither the light nor any objects in the shadow map are moving. Any kind of moving sun is out. Even if your sun is static, you could only bake the cascades if they cover a specific area and never move (with the player, based on where the player looks, etc.) This largely defeats the purpose of cascades, and I can’t think of any cases where it would be useful to bake them. I can’t remember the site, company, or game, but around 7 years ago this idea was published and explained with a demo. You reproject the shadow look-up coordinates in much the same way as you have to reproject the scene for temporal anti-aliasing. It hasn’t caught on since then due to the difficulty in implementing it and all the edge cases that arise that either slow down the routine if handled fully or lead to artifacts if not. As with any reprojection technique, you have problems with things appearing from out-of-view. But it might be suitable for the farthest cascade of a shadow map. We were considering this but did not implement it. If your world is as large as ours in Final Fantasy XV, then your farthest cascade will be mostly blurry and you can get away with not rendering certain things such as small foliage (another optimization I implemented), so if there is a candidate for this type of reduced updating rates it would be that. L. Spiro
  46. 2 points
    Gamemaker is probably your best bet then. If you need more assets, there are plenty of free ones around for you to get started.
  47. 2 points
    Why not just jump into GameMaker and see where it takes you?
  48. 2 points
    My first suggestion is that you don't need to have a list of classes up-front. If we tried to do that for AAA games we'd never start coding. My other comments: I like to have a separate App class which contains a Game class. Game is for, well, gamey things. I'd create the window and other input/output in the App, as well as an instance of the Game. Actors shouldn't need TextureManagers. There's no part of 'acting' that needs to look up textures. If you want Actors to be responsible for drawing themselves, that's fine (at least at this level), but you should pass in the texture to use in each case. Input handling for a game like this can stay simple. I'd start with a function that is called from the main loop, with the paddle passed in as an argument. Call methods on the paddle to implement movement, based on input state. If you have the separate Game/App system like I do, then the App's input handling can call through to the Game's input handling.
  49. 2 points
    I was on the 35th floor in the north conference room. Through the window, I could see the gray, rainy Toronto skyline. I was here to learn about government funding programs for Digital Media. At my table were a television/documentary producer, a toy manufacturer, and two suits who looked so dull and cliche that I didn't even introduce myself. The panel consisted of several government agency workers, a consultant, and a game developer. The information shared over two hours was good, but I enjoyed the spicy chicken wrap from the buffet a lot more. As a wrap-up, the organizer asked the panel what final words they would like to share with the roughly 40 people in attendance. With only 20% of all applicants being selected for funding, the two agency reps and the game developer stressed how important it is to sell yourself. It wasn't until this moment when the slightly scruffy toque-wearing game developer said this, that I realized how important sales technique is for the indie dev. Fortunately, this is something I have experience with. And I am happy to share these techniques with the rest of the indie dev community. In this article, I attempt to demystify the science and psychology of selling (pitching). I will focus on selling to EXTERNAL parties (strategic partners, customers, etc.). If people see value in this, then I'll take the time to describe how to sell to INTERNAL parties (your team, your boss, etc.). I'm writing primarily for small indie game developers who will often need to pitch themselves -- perhaps to journalists, publishers, investors, potential hires, strategic partners, game contests, government organizations, incubators, and many others. However, these principles of selling aren't specific to game development. Anyone can use them to build their business, land a job, or convince someone to marry them Before I take advice from anyone, I like to know their experience. So before I go any further, let me digress a moment to summarize my professional sales experience. I began selling as a full-time commission-only computer sales person at a Canadian electronics retailer called Future Shop (similar to Circuit City or Best Buy). The company paid 25% of the profit of whatever you sold. As you can quickly see: 1) recruits either learn to sell FAST or die; and 2) if you can sell, you have unlimited maximum income. I took to it like a fish to water. But I also took my new profession seriously: I learned everything I could from the extensive training program (based on the Xerox method), managers, co-workers, books, tapes, and video training series from motivational speakers such as Zig Ziglar. I did well and eventually became a sales trainer for new recruits in the corporate head office. Now sales execs generally look down on one-to-one business-to-consumer (B2C) sales, and retail in particular -- for some good reasons, I must admit. It's usually done very poorly. But here is one important advantage: The number of pitches you can do in a day in retail is astronomical: 20-40 pitches a day every day compared to business-to-business (B2B), which allows for 1-2 a day at best. That kind of regularity, repetition, and low cost of failure (if you misspeak and lose a sale, someone new will be along in the next 5 minutes) is the perfect training ground for learning how to pitch. I moved into B2B sales first for a web dev company (1 pitch a month), then into business for myself (about 1 pitch a month). I was still 100% dependent on my ability to sell, but now with the pressure of supporting my staff and other overhead, too! For more than 10 years, I sold custom mobile software projects ranging from small ($25-50k) to large ($700-900k). Over the years, I reckon I've sold about $6+ million across 30+ projects with a 95% closing percentage. My pitches were primarily to a C-level audience (CEO, CFO, CTO, CMO, COO). To conclude this summary, I'll share one of my proudest sales moments: I was about two years into my business. I was introduced by conference call to a mammoth prospective customer: We had 4 employees, and they had $4 billion in annual revenue. They used IBM for most of their IT consulting and were considering a mobile software project -- and using IBM for it. I flew into town (I still can't believe I managed to get the client to pay for my flight and hotel!), spent a day with the CTO in the board room, flew home, and closed the deal the following week by phone. Take that, Big Blue! Definitions B2B sales are most similar to what the typical indie faces -- whether you are pitching your game to a console manufacturer or a journalist. I will use the lingo of "Customer" to mean the party you are selling to. When I use the term sale, I want to be clear what I mean. Simply put, a "sale" is when you convince someone of something. It is a transaction of the mind. It's like Inception - but this time everyone is awake. Once this is accomplished, handing over money, signing contracts, creating a feature article, or any action the customer does is secondary. It wouldn't have happened if you hadn't convinced them it was worth doing in the first place. OK, let's get to it! 1. Every Buy Decision is a Largely an Emotional One. This is the most important and shockingly counter-intuitive truth I can share with you. If you don't remember any other principle, remember this one! When making a decision, people like to think they are rational and logical. While they know they have emotions, they don't understand or believe that emotions make up probably 80% of their decisions. Don't burst their bubble! The poor souls living in the Matrix are happy there! For example, let's say you are house shopping with your spouse. You look at two houses with roughly the same features, location, and price. But the more expensive house that is slightly older and needs more work just has a great living room that seems perfect for family visits. On a pro/con list, you should not choose this one -- but most people do. Why? Because you have an emotional attachment that drives a seemingly fully rational decision. Ever got a job you were slightly unqualified for? Ever NOT get a job you were overqualified for? If your answer is "yes," you know from experience the huge role emotion plays in human decision-making. It is NOT all about features, merit, dollars and cents, brand or background; sales technique can overcome ANY weakness or hurdle if executed the right way. You too can beat IBM! Or you can be in the best position (factually and objectively) and totally blow it Success is within your grasp -- something you can control through sheer determination. What I'm trying to say is that time spent learning and practising sales technique will increase your closing percentage -- NOT because your product changed, but because of how you pitched it. More features won't sell your game; you will! Pro Tip: My good friend and English professor taught me when writing persuasion (sales) literature for a friendly audience to save your strongest point for last. But when writing to a sceptical audience, use your strongest point first because they may never read any further. Good advice! 2. Sell Because it's Your Job. No one else will sell you but you. If you won't sell you, you are screwed. Most people are uncomfortable selling. I think salespeople rank just below politicians and lawyers on the Slimy Job Top Ten list. I believe two major factors contribute to this: Because you gain something out of selling, somehow this makes the act immediately feel disingenuous. Your motives don't feel pure. Selling requires risking personal rejection and failure. Someone may make a face at you, respond with something hurtful, or (worse) ignore you completely. This was true for me. I'm an introverted computer nerd who tried to attract the ladies with well-crafted autoexec.bats. I dislike meeting new people. I'll never forget the lesson a Future Shop manager shared when he noticed several shy new recruits reluctant to approach customers: Have you ever been at a bar and seen a really attractive person across the room you'd like to meet? But you are too afraid to approach him or her? Maybe you think they are out of your league, or just want to be left alone, or look busy, or some other excuse. Now consider this: What if you were hired by the bar owner to be a greeter. He made your job very clear: "I want you to make sure people have a good time here, so make sure you talk to each person at least once and see how they are doing." Now how would you feel about approaching the attractive person? It's way easier! Whether it goes well or poorly, it doesn't matter anymore; you are just doing your job. You no longer feel threatened -- or threatening. The difference between the two scenarios is not one of facts or features. Neither you nor the other person has changed. The change happened inside you. Now you feel permission or even the right to make the first move. You need to get to the place where you give yourself permission to approach that publisher, journalist, voice actor, or the general public. Until then, you will simply give yourself too many excuses not to sell. Pro Tip: In every discussion with a customer a sale is being made. You are selling your ideas, but the customer is selling too! Either you are convincing them to buy, or they are convincing you why they shouldn't. Who will be the better salesperson?! Notice in the conclusion statement that you either give yourself permission or you give yourself excuses. A sale is being made here too! You either sell to yourself that you are allowed to sell, or you sell to yourself you aren't. 3. If you Don't Believe It, No One Else Will. Humans are born with two unique abilities: to smell a fart in an elevator to smell a phony In order to sell well, you must have conviction. You have conviction if you truly believe in yourself and your product. While I must admit it is possible for the highly skilled to fake conviction, there is no need to do so. Real conviction is easy and free when you are in love with your product. It will ooze out of every pore; little things like the tone of your voice, word choice, the speed at which you speak, and the brightness of your eyes. Conviction is infectious. People want to be caught up in it. Which goes right back to point #1 about the emotionality of selling. But why does conviction sell? Because a customer is constantly scanning you to see if what you are saying is true. Conviction is important in how the customer reads you. Imagine you are trying to convince a friend to see a movie. Your friend thinks: He appears quite excited about this movie. I would only be that excited and passionate if it was a really good movie. Ergo, the movie must be really good. In Jordan Mechner's book, The Making of Prince of Persia, he records the process of making the first Prince of Persia game (which was incredible for its time). The production team believed in the project immensely, but the marketing department did not. When they chose the box art and shipped the title, this great game had dismal sales for the first year. Only when a new marketing department came in, believed in the product, and revisited the box art and marketing plan did the game start selling. Conviction gives the customer the data needed to sell themselves into believing what you are saying. This dovetails nicely with my next point. 4. Want What is Best for the Customer. I'm currently doing a sales job on you (oops, I seem to have broken the fourth wall!) I'm trying to convince you that what I am saying is true -- and when put into practice, will make you better at pitching your game. Why am I typing this at 2:36 a.m. when I could be sleeping -- or better yet, playing Mario Kart 8? Because I genuinely believe this information will help someone. It costs me very little (some time at the keyboard) and could make a real difference in someone's life. See, I'm not typing this article for me; I'm doing it for you. Whether or not I benefit from doing so, my primary motivator is to do something good for you. If you want to get your game featured on a certain site, stop thinking about how it is good for you to be featured and start thinking about how it is good for them to feature you. Reasons (arguments) made from the perspective of their good will impact deeper and resonate longer. So how can you know what is good for your prospective customer/journalist/publisher/government agency? Do your homework. Know what makes your target tick. Find out what motivates them. Discover what is important to them. More importantly, find out what is not important to them. For the conference I attended, the purpose of the government program was to generate digital media jobs in our province. The overseer specifically told us: "When you write your proposal, be sure to point out how this will lead to job creation." This is great advice for two reasons: The customer is not only saying "Tell me how it's good for me," but also "I'm lazy, so make it easy for me." In other words, the customer is 'tipping his hand' by saying "All things being equal, the proposal that more easily shows what's in it for me will be chosen." Don't rely on your target audience to do the work of understanding. Your pitches will vastly improve if you spoon feed them the goodness! Pro Tip: Knowing what NOT to say is just as important as what TO say. For example, I regularly listen to the Indie Haven Podcast. On one specific episode, all four journalists went on a bit of a rant that if you are contacting them for the first time, do not tell them about your Kickstarter. Tell them about your GAME! They said if you start your email about your Kickstarter they will stop reading. So know what NOT to say and avoid the virtual trash bin! 5. Don't say what is True, say what is Believable I had just started my software company and was having lunch with a veteran entrepreneur millionaire friend to get some advice. During the soup course, he asked, "So what does your software company do?" "We make amazing custom software," I answered. "I understand that, but what specifically are you good at?" "Here's the thing, we are so good with such a great process we can literally make any kind of software the customer wants -- be it web portal, client-server, or mobile. We are amazing at building the first version of something, whereas many companies are not." "That may be true, but it isn't believable." I dropped my spoon in shock. Maybe your role-playing game is 10x more fun than Skyrim -- not just to you, but empirically through diligent focus group testing. But don't try and approach a journalist or publisher with those claims. It may be true, but it certainly isn't believable. What is true and believable is, "If you liked Skyrim, you'll like RPG-I-Made." Ever seen a byline or quote like that in an app description? Yep, because that is as far as you can go without crossing the line into the "unbelievable" territory. 6. Create the Need Every sales pitch is like a story, and every story is like a sales pitch. Let me explain. You can't give an answer to someone who doesn't have the question. You can walk up and down the street yelling "42!" to people -- but if they aren't struggling to know the answer to Life, the Universe, and Everything, it won't mean a thing to them. You can't sell a product/idea to someone who doesn't have a need. Every pitch follows the three-act story structure: Act 1: Setup Act 2: Establish the need Act 3: Present your solution We see this in The Lord of the Rings: Act 1: Frodo is happy at home, life is good. We meet a bunch of characters at Bilbo's birthday party. -- Setup Act 2: A ring will destroy everything Frodo loves. And people are coming to get it right now. -- Need Act 3: The fires of Mount Doom can unmake the ring. Frodo tosses it in, by way of Gollum. -- Solution Study the first part of infomercials to see how need can be quickly established. Humans have plenty of basic latent needs/desires you can tap into. You don't need to manufacture a new one. When it comes to gaming, one simple one is "to feel awesome." Pretty much every game I play makes me feel awesome. Now I may or may not be awesome in real life, but I have a need/desire to feel awesome -- and games fill that need nicely. Bringing it back to the government program, what is their need? They are handing out money and tax incentives. At first blush, there doesn't seem to be a need that I can tap into. But applying principle #4 of what's good for them, we can do our homework and discover that if the program has 20 million dollars, they HAVE to give that money out. The people working there are not evaluated by how much money they keep; they are rewarded by how much they give away. They literally have a need to give away money. But not to just anyone; they need to give it to studios that will manage it well and create long-term jobs in digital media. As a final example, notice how I establish a need for this article in paragraphs 5 and 6. This article is based on the common need for indie game devs to promote themselves. 7. Talk to the Real Decision Maker Who is the best person to pitch you? You. So don't expect all the time and effort spent pitching a minion means they will pitch their boss on your behalf just as well. Aragorn did not find a mid-level orc, explain his position, then hope the orc makes as impassioned a presentation to Sauron. Aragorn knew he needed to climb the corporate ladder. He went directly to the Black Gate to take his issue up with Sauron directly! Throughout most of my B2B sales career, I initially got in the door through a mid-level manager like a project manager, IT director, or operations manager. These people have "felt need". Their team needs to do something new or is inefficient and needs software to solve it. But a $250k decision is way beyond their pay grade; they need the CFO and maybe CEO to make the decision. You can spend hours and hours pitching the minion with amazing props and demonstrations, and they turn it into a 3-line email to their boss saying your presentation was very nice. Aaarrrggghhhh!!! Even worse, what if the competition is talking to the CEO over lunch at the country club while you are spending all your efforts on the minion?! Flanking manoeuvres like this are a common reason for losing a sale. Remember in point #1 how all decisions are really emotional? By filtering your pitch through someone to the CEO, all of the emotional trappings disappear; it literally is just features/functions on a page. Meanwhile, the sales guy at the country club is showing interest in the CEO's children, sharing stories of his own, and having a good laugh. All things being equal, 9 out of 10 times when the CEO has to decide, he'll go with the person he met. Everyone trusts what they see with their own eyes more than what was reported to them by another. Use this to your advantage. This doesn't mean you shouldn't talk to minions or treat them like a waste of time. That is mean and dehumanizing. You won't get anywhere with that. My point is not to RELY on the minion to do the sales job for you. You have to climb the corporate ladder to the actual decision maker and give it your best. A concrete example is when I organize a pitch session with the mid-level manager, I make sure their boss is invited to the meeting. Or I do the whole pitch to the mid-level manager and then ask, "Do you think your boss would see value in having this information, too? I would be happy to come back and run through it." If they are impressed with what you've done, they are more than willing to move you up the ladder. Now, big companies are wise to these ways and may have strict rules on who can meet with external parties. This is frustrating. The best you can do is to find the closest person to the actual decision maker and pitch your heart out. Personally, I find this ladder-climbing the most difficult aspect of selling. But then I have to remember principle #2: It's my job. If I don't do it, no one will. 8. Sell the Appointment, not the Product When are you at your best, selling-wise? In front of the person with all your tools, demos, snappy dress -- and sharing fancy coffees. When is it harder to say "no" to someone -- over the phone/email or in person? In person. Most people suck at cold calling/emailing. While it is a sucky task, one big reason people fail is because they have the wrong objective. They think that as soon as they get the person's attention, it is time to pitch. By-the-power-of-Grayskull no!!! When you first encounter someone you need to pitch, your goal is to get a meeting where the person is relaxed, focused, and mentally prepared to listen to what you have to say. Your email or call may have interrupted their day between meetings, or baby bottles -- and they don't have the headspace to listen, never mind think. You will get a "no" at this stage. So give yourself every chance of success; book the meeting! To get the meeting, you must be diligent about three things: Keep the conversation as short as possible. Tell just enough to whet their appetite. DO NOT tip your hand -- build the need/desire for the meeting. Keep steering them back to the appointment Granted, this one takes some practice -- but here is a quick example to get you started: "Hi, Mrs. Big Shot. I'm Thomas, and I am making a new kind of role playing game that I think would be a great addition to your platform. Could I schedule just 15 minutes of your time to show you what I'm working on? I really think you will like what I have to show you." "Role-playing game, eh? Dime a dozen, pal. What's so great about yours?" "Well, I have some new A.I. techniques and combat mechanics that haven't been seen before. I'd love to meet with you to go over the key features of the game and even show you some gameplay. How about a quick meeting later this week?" "Have you made anything before, or this your first time?" "I've released two games previously, but I would be more than happy to go over my qualifications and previous experience with you when we meet. Is next week better than this week?" "I'm pretty busy this week, but schedule something next week with my assistant." "Thank you, Mrs. Big Shot! I look forward to meeting you!" Why does this work? Because curiosity sells. Since you haven't given Mrs. Big Shot something yet to reject, she is open and slightly curious to see if maybe, just maybe, you have the next big thing. 9. Inoculation The ability to inoculate against objections is probably the single biggest gain a newbie sales person can make. Removing and eliminating objections is the key to closing the sale. In real life, we get vaccinations to prevent disease. The process is to introduce a small weak version of the disease into your body against which your immune system will build a proper defense for the long term. When the actual disease comes along, you are immune. Inoculation (in sales) is the process by which a salesperson overcomes objections before they have a chance to build up and fester. The longer the objections gestate in the customers' minds, the quicker the "virus" takes hold. You do this by bringing up the objection first yourself, and then immediately answering it. If you bring up the objection first, the virus is in its weakest possible state -- and the customer becomes impervious to it. So after you prepare your pitch -- whether it's website text or email -- you have to look at it from the customer's perspective and see where your weaknesses are. Maybe get a friend to help you with this. Let's imagine you've come up with three likely objections to your game: You've never made a game before. Your selected genre is oversaturated. Your scope is aggressively large. Before I go any further, let's reflect for a minute on how likely you are you to close the deal with those three objections hanging in the customer's mind. Not very likely. Even if they haven't voiced them yet, just thinking them will torpedo your chance of success. Now imagine all three of those objections have been inoculated against. It's clear sailing to closing the deal! So here is an important principle: If someone raises an objection when you try to close, what they are really saying is that you haven't successfully pre-empted the objection by inoculating against it. Learn from this! Remember this objection for next time. Spend time thinking through possible ways to inoculate against it. The more chances you have to pitch, the more experience you will have with objections, and the more inoculations you can build into the next version of your pitch. Sales is a real-time strategy game! Prepare your defences well! Another principle to remember: Customers are not necessarily truthful and forthright. They may have objections but haven't shared them with you. If they don't share them, you have no way to overcome them -- and your sale dies right then and there. Inoculation is the best defense against this. Pro Tip: Don't save all your inoculations for the end of your pitch; it's too late then. Sprinkle them throughout the pitch; they are more easily digested one at a time. Early in the presentation, you should be inoculating against conceptual objections such as, "Is this even a good idea?" Later on in the presentation when you are about to go for the close, you need to address implementation objections such as, "Do you have a realistic team to build this?" A further benefit of inoculation is that by bringing up your perceived weakness yourself, you gain credibility and show that you can think critically. This goes to character, and people generally want to work with credible people who can think critically. So how can we inoculate against those three example objections? 1) You've never made a game before. Early in the presentation, like when you are sharing your background or how you came up with the concept of the game. Say something like, "Now this is the first game I'm making myself. However, I have X industry experience doing Y. I also have two mentors who have released several titles that I meet with regularly. When I don't know what to do, I lean on their experience. " 2) Your selected genre is oversaturated. Mid-presentation, show some screenshots or demo -- and the genre will be known. You can say something like, "Now I know what you are thinking: Another First Person Cake Decorating game? And initially, when I was designing it, I felt the same way. But here is why I think our First Person Cake Decorator is unlike anything else in the market . . ." 3) Your scope is aggressively large. Late presentation just before the close addresses objections like this. "Now I recognize that our scope seems too large for our small team. But team member X worked on such and such, and it had 3 times as many A.I. agents as our game. And we are open to discussing the scope with experienced developers. At the end of the day, we want to make something new and compelling for the genre and are looking for key partners like you to help us get there." Pro Tip: When the customer asks for implementation details such as scheduling, resources, costs, specific technologies, start getting excited. These are buying signals. The customer is rolling your proposal around in their mind trying to imagine working with you. So make sure you answer all the questions truthfully and completely! 10. Leave Nothing to the Customer's Imagination Since I was pitching custom software, I had nothing to show because it didn't exist yet. It's one thing to pitch a car or house that is right there in front of the customer. But to pitch an idea? And they have to agree to spend the money first before they see anything tangible? This is extremely difficult! Now I imagine in the game space that the people you meet probably exercise their imaginations regularly. But in the business space, I can assure you that the CFOs are NOT hired for their creative imaginations. More likely, their lack of it. So what do we do? Do not rely on the customer's imagination to understand what you intend to do or build. Make it as concrete for them as possible. Words are cheap, so use props. One reason my software company closed many deals despite being up against larger, more experienced competitors is the lengths we would go to show the customer how their eventual software may work. Our competitors would hand in four-page proposals; ours were 20-30 pages. We spent dozens of hours mocking up screens and writing out feature descriptions. Sometimes we would build a demo app and throw it on a handheld. All this so they could see, touch, and taste the potential software in the board room and close the deal. Even if our software solution cost more and would take longer to complete, the customer would go with us because our presentation was more concrete. They could see success with us; whereas, they would have to imagine success with the competitor. In games, you can make a demo. But if that is too much, you can at least get an artist to make mock screens, get some royalty-free music that fits the theme, and then show footage from other games that inspire you. Props beat words every day of the week. Pro Tip: When up against competitors, you always want to present last. I've been in many "showcase showdowns" over the years where the customer will hear presentations from 3 or 4 companies throughout a day. The reason you want to go last is whatever presentations they saw before yours creates "the bar," the standard of excellence. If you are better than that, it will be so completely obvious to them that half your work is already done. But what if you aren't way better than the competition? However amazing the first presentation may have been, it fades in the customer's memory. Perhaps by the fourth presentation, they have forgotten all the glitz of the first. It's sucky to lose that way but remember: The decisions are emotionally charged and based on faulty humans rather than faultless computers. Go last, have the strongest last impression, and improve your chances of winning! 11. Work Hard! Earn it! The movie Rudy is a great example of this principle. Based on a true story, Rudy wants to play football for Notre Dame. Trouble is he isn't big, fast, or particularly good at football. But he tries! Oh, how he tries! He practices more and with greater gusto than anyone else. Finally, at the end of the movie, Rudy is given the chance to play in a game. The crowd chants and the movie audience cries because it's all just so wonderful! Almost all of the software deals I closed were bid on by multiple competitors. Canadians love the "3 quotes" principle. When I would check in on my client waiting to hear that we won the job, it would boggle my mind to hear the decision is delayed because one of the competitors was in late with their proposal. Are you kidding me?! We delivered our proposals on time every time. That may have meant some late nights, but failure wasn't an option. And as previously mentioned, we always delivered more in our proposals than our competitors did. Everyone likes to reward a Rudy because we all want to believe you can overcome your weaknesses through hard work and dedication and achieve your goals. Working hard during your pitch says more about your character than anything else. It gives the customer the impression, "If they work hard here, they will work hard for the whole project." The reverse is also true: "If they are lazy and late here, they will be lazy and late for the whole project." Again, talent isn't everything; who you are inside and how you work is. I have personally awarded work to companies/contractors because they worked harder for it than the others, even though they weren't the best proposal I received. Pro Tip: Be the best to work with. When I am in the process of pitching someone, I am "all hands on deck" for instant responses to questions or ideas from the customer. An impression is not just made with how you answer but how quickly you answer. If customers encounter a question and get an email response within 12 minutes, they are impressed and know you are "earning it." 12 You Have to Ask for the Close "You miss 100% of the shots you don't take." - Wayne Gretzky I'm not great at networking or cold calling. I've already shared that I'm not great at ladder climbing. But where I really shine is closing. Closing a deal is like winning a thousand super bowls all wrapped up into a single moment. With a bow. And sparklers. I could write a whole article just on closing (and there are books dedicated to it), so I've limited our time to just the most important, most missed principle: You have to ask for the close. I have seen great sales presentations fail because the presenter never asked for the deal. They talked and talked and said lots of wonderful things, but then just sat there at the end. What were they expecting? The customer to jump out of their seat screaming, "I'll take it!" Or maybe it's as if there is a secret that the salesperson is there to make a sale and they don't want to blow their cover by actually saying, "So, will you choose us?" If you don't ask for the close, you won't get the objections -- and if you don't get past the objections, you won't win. So ask for it! Now to some specific techniques to help you. First, be clear about asking for the close. If you want an interview, say "So do you think you can interview us?" If you want a meeting with someone, say "So can we book a meeting for Tuesday?" If you really struggle with what I just said, try the pre-close to boost your confidence: "So what do you think so far?" That is not a close. That is a non-threatening temperature check. The customers are just sharing their thoughts, tipping their hand to tell you what they like and any immediate objections that come to mind. After you discuss their thoughts, you still have to circle back around to booking that interview or the meeting. Second, when you ask for the close, the next person who speaks loses. Silence is generally uncomfortable for people, so this one requires real grit and determination. Many salespeople say something during the silence to try and help their case. They are doing the opposite. Asking for the close is a pointed question that requires the customer to make a mental evaluation and then a decision. If you say anything while they are doing the mental process, you will distract them and cause the conversation to veer away from the close to something else: tertiary details, objections, etc. I was in a meeting with a potential client when I had the unfortunate task of telling them their software wouldn't be $250k but $400k and take months longer. I explained why and then asked for the close: "This is what it costs and how long it takes to do what you want to do. It will work exactly as you want. Would you like to go ahead?" They were visibly mad at the ballooned cost/time. I sat in silence for what felt like hours but was probably 3-4 minutes as the VP stared at the sheets I'd given him. Finally, he said "I don't like it, I'm not happy, but ok. But this date has to be the date -- and no later!" The silence put the burden of making a decision squarely on the VP, and he decided. Third, expect objections. Even if you did all your inoculations correctly, there will be something you never thought of that they did. Hopefully, you got the big ones out of the way -- but I don't think I've been in a meeting where they just said, "Great presentation. Let's do it!" Sometimes people bring up objections for emotional reasons: They just don't want to work with you. Like the girl who won't go out with you because she has to wash her hair that night. There really is nothing you can do at that point. You've failed to build rapport or show how you can meet their needs. You won't recover these blunders at the closing stage. But for real objections, these are legitimate reasons preventing them from going with you. Get past those, and it's time for the sparklers! It is critical to first get all the objections in one go. This is most easily done with a simple question, "Other than X, is there anything else preventing us from working together?" I'll show you why this is important in a moment. If possible, write down every objection they give you. Most people get hung up on one or two. In my hundreds of meetings, I have never seen someone able to list 4+ objections to a pitch. Now work through each one of the objections in turn -- treating them seriously. Treat them like they are the end of the world if unresolved; because they are! Before moving on to the next objection, say "Does what I just shared address your concern?" If they say yes, cross that off the list. Pro Tip: You don't have to deal with the objections in the same order they raised them in. If there are some quick ones and then a hard one, get the quickies out of the way first, build up momentum, turn the room temperature in your favor, and go for the hard one. Also, if you do handle them out of order you maintain complete control of the conversation because they can't anticipate what is coming next. Once you have dealt with each of the listed objections, say something like, "Well we've addressed A, B, and C. So now do you think we can work together?" By gathering the list of objections first, you have achieved several things. First, you've shown you listened to them. Listening and understanding can overcome much of the objection. Second, it brings a natural path back to the close! They listed out the agenda, and you dealt with it; there is nothing left to do but close! Finally, you are preventing them from coming up with new objections. This is a psychological trick since you gave them every opportunity to list out their objections earlier -- now that time has passed. They look foolish if they do it again. Sort of like when you get to a certain point in a conversation, it's just too late to ask the person their name. If they raise new objections at this point, it looks like they are just stalling or delaying. Maybe that is what they are doing -- because the objections were emotional ones. These principles apply to writing as well! Like a website "squeeze" page to get newsletter subscribers. You have to be clear and obvious about what you want: You want a newsletter signup. Well, make it clear and easy for them to do that! Pro Tip: When negotiating (which is just a sale in a different form), when is it better to name a price? Should you go first -- or let them be first instead? Common knowledge is to go last, which happens to be the wrong answer. According to the Harvard Business Essentials: Negotiation book you should speak first. The person who speaks first frames the rest of the conversation and is more likely to get it to go their way. I saw the truth of this early on in my business. I went to downtown Toronto to meet with a client and negotiate the value of something. I sat down with the CFO, and he was going on and on about how what he wanted wasn't very valuable to me. Then he said, "What do you think it's worth, Thomas?" I said $30,000 -- and he almost fell backward out of his chair. He was thinking only $1,000-2,000. But since I went first, his paltry fee looked insulting and ridiculous. We ended up at $15,000. Half of what I wanted, but 8x-15x more than he thought going in. Speaking first works. Conclusion Well, there you have it: roughly 12 years of sales experience boiled down to 12 principles. Did I "close" you? Was this information helpful in improving your pitches? Use the comments to let me know! SDG You can follow the game I'm working on, Archmage Rises, by joining the newsletter and frequently updated Facebook page. You can tweet me @LordYabo
  50. 2 points
    Introduction This article attempts to answer one of the most asked questions on GameDev.net. "I am a beginner. What game should I make?" If you are a beginner at game development, you should definitely read this article. Your First Step to Game Development Starts Here You've learned a language. Skills are at the ready. Now it's time to finally create that game! After years of playing games and discussing graphics, design, and mechanics, the time to put the game that has been dreamt about on the big screen is now. That Final Fantasy 7 remake is the first game that needs to be made. The idea of making it an online multiplayer is also a priority. Why? It would make the game better of course. Plus, everyone wants that feature anyway. Now the googling begins. What engine was it made from? What graphics does it need? Did it use DirectX or OpenGL or even Unity? Every new question produces two more questions. It gets to the point that the tasks and goal can be overwhelming. But with ambition the goal can be met! Right? Unfortunately as many beginners come to find out, the complexity of a game can tamper ambition and in some cases completely put out the flame. However, this article will help you prevent that and also build up your game programming skills. But first let's address some issues that a vast majority of beginners run into. Many beginners ask what language they should be using. The answer is this: any language. Yes, that's right: C, C++, D, Java, Python, Lua, Scheme, or F#. And that's the short list. The language is just a tool. Using one language or the other does not matter. Don't worry about what the professionals are using. As a beginner, the only priority and goal is having the tools to create and complete the game. The second priority is to improve your code and skill. We'll get into that a bit later. Remember there is no "which language is better?" or "which language is best?". The only question anyone with experience will ask is: "How much experience do you have with the language?". At this stage in the game development journey, familiarity and skill with whatever language you are using is more important than the language itself. This is an universal truth. With your language of choice in hand, now is the time to choose how you will make the game. The choice normally is among a game development library, game engine, or a game maker. Which should you choose? If you are prototyping or are not a programmer, then a game maker would probably be the best choice. Game makers (ex: Game Maker, RPG Maker, ENIGMA) are able to create games (which I list later on) similar to the games of the 8-bit and 16-bit era. Game makers do some of the heavy lifting for you (ex: loading/handling image formats, input handling, integrating physics) and allow you to focus on the game itself. Most, if not all, game makers have a language specific to them to handle more advanced techniques and situations. The language more often than not is similar to C/C++/Javascript. Game engines such as Unreal, Crysis, and Unity handle all manner of games (ex: 2D, 3D, offline, online) and therefore are far more complex and in some cases complete overkill for the type of games a beginner should be making. Game engines should be used when you as a game developer have several games under your belt and fully understand the mechanics of making a game. For most beginner game developers, especially those who are programmers, choosing a game development library is a good choice. It puts those programming skills to the test and allows discovery of more things about the language. Like the language, the library doesn't matter. Whether it's SDL, SFML, PyGame (for Python only), or Allegro, the library is just another tool to create and complete the game. Game dev libraries have more or less the same features. So whichever you pick will be fine to get the job done. Finally after gathering our tools: language and game dev library or game maker software, we are ready to answer the most important question of all. "What game should I make?" For this question, the answer has to be approachable, doable, and for the most part understood. This is why the game that should be made should be 2D. Everyone understands 2D games. 2D games can be fancy but at its core they are basic with very few "moving parts". Believe it or not, the previous question has a definitive answer. And that answer is Pong. Now you may wonder, "why?". Well, Pong is one of the simplest games known. The graphics are simple and the mechanics are simple. There's no guesswork on how Pong should work. Therefore it's the best candidate for the first game to be made. Each new game that is presented in this article is meant to show something new and/or build upon what the last game taught you. The skills that are learned from each game become cumulative and not specific to just one game. So each game is a step up in terms of difficulty, but nothing a little brainpower and some brute force can't solve. Now I'll list some well-known games that will definitely help your game development skills and allow you to have actual complete games under your belt. I'll quickly point out some things that will be learned for each game. These games are: Pong = Simple: input, physics, collision detection, sound; scoring Worm = Placement of random powerups, handling of screen boundaries, worm data structure Breakout = Lessons of pong, powerups, maps (brick arrangements) Missile Command = targeting; simple enemy ai, movement, and sound Space Invaders = simple movement for player and enemy, very similar to breakout with the exception that the enemy constantly moves downward, simple sound Asteroids = asteroids (enemies) and player can move in all directions, asteroids appear and move randomly, simple sound Tetris = block design, clearing the lines, scoring, simple animation Pac Man = simple animation, input, collision detection, maps (level design), ai Ikari Warriors = top down view, enemy ai, powerups, scoring, collision detection, maps (level design), input, sound, boss ai Super Mario Bros = lessons of Ikari Warriors (except with side-view instead of top-down view), acceleration, jumping, platforms The list shows games in terms of difficulty from least to greatest as far as programming them goes. There are games that others may suggest but these 10 games will definitely round out what you need to know in 2D game development. If you can make and complete these games, then games like Sonic, Metroid, or even Zelda become that much easier. Those games are just variations or extensions of what you have already learned. Before I end this article, I would like to say something about completing the games. As I said above, your primary goal is making and completing the game. However, your secondary, and arguably just as important, goal is to refine your game. It's safe to say that 99% of programmers do not code Pong perfectly. Most likely your first or even second go around with Pong or Worm will not be a software architecture masterpiece. And it's not supposed to be. However, to improve your code and therefore your skill, you'll have to submit code for a code review. As all will attest to, this is A Good Thing TM. Allowing others to proofread your code will give you insights on better structure, better practices, and dangerous code that may work now, but may crash in the near or far future. Being introduced to good advice early in your game dev journey will save you from sudden and unnecessary meetings between your head and the keyboard. As you complete one game and move on to the next, do not kick that completed game to the corner. Go back (sooner rather than later) and refactor and improve the code. Doing so is proof that you understand the advice that others are giving you and shows that your skills have indeed become better. So in short, the process of making a game should be: create > complete > code review > refactor. Again, once you submit your code for review go on to the next game on the list, but remember to go back and improve that code after you get some feedback. If you've made it to the end of this article, you now have a path to start your game development journey. This article is meant to be a guide and not a be-all, end-all to game development. Hopefully the advice given here helps others start to become better game developers. NOTE: You can post code reviews in the For Beginners forum. Also, it is easier on the people checking your code if you post all the code in your post. Article Update Log 26 Mar 2013: Grammar edits, code review clarification 19 Mar 2013: Initial release