Anonymous asked: So for game developers who are closer to indie in terms of budget, how can they best manage to still get solid marketing without going over budget?
There was a very solid GDC talk given this year on marketing games with zero budget. The six core principles behind it are:
Step 1: Figure out what’s exciting about your game and focus on getting that message out (trailer, press release, etc.). Remember, the important part is the interesting bit can be difficult - test your pitch with various people to figure what is the most exciting, because things you’re excited about aren’t necessarily the thing players will be excited about. It’s probably going to be what you’re offering to players that nobody else is.
Step 2: Make sure there’s a place for your audience who are interested to congregate. After they watch your trailer and/or visit your website, how will you engage with them? It could be a subreddit, a forum, a discord server, whatever, but you need to provide these interested players a reason to stay on with the community. This means you need to spend some time engaging with them in the community, but you can also provide value for participating in the community - beta tests for community members, special in-game recognition of the community members, disseminating info in the community first, etc.
Step 3: The public image of the game is super important. You want the public image of the game to be what the players expect, and the public image will inform the players as to expectations regarding game size/scope, cost, and value. It needs to be sufficiently interesting and different on its own so that players can pick it out from the dozens of other games that will be releasing that same week.
Step 4:
Do the legwork to maximize your chances of success.
Engage with your community and build a presence of interested players, especially via newer channels like livestreams. Leverage your growing community to help get the word out, especially those who build fansites or create content for your game. Use the numbers from your engaged community as a selling point to potential business partners.
Step 5: Drop your ego and pride and ask for stuff from potential business partners. Talk to the platforms. Ask for the platforms like Steam, Xbox, iOS, Google Play, etc. to help out. Using a discord server? Talk to Discord. Twitch streams? Try contacting Twitch.tv directly. Subreddit? Maybe you could talk to somebody at Reddit. Build a presence on big platforms like Facebook, Twitter, etc. but don’t neglect the smaller platforms too, like Microsoft’s Mixer streaming service. Smaller platforms are more hungry for new and interesting content, and are more amenable to making deals with indies. Cold call their business folks regarding your game, show them your trailer and press releases. They probably won’t come to you, but you might be able to find some of them willing to listen if you throw out enough. Then you can try to hash out a deal. Nobody is going to know about your product unless you tell them.
Step 6: Be realistic about what you expect. As of the video, the average Steam game earned about $12,500 in its first month and $30,000 in its first year. Do some realistic planning for various scenarios - worst case, not-as-bad-as-worst case, expected case, etc. for what this means for the team, scope, the next 6-12 months, etc.
The important takeaways are to craft the proper public image for your game in order to set expectations, build a community for interested players to congregate and engage with them, and leverage your community and public image to establish partnerships and deals with as many other business partners and platforms as you can. Since you don’t have the budget for marketing, you need to task somebody to do the legwork and put in the time to handle all this stuff. But these are some good core principles for building a presence among players and increasing your chances of success without incurring significant financial cost. I wish you good fortune!
The FANTa Project is currently on hiatus while I am crunching at work too busy.
Anonymous asked: I don't really get it. If gamers don't know anything about the industry as is consistently made clear to us, why did Ms. Price expect Deroir to know the finer nuances of her -own- personal experiences of sexism at work in depth enough that even a polite criticism is sexist? I usually like siding with game devs, but this just seemed really unnecessary. :c
He told her about a concept that she was already far more familiar with than he and then told her it would solve the problem. She got angry because this was the latest in a never ending stream of dudes with no dev experience explaining concepts to her that she is already intimately familiar with and then telling her how to use them, so she snapped at him. He was polite, but he didn’t ask a question or start a dialogue - he told her that branching dialogue was the solution to the problem she posed. Being polite doesn’t somehow make what he said less patronizing.
Let’s try a thought exercise. Imagine that you’re an expert in a specific field like baking cupcakes. You’ve been baking cupcakes professionally for over a decade and you’ve been recognized for it. You know cupcakes like the back of your hand - how much flour, how much sugar, how many eggs, how long to bake, butter vs vegetable oil, salt, vanilla, types of sugar, what temperature to bake at, frosting ingredients, frosting techniques, mini cupcakes vs full-sized, even the economics of buying ingredients and scheduling necessary to deliver an order. You know it all because you’ve been doing it for years. Whenever somebody asks you a question about what kind of cupcakes to order, your mind automatically comes up with a dozen different types of cupcakes and the pros and cons of each kind because you know them so well.
You’ve just had an in-depth discussion on how baking cupcakes for a large corporate event is very different from baking for a child’s birthday party. There’s notable differences in flavor profiles, ingredient lists, decoration techniques, and so on because the people consuming the cupcakes are going to be different and care about different things. Adults care more about depth of flavor, children much prefer bright colors and more elaborate presentation.
Now imagine that some guy you just met who loves eating cupcakes but has never baked one in his life tells you “Oh that’s super interesting! However, allow me to disagree slightly. You should just make red velvet cupcakes. Everybody loves red velvet cupcakes.”
I don’t know about you, but I would certainly be at least a little annoyed by this person. Not only has this person ignored the nuance of the situation involved, but he has completely ignored all of your expertise and instead told you to do something that you are already intimately familiar with - you’ve already baked and sold thousands of red velvet cupcakes over the course of your career. You know why red velvet wouldn’t work, because you’ve tried it and have seen the results to prove it.
Now imagine that this isn’t an isolated incident. People who occasionally eat cupcakes come up to you all the time and tell you to just make red velvet, or just make oreo cupcakes, or just bake carrot cakes, or chocolate cakes, or just use fondant instead of buttercream. They don’t ask you respectfully, they tell you that you’re doing it wrong and should do what they say despite the massive difference in expertise. This happens day in and day out, hundreds, thousands of times. Finally, you snap at the thousandth person this month to say this sort of thing to you by saying “Thanks for telling me how to do my job, dude”.
He responds with “You getting mad at my obvious attempt at creating dialogue and discussion with you, instead of just replying that I am wrong or otherwise correct me in my false assumptions, is really just disheartening for me. You do you though. I’m sorry if it offended. I’ll leave you to it.”
There was no “obvious attempt at dialogue or discussion”. He literally told you to make red velvet just like all the others. But because you push back, he plays the crowd for sympathy and goes passive aggressive because you called him out for telling you how to do your job. He just made a simple and polite “suggestion” and you hurt his feelings. Suddenly you’re the bully in this situation.
As I said in my original post - I don’t agree with the lashing out, but I do understand, sympathize with, and agree with Price’s assessment of the situation. I think that ArenaNet made a huge mistake by firing her and Fries. It kills their team morale and it scares away potential recruits. I don’t think she is blameless - I think she probably should have been reprimanded and publicly apologized. However, I also think ArenaNet should have had her back instead of firing her.
I, personally, don’t engage with fans directly about my projects on social media because I am paranoid about this sort of thing and highly value my anonymity. But I also recognize that my choice deprives my game’s community of a lot of the interesting dialogue and discussion that they could have had if I didn’t feel like I have to watch my own back so much. I think it sucks that a dev posting publicly means that they are on the clock as representatives of their companies 24/7. If you ever wondered why devs have to be so tight-lipped about talking with the gaming community, this is why. If we do and ever mess up, we get harassed and now we get fired.
The FANTa Project is currently on hiatus while I am crunching at work.
Anonymous asked: As for programming, I'm having difficulty maintaining a good level of productivity. When I'm working on a new feature for my game, I always end up spending a lot of time trying to figure out how this new feature will interact with everything I've already implemented, and everything I'm going to implement, to keep my project from becoming a mess . But sometimes (alright, many times), I spend days thinking about the problem and not reaching a good solution. What do I do? I am losing a lot of time.
Whenever I think about building a new system, I think of it like a box with a specific set of inputs on one side and outputs on the other. If you open the box, you will see that it contains a bunch of internal logic that takes the inputs and calculates the outputs from them. A large box might even contain several smaller boxes inside that are invisible from the outside.
However, you can also close the outer box and still trust it to do what you want it to do. When I have a code task that needs doing, the first thing I do is establish what inputs I have and what outputs I need from it.
Let’s try an example. Say I’m outlining a very basic experience level system. This system will keep track of experience points earned, then increase the player’s level when certain thresholds are reached. It won’t do anything else (yet), because we can have a separate character stat system and a character ability system and such that can behave based on the character’s level. So let’s break this down - a very basic experience level system.
What goes into it?
Any time the player gains experience points, the experience level system must know how much experience it has obtained.
It needs to specify a specific asset to read from (like an experience table spreadsheet) so it knows how many experience points are necessary to reach which level.
It needs to be able to field requests for information about what level the player is from other systems, how much experience the player has earned, and how much is needed for the next level
It will probably need a way to bypass the regular experience gain method for debugging purposes… a special debug-only input that will generate enough experience points to set the player at a specific level to test level-gated parts of the game.
What comes out of it?
The player’s current experience level
Maybe the total number of experience points earned so far
Maybe the number of experience points needed to reach the next level
Maybe it will send an event out to notify other game systems whenever the player has gained a new level
These inputs and outputs can be organized into a programming interface - a set of functions that can be called from other parts of the game that will pass in the data the experience system needs and provide the information that the other parts of the game want (e.g. the UI will want to know what the character’s level is so it can display it).
You don’t need to actually make it do these things yet - you’re just establishing the parameters and limits of the system’s box. You can put in some placeholder functions first just so you have some code to test, for example. You can then assume that it will (eventually) do these promised things once you’ve finished the planning and implemented the system. Then you can look at how your different system boxes connect to each other in the bigger overall picture. When you actually finish the planning for your system you can start making it do what you promised it would. It should take the given the inputs that you’ve established that it needs, and present the outputs that you promised it would give.
Why should I care?
Think about it. By establishing the inputs and outputs of your system, you’ve effectively figured out its limits. You know exactly what it needs to function, and how other systems will interact with it. Once you’ve established the limits, you can write the necessary code to fill in the gaps. Nailing down those limits and parameters is the fastest way to get a system ready to work. It also provides a good mentality to break down complex hard-to-solve problems into simpler, easily solvable components.
First figure out where your starting point and finish line are. Then figure out how to get from one to the other.
