Said about playable demo , wasn't you plan to have 1 soon ? As you making normal indie project (those AAA fund indie project don't count) , i think the most important is make something simple as possible . Make something playable then slowly upgrade it .
For example , if i have to chose between sword and gun , i rather use gun in my game cause there are less animation compare to chunky sword animation . If i have to chose between full fantasy building then i rather chose modern building , cause you can easy to passed some problem with it . While it kind of sound lazy , i but think it's better to make things work when you don't have large fund and time .
Specially MMO , while the making game fund is a problem , money to run it's the real problem . So save up for run it instead of spend too much on develop is better option IMO .
Said about playable demo , wasn't you plan to have 1 soon ? As you making normal indie project (those AAA fund indie project don't count) , i think the most important is make something simple as possible . Make something playable then slowly upgrade it .
For example , if i have to chose between sword and gun , i rather use gun in my game cause there are less animation compare to chunky sword animation . If i have to chose between full fantasy building then i rather chose modern building , cause you can easy to passed some problem with it . While it kind of sound lazy , i but think it's better to make things work when you don't have large fund and time .
Specially MMO , while the making game fund is a problem , money to run it's the real problem . So save up for run it instead of spend too much on develop is better option IMO .
Yes, my goal is to provide something the players can try out as soon as possible. Both to server as a demo or pre-release or pre-alpha or whatever.
Most likely, when I get the basics of building down I will release it. Obviously this is far from the real game, and is purely for the purpose of testing. As such there wont be any real gameplay elements, other than the chance to try out the mechanics and make suggestions based on the experience.
It's also important to actually test out the game, and find bugs.
And yes, I am also taking the approach of making this project as easy as possible for myself when it comes to content.
I guess I was hoping there'd be more people who would like to discuss theories for a game of this genre - even if the project itself is not far along the path.
So instead of community-driven development I find myself constantly defending the very basic of components.
There are actually plenty of us who like to discuss theories of game design, and mostly we are familiar with your genre, though it's not necessarily our favorite, and we aren't necessarily going to agree with your ideas about design principles and goals. But, we can't discuss your project in particular until we know what all your basic components and other features are, as well as why you have chosen them and whether you are willing to consider alternatives.
From the beginning of this thread, we barely knew what genre of game you wanted to make and didn't know what choices you had already made. We still don't know your full design. There's no need to feel defensive about it, but there is a need to explain your basics and your design goals before we can discuss any more complicated theory.
I want to help design and develop a PvE-focused, solo-friendly, sandpark MMO which combines crafting, monster hunting, and story. So PM me if you are starting one.
It will be hard to attract people to an idea alone. Your product likely won't get any sort of following until there is something tangible. A video on YouTube can do that - if you record a piece of your project and share it, people may come.
I am completely gobsmacked about the YouTube algorithm though. One of my earliest videos has 9000 views. Some of the more recent ones, which are arguably a lot more interesting, can't even get past 100. I tried length, voicing, different styles, tags, names - nothing seems to influence whether a video gets traction. It all feels a little random.
When it comes to these forums, people enjoy discussing specific concepts. I've asked about specific topics in the past and got great feedback. People didn't tell me how to design my game (I never asked for that), but they discussed on my threads about which crafting systems they like the most, etc.
Here is a quick overview of my workflow: I start thinking about a feature I want to implement. This is in very broad terms - I have a rough intuition of what the feature should accomplish. If the idea is too abstract, or if I'm not confident in my intuition, I ask around. If I ask on these forums, I come with a specific question. I read all the responses carefully, take a notepad and start sketching ideas on paper (based on my own game, based on what I'm trying to achieve, and also based on what people said on the forums). For example, the feedback I got here on crafting was very influential to what we finally came up with. Once I have a rough idea, I then go to my backend developer and discuss my idea with them for about an hour.
My developer knows the backend very well (very talented guy), so he will help me refine my idea to a shape that works with our implementation. I am the "project manager", so I need to be wary of the complexity of the stuff we set our sights on. As a result of my chat with the developer, we have a back and forth regarding the implementation. I recall coming to him with an item property system, we were discussing it for a few days. Over the week, the idea shifted from a static pre-defined property-driven system to a component-driven system. At the end of our chat, everyone should have a clear idea what it is we are implementing, how to do this (what the code will roughly look like in broad strokes), if we need to target a deadline and what other resources this might need.
If it's a brand new, experimental feature, either he or I then go and make a stand-alone prototype. I am playing around with a house building prototype this week. No point in even trying that in the actual game, if I don't know that the building placement even works in the engine. We see if there are any obvious flaws in the design. If not, we refine the prototype slightly and then put it into our codebase (to test it in the context of the game). Many times, we will realize something needs adjusting at this point. Often, the design needs to be tweaked slightly to account for something we didn't initially consider. We then push this feature into a testing build. Whoever is developing it (the developer does most coding, but I do work on something occasionally) tests it for any critical bugs and fixes them. We then make a networked build and test it with multiple people.
Finally, the feature gets pushed into a public build that I share with a few of our friends (who are nice enough to be our testers). We used to have a permanent server running which was really important as well - you want to see if your features can keep running on a server for multiple days in a row. We are just in the middle of a huge code rewrite, so the test server is down, but I hope to have it back up by Christmas.
Some features turn out to be boring only after a longer playthrough. Usually, this would only be discovered in our public playtests.
I guess I was hoping there'd be more people who would like to discuss theories for a game of this genre - even if the project itself is not far along the path.
So instead of community-driven development I find myself constantly defending the very basic of components.
There are actually plenty of us who like to discuss theories of game design, and mostly we are familiar with your genre, though it's not necessarily our favorite, and we aren't necessarily going to agree with your ideas about design principles and goals. But, we can't discuss your project in particular until we know what all your basic components and other features are, as well as why you have chosen them and whether you are willing to consider alternatives.
From the beginning of this thread, we barely knew what genre of game you wanted to make and didn't know what choices you had already made. We still don't know your full design. There's no need to feel defensive about it, but there is a need to explain your basics and your design goals before we can discuss any more complicated theory.
You're right. And even though I have posted some core ideas - they are not obvious, or instantly available.
However - the subject is obviously too big to be discussed in a single forum thread with several people. That's why I made a forum where things could be organized into bite-sized bits instead.
The subject of game design is too complex to be explained in linear fashion and the attention span of average by-passer is way too short to digest a single document containing it all.
However, I am available for any specific questions or discussions that someone wishes to ask.
It will be hard to attract people to an idea alone. Your product likely won't get any sort of following until there is something tangible. A video on YouTube can do that - if you record a piece of your project and share it, people may come.
I am completely gobsmacked about the YouTube algorithm though. One of my earliest videos has 9000 views. Some of the more recent ones, which are arguably a lot more interesting, can't even get past 100. I tried length, voicing, different styles, tags, names - nothing seems to influence whether a video gets traction. It all feels a little random.
When it comes to these forums, people enjoy discussing specific concepts. I've asked about specific topics in the past and got great feedback. People didn't tell me how to design my game (I never asked for that), but they discussed on my threads about which crafting systems they like the most, etc.
Here is a quick overview of my workflow: I start thinking about a feature I want to implement. This is in very broad terms - I have a rough intuition of what the feature should accomplish. If the idea is too abstract, or if I'm not confident in my intuition, I ask around. If I ask on these forums, I come with a specific question. I read all the responses carefully, take a notepad and start sketching ideas on paper (based on my own game, based on what I'm trying to achieve, and also based on what people said on the forums). For example, the feedback I got here on crafting was very influential to what we finally came up with. Once I have a rough idea, I then go to my backend developer and discuss my idea with them for about an hour.
My developer knows the backend very well (very talented guy), so he will help me refine my idea to a shape that works with our implementation. I am the "project manager", so I need to be wary of the complexity of the stuff we set our sights on. As a result of my chat with the developer, we have a back and forth regarding the implementation. I recall coming to him with an item property system, we were discussing it for a few days. Over the week, the idea shifted from a static pre-defined property-driven system to a component-driven system. At the end of our chat, everyone should have a clear idea what it is we are implementing, how to do this (what the code will roughly look like in broad strokes), if we need to target a deadline and what other resources this might need.
If it's a brand new, experimental feature, either he or I then go and make a stand-alone prototype. I am playing around with a house building prototype this week. No point in even trying that in the actual game, if I don't know that the building placement even works in the engine. We see if there are any obvious flaws in the design. If not, we refine the prototype slightly and then put it into our codebase (to test it in the context of the game). Many times, we will realize something needs adjusting at this point. Often, the design needs to be tweaked slightly to account for something we didn't initially consider. We then push this feature into a testing build. Whoever is developing it (the developer does most coding, but I do work on something occasionally) tests it for any critical bugs and fixes them. We then make a networked build and test it with multiple people.
Finally, the feature gets pushed into a public build that I share with a few of our friends (who are nice enough to be our testers). We used to have a permanent server running which was really important as well - you want to see if your features can keep running on a server for multiple days in a row. We are just in the middle of a huge code rewrite, so the test server is down, but I hope to have it back up by Christmas.
Some features turn out to be boring only after a longer playthrough. Usually, this would only be discovered in our public playtests.
Thank you for describing your process.
And I agree. In fact - I am starting to doubt my whole idea of "community-driven development".
I never meant it to be open-democracy style development. But expecting players to come up with concepts and ideas wildcard-like and expecting a decent result is being naive.
I do however have my own ideas, and as it stands right now - I am simply stepping forward with them.
I will however involve community in discussion, posting my progress and ideas as they come. And use open-development model. Fuck all "pay to be alpha-tester" and "crowdfunded AAA indie - never-getting-released" BS.
And I agree. In fact - I am starting to doubt my whole idea of "community-driven development".
I never meant it to be open-democracy style development. But expecting players to come up with concepts and ideas wildcard-like and expecting a decent result is being naive.
I do however have my own ideas, and as it stands right now - I am simply stepping forward with them.
I will however involve community in discussion, posting my progress and ideas as they come. And use open-development model. Fuck all "pay to be alpha-tester" and "crowdfunded AAA indie - never-getting-released" BS.
To me, community-driven development means keeping the community in the loop.
You should have an open line of communication with the community, keep them updated and make them feel like the game is being built around them.
The "select a feature" approach to community development is mostly a marketing gimmick. I did that on my Minecraft project and didn't feel it was very rewarding to any party. You'd list 4 features that are on your development schedule already, and have the community pick one. You'd deliver that one first while delivering the 3 others soon after anyway. If you were to genuinely do it, I don't think it would result in a cohesive experience.
One of my Minecraft players roleplayed a potato farmer and asked me to implement a profession dedicated to potato farming. We had 300 members and an active community of 30, so it didn't make sense to make a full potato farming profession to satisfy that request. Our professions there each had a unique mechanic and a lot of research went into them - we were looking at 2 weeks of my time to do that. I spent that time on creating jewelry making instead, which made a lot more sense given the state of the project.
I always had an open line of communication though - I think that's much more meaningful. If I was working on a feature (let's say making big changes to the political system), I'd go to the relevant people in the community, ask them for feedback. You can do this via a thread, where people comment on your plans via your forums. I preferred to actually do it in person - talk to people in the community one by one (or in some sort of a group chat). This does a couple of things:
People feel personal attention, becoming much more invested in the project.
You get to see your players' perspective on things.
You get to explain your reasoning. Many times players think they want feature A, but if you explain the design process in person (as a dialogue), they might understand why feature B is more beneficial.
They get to see that activity is rewarded. A new player joins the community and sees that key members know a fair bit about the development. The systems implemented will be tightly linked with those who gave feedback on them, so everyone in the community feels like it's their own game.
The "key" members convert to paying members voluntarily. I never had to worry about this (all of my projects are basically hobbies - I set them all up in a way where I can finance them with no income from players). But in all of my projects, people voluntarily came forward about wanting to contribute financially - all of these were members of the player base invested in the development process.
You're right. And even though I have posted some core ideas - they are not obvious, or instantly available.
However - the subject is obviously too big to be discussed in a single forum thread with several people. That's why I made a forum where things could be organized into bite-sized bits instead.
The subject of game design is too complex to be explained in linear fashion and the attention span of average by-passer is way too short to digest a single document containing it all.
However, I am available for any specific questions or discussions that someone wishes to ask.
Well, even on your forum you're going to want to have a "What is the game?" thread which you direct new forum members to look at first. And that thread should probably start with a post which is something like:
1. A paragraph about what kind of game you are dreaming of, and why you think this is great. This is called a "statement of purpose" or "philosophy of design".
2. A description of the game's genre and a list of its basic features.
I want to help design and develop a PvE-focused, solo-friendly, sandpark MMO which combines crafting, monster hunting, and story. So PM me if you are starting one.
Comments
As you making normal indie project (those AAA fund indie project don't count) , i think the most important is make something simple as possible .
Make something playable then slowly upgrade it .
For example , if i have to chose between sword and gun , i rather use gun in my game cause there are less animation compare to chunky sword animation .
If i have to chose between full fantasy building then i rather chose modern building , cause you can easy to passed some problem with it .
While it kind of sound lazy , i but think it's better to make things work when you don't have large fund and time .
Specially MMO , while the making game fund is a problem , money to run it's the real problem . So save up for run it instead of spend too much on develop is better option IMO .
Yes, my goal is to provide something the players can try out as soon as possible. Both to server as a demo or pre-release or pre-alpha or whatever.
Most likely, when I get the basics of building down I will release it. Obviously this is far from the real game, and is purely for the purpose of testing. As such there wont be any real gameplay elements, other than the chance to try out the mechanics and make suggestions based on the experience.
It's also important to actually test out the game, and find bugs.
And yes, I am also taking the approach of making this project as easy as possible for myself when it comes to content.
From the beginning of this thread, we barely knew what genre of game you wanted to make and didn't know what choices you had already made. We still don't know your full design. There's no need to feel defensive about it, but there is a need to explain your basics and your design goals before we can discuss any more complicated theory.
I am completely gobsmacked about the YouTube algorithm though. One of my earliest videos has 9000 views. Some of the more recent ones, which are arguably a lot more interesting, can't even get past 100. I tried length, voicing, different styles, tags, names - nothing seems to influence whether a video gets traction. It all feels a little random.
When it comes to these forums, people enjoy discussing specific concepts. I've asked about specific topics in the past and got great feedback. People didn't tell me how to design my game (I never asked for that), but they discussed on my threads about which crafting systems they like the most, etc.
Here is a quick overview of my workflow:
I start thinking about a feature I want to implement. This is in very broad terms - I have a rough intuition of what the feature should accomplish. If the idea is too abstract, or if I'm not confident in my intuition, I ask around. If I ask on these forums, I come with a specific question. I read all the responses carefully, take a notepad and start sketching ideas on paper (based on my own game, based on what I'm trying to achieve, and also based on what people said on the forums). For example, the feedback I got here on crafting was very influential to what we finally came up with. Once I have a rough idea, I then go to my backend developer and discuss my idea with them for about an hour.
My developer knows the backend very well (very talented guy), so he will help me refine my idea to a shape that works with our implementation. I am the "project manager", so I need to be wary of the complexity of the stuff we set our sights on. As a result of my chat with the developer, we have a back and forth regarding the implementation. I recall coming to him with an item property system, we were discussing it for a few days. Over the week, the idea shifted from a static pre-defined property-driven system to a component-driven system. At the end of our chat, everyone should have a clear idea what it is we are implementing, how to do this (what the code will roughly look like in broad strokes), if we need to target a deadline and what other resources this might need.
If it's a brand new, experimental feature, either he or I then go and make a stand-alone prototype. I am playing around with a house building prototype this week. No point in even trying that in the actual game, if I don't know that the building placement even works in the engine. We see if there are any obvious flaws in the design. If not, we refine the prototype slightly and then put it into our codebase (to test it in the context of the game). Many times, we will realize something needs adjusting at this point. Often, the design needs to be tweaked slightly to account for something we didn't initially consider. We then push this feature into a testing build. Whoever is developing it (the developer does most coding, but I do work on something occasionally) tests it for any critical bugs and fixes them. We then make a networked build and test it with multiple people.
Finally, the feature gets pushed into a public build that I share with a few of our friends (who are nice enough to be our testers). We used to have a permanent server running which was really important as well - you want to see if your features can keep running on a server for multiple days in a row. We are just in the middle of a huge code rewrite, so the test server is down, but I hope to have it back up by Christmas.
Some features turn out to be boring only after a longer playthrough. Usually, this would only be discovered in our public playtests.
You're right. And even though I have posted some core ideas - they are not obvious, or instantly available.
However - the subject is obviously too big to be discussed in a single forum thread with several people. That's why I made a forum where things could be organized into bite-sized bits instead.
The subject of game design is too complex to be explained in linear fashion and the attention span of average by-passer is way too short to digest a single document containing it all.
However, I am available for any specific questions or discussions that someone wishes to ask.
Thank you for describing your process.
And I agree. In fact - I am starting to doubt my whole idea of "community-driven development".
I never meant it to be open-democracy style development. But expecting players to come up with concepts and ideas wildcard-like and expecting a decent result is being naive.
I do however have my own ideas, and as it stands right now - I am simply stepping forward with them.
I will however involve community in discussion, posting my progress and ideas as they come.
And use open-development model.
Fuck all "pay to be alpha-tester" and "crowdfunded AAA indie - never-getting-released" BS.
You should have an open line of communication with the community, keep them updated and make them feel like the game is being built around them.
The "select a feature" approach to community development is mostly a marketing gimmick. I did that on my Minecraft project and didn't feel it was very rewarding to any party. You'd list 4 features that are on your development schedule already, and have the community pick one. You'd deliver that one first while delivering the 3 others soon after anyway. If you were to genuinely do it, I don't think it would result in a cohesive experience.
One of my Minecraft players roleplayed a potato farmer and asked me to implement a profession dedicated to potato farming. We had 300 members and an active community of 30, so it didn't make sense to make a full potato farming profession to satisfy that request. Our professions there each had a unique mechanic and a lot of research went into them - we were looking at 2 weeks of my time to do that. I spent that time on creating jewelry making instead, which made a lot more sense given the state of the project.
I always had an open line of communication though - I think that's much more meaningful. If I was working on a feature (let's say making big changes to the political system), I'd go to the relevant people in the community, ask them for feedback. You can do this via a thread, where people comment on your plans via your forums. I preferred to actually do it in person - talk to people in the community one by one (or in some sort of a group chat). This does a couple of things: