Moderators

52

14014

Moderators

20

8335

Moderators

20

14399

Moderators

15

10845

## Popular Content

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

1. 5 points

## Will we ever see an adoption of something other than C and C++?

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

3. 4 points

## Cache Coherency and Object Update

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

5. 4 points

## What do you think about JAI

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

## Marching Cubes with Multiple Materials

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

## Windows Raw Input virtual Key consts?

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

## Status Effects (Buffs Debuffs) in an ECS Architecture

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

## Will we ever see an adoption of something other than C and C++?

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

## What languages should a person learn to be a well-rounded programmer?

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

## Will we ever see an adoption of something other than C and C++?

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

## What do you think about JAI

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

## What do you think about JAI

Wake me up when it actually ships.
14. 3 points

## Linear games - what do you want to see improved on in linear, cinematic stories?

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

## Making Breakout - Code Structure help requested

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

## How to design world, player, obstacles etc classes so they can communicate, which class does what?

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

## How to design world, player, obstacles etc classes so they can communicate, which class does what?

"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

## Books on MMORPG engineering

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

## ECS : same transformation component for both physic and graphic

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

## TextureCube sampling

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

## Xor contents of an object with virtual function

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

## to_lower function entering an infinite loop

Except that code doesn't find "abac" in the string "ababac". Correctness matters.
23. 2 points

24. 2 points

## What languages should a person learn to be a well-rounded programmer?

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

## Slow site?

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

## What do you think about JAI

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

## How to design world, player, obstacles etc classes so they can communicate, which class does what?

"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

## What do you think about JAI

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

## Making Breakout - Code Structure help requested

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

## Do cheat codes still have a place in single player games?

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

## What is the Unity equivalent of console.Readline?

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

## Making Breakout - Code Structure help requested

https://gafferongames.com/post/fix_your_timestep/
33. 2 points

## Is there a tool to write C++ code to a file

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

## When is lag compensation needed?

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

36. 2 points

## Stop hacking

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

38. 2 points

## Important Information For Your First STEAM Release

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

No.
40. 2 points

## Coding Guidelines

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

42. 2 points

## Understanding probabilities of getting certain items?

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

## What am I not understanding about programming?

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

## Career Advice: What jobs do you think I should be looking for given my current skillset?

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

46. 2 points

## Beginner in need of guidance

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

## Beginner in need of guidance

Why not just jump into GameMaker and see where it takes you?
48. 2 points

## Making Breakout - Code Structure help requested

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

## Your First Step to Game Development Starts Here

1. 1
2. 2
3. 3
4. 4
frob
14
5. 5
• ### Member Statistics

• Total Members
237097
• Most Online
6110