Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Brainstorming New Patreon Plans, Rewards, & Goals

Yotes Games



I'm brainstorming some new plans for making the Yotes Games Patreon a much bigger deal. My general idea is that I need to put more effort into my YouTube channel due to the level of engagement that gets out of people.

But I'd like to hear some feedback from you! It'd be super great to hear someone else's take on where I should take this crazy train next. Or hear exactly why you personally wouldn't donate to my Patreon but would to another. What rewards would you like to see? Should the project be more polished? I wanna know how to get strangers completely HYPED about this game!

Trying to emulate the success of ALBDifferent, Exiled, & YandereDev here, and a solid YouTube effort is the key ingredient I'm neglecting. Even just read an article today about how Fighting is Magic might not've exploded if that demonstration trailer didn't get shared left and right earning 900,000 views. Nerds like me read development blogs, but everybody watches videos. I outta make some videos.

Check out the huge list of ideas about how I'ma to do just that on the official development blog!


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By CharlieMarshall
      I have recently put together a small portfolio with the intention of going to developers to try get freelance work producing music for video games. 
      I am after some constructive criticisms and maybe a reality check as to weather my music is even close to good enough to present to developers asking for paid work. 
      Link to portfolio: https://cmarshallost.wordpress.com/
      Ill appreciate any feedback and advice, thanks.
    • By Brandon Sharp
      This is a project I've been working on for awhile now. I'd save over all going on around a year. I did the Machbot 2.0 all from scratch including the textures. I spent countless hours trying to figure out how to get the models from Twisted Metal. I finally figured out how to manually extract the mesh. But the only problem was it was not UV mapped. So i pretty much had to go back in and remap everything. Which wasn't hard but the assembling of the model itself was a challenge. I did the best I could at placing stuff where it goes I'm sure there are things that are incorrect. All in all it was for this one render. Not sure if my models can be used as game assets but i do want to eventually make this into a fighting game. Both vehicles and bots. Let me know what you think and thank your for checking out my work. 

    • By Ericjor
      Hello Gamedev users. I am new to this forum, and though I am quite proficient at understanding the basics of just about any form of science, I do not have the natural skill or patience needed to become a great programmer, so I ask that you be patient, and bear with me.
      So, to get to the point, I have thought up a peripheral that can potentially be used for various PC games. Without giving away too many details to those not interested in contributing, I will give as informative an explanation as possible. In theory, it will be activated in intense danger sequences, such as in a FPS firefight, melee combat and fight scenes in medieval style RPG's, etc. The difficulty is not in designing the device, but in implementing the program that would detect these scenes in-game. The software would be for Windows PCs, and made to work with as many games as possible.
      I have some experience with how modding works, and have considered how it could be used alongside currently released games such as Fallout 4, Battlefield, Call of Duty, Elder Scrolls Skyrim etc. However, I simply do not know enough about programming to determine the viability of integrating features into the software that would allow the danger scenes and combat gameplay of already released games to trigger the software to activate the peripheral. 
      Essentially I am wondering if this would this be something that could be integrated? If so, how could these combat sequences be detected by the software? 
      If you are interested and have something important to contribute, I can promise you a copy of the software and option to purchase the peripheral at cost if you would like. Depending on your motivation, I am open to working together. Even if you are not highly experienced, everyone has to learn somewhere.
      Whether or not you are interested, I would be grateful for all the advice you have to offer. So, any ideas for how something like this could be implemented?
    • By jb-dev
      As the gaming industry advances and evolves, new ideas can suddenly popup and change the way things goes in an instant.
      I've worked for 2 years in a Agile-centered startup. I've experienced first hand what agility can do to boost productivity and reduce development cost. It's a really simple and pleasant thing to work with agility, and maybe the gaming industry can benefit from it.
      The values
      Everybody that knows agility should be able to understand the core values of the Agile Manifesto.
      To put it simply, we should value:
      Individuals and interactions over process and tools;
      (i.e. work geographically close rather than remotely or value genuine conversations over Skype) Working software over comprehensive documentation;
      In our case, the game MUST be fun (or work correctly) before anything else Customer collaboration over contract negotiation;
      Basically, make the player more involved in the game's development Responding to change over following a plan.
      This is, of course, directly dependent of point 3 Also, keep in mind that it's mostly an hypothesis. As the manifesto states :
      Doing Agile vs. Being Agile
      During the past 2 years, our scrum master always warned us about the impostors, or the people that are "Doing Agility". Things like using a Kanban board or doing Daily Scrums wont make your team Agile. It's all about the values.
      These tools should be used to apply those values rather than using them just because it's a trend. 
      For exemple, some teams uses a Scrum backlog while locking it's content to everybody other that the project owner. This puts the project on rails, and can just be a waterfall process disguised as something agile.
      How can the gaming industry can benefit from it?
      As we keep seeing video games cost more and take a lot more time to develop, the customers grows more and more displeased: There are bugs-a-plenty on crucial mechanics, while relatively small and insignifiant functionalities are well polished and bug-free.
      Getting the game as fast as possible in the hands of beta players 
      The first thing to do is to involve the player as fast as possible in the game development's cycle. Doing that will significantly improve the player's sense of content and can make the game better. In the past, this kind of development wasn't practical, but, with the development of broadband, it's now possible.
      Early Access
      Nowadays, people talks about "Early Access". For those living under a rock, early access is a way of distributing a game in which the game itself isn't completed in a traditional sense. The customer then buys an somewhat incomplete game, of which many features will come later.
      This process is by far the best idea the industry never had.
      However, due to some mishandling of said practice, it's now regarded as a sing of cheapness and greed.
      If the ones doing it are agile impostors, then yes. There are times where games simply gets abandoned by their maintainer. These instances gives early access some bad name. 
      Early access should also be used in Agility in a form of customer collaboration. For example, one could ask a random early access player to participate in the planification of a sprint.
      If the team isn't confortable with the idea, then maybe a suggestion box can be plugged directly in the backlog...
      Prioritizing mechanics based on feedback
      Getting feedback form customers is an important thing in Agile Methodologies. The backlog can be prioritized based on player feedback and feature requests. 
      The same thing can be used on bugs. The more frequent it becomes, the more critical it becomes.
      Minimal efforts of development
      In most cases, the backlog should be prioritized based on business value rather that complexity. Being so, things that are developed first are important (or so the team thinks) to the game, while less important functions aren't implemented right away and have time to simmer down. Paired with early access, this becomes a quite powerful tool to test out hypothesis and experiment with mechanics.
      Due to the iterative process of some methodologies, functionalities are minimal and doesn't require a whole lot of effort to develop: after all, we have no idea if a mechanic is going to be loved or hated by a player until said players plays the game.
      Change prone games
      Another important argument is that Agility is generally speaking change tolerant. In our case, this means that if the beta players disliked or liked a newly implemented feature, then said feature should be remove and subsequent features should also be re-evaluated.
      The importance should always change based on discoveries made by the team or even the project owner. It is considered healthy for a backlog to change it's feature's priority. Otherwise, it's a bad omen...
      How about me?
      Agile is first and foremost a philosophy, or a way of life. Sure, it can easily be imposed to people, but it's in these situations that you get fake Agility. It should be a conviction more that a rule: a rule should be static and shouldn't change a lot. 
      Agility starts with the team. If one of it's member isn't committed, it will go sour really fast.
      I've seen so many times that Agility can be broken by a malicious person (a saboteur if you will). The best thing you can do to an Agile team is to be, yourself, agile.
      Agility should be an integral part of game development. With Agile, you can easily prioritize mechanics that are crucial for having a fun and interesting game.  
    • By Chadlee
      What's up everybody. The last time I posted here I got some very valuable feedback on a track. I also said I would come back when I had made something significantly better. This is it. 
      Im still new to this (less than a year) and appreciate any listens or comments.

Important Information

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

We are the game development community.

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

Sign me up!