Show Posts
61
General discussions / Re: SFML 3 - What is your vision?
« on: October 10, 2014, 11:23:33 pm »
One example of explicit stratification would be a "marquee" interface / abstract class which doesn't exist in strata 0, does exists in strata 1, and perhaps exists with additional switches and options in strata 2.
The interface or abstract class would be inherited by the Sprite and Text classes. Its function is to provide the programmer a way indicate that a specific texture or text should be clipped to a small rectangular region, and that the region is what is being drawn. You could use the state of the marquee to scroll the text side to side or to indicate that the space should be a loop like what you might see on big LED signs that advertise various things. You could also set the state to scroll continuously or discreetly and be commanded by time or call-- so you could implement a sprite sheet with the marquee system, or you could create a very long and narrow sprite that represents hundreds of projectiles and just loop it as described above for looping text.
In strata 1 it would include finer control, so that the region that it is drawn onto isn't specifically a rectangle, but can be any user defined shape and pair of edges belonging to that shape to form a "ribbon". There might be more rendering control so that people can create layered special effects using hardly any texture space or any more overhead than it takes to change local view space coordinates and do some clipping and "stretching" on the texures.
Now that isn't something I necessarily need in SFML or probably something that most people need. I'm just giving an example of what stratification is.
The point is to make MASTERING sfml easier by reducing the skill curve. You reduce the amount of options and you also reduce the complexity. Then people can master a subset of the functionality of SFML proper, and when they are content with that and really are being held back by the lack of options they can move up one stratification level and learn more things and do more things. That increases the rate at which newbie users develop into expert users.
The Stratas do not have differing design philosophies, they just have different audiences. Strata 0 does not try to provide a way to do everything with enough effort, it is supposed to provide an extremely simple interface for doing simple things that allow you to "get a feel" for what SFML is and what the higher stratas do in the general sense.
People who are experts with SFML or who are practicing software engineers probably could just read the documentation and know pretty much instantly what SFML is capable of. What I'm saying is that it isn't necessary to limit your audience because you can have your cake and eat it to. You can please everyone. You can have power for those that want power and simplicity for those that need simplicity above all else, just by stratifying your API. The cost of that design direction is the same as the cost of splitting your userbase into 3 parts, or subcommunities. If there isn't enough motivation in one subcommunity it can fracture the userbase and cause the "pipeline" to fail.
In order to prevent that from happening you would just need to carefully consider what each sub community needs from a media library and carefully design the stratification to meet the needs of the user base. That means writing software for the consumer rather than software for the sake of fulfilling a philosophical idea of what "simple" ought to be.
If software can bring people together, cause them to want to instruct eachother, communicate a tangible sense of achievement (through stratification), endow a sense of responsibility, and be powerful enough to do everything the user could want while being concise enough for the user to comprehend then people will use it regardless of what the word or idea "simple" really means.
As for HOW stratas are implemented, whether by having one API be a subset of another or just artificially through the tutorial is something I consider an implementation detail. It doesn't matter how such a thing is implemented as long as the implementation is effective and it actually organizes the community into discreet classes of users.
The fact is that newbies who ask questions some times get answers that they can't understand because the person answering them presumes an understanding about many different things, when a simple and less accurate explanation which is atleast comprehendable would be infinitely more useful. People iterate. They learn, unlearn, and relearn until they approach an understanding that represents the truth. Giving someone a terse answer that you worked for 3 years to understand may not be appreciated, and this causes a communication breakdown between these classes of users.
By putting people into classes of other people who have roughly the same familiarity with the API, they can work off of eachother's expertise by providing answers and questions that everyone in that subcommunity can understand. By putting incentives to higher strata communities to answer outstanding questions or problems that the lower strata community cannot resolve on its own, you build a positive flow, where some users in a lower community eventually become practiced and familiar enough with one strata to master then next higher one and to contribute to the associated next higher sub community.
The increase in the total number of "SFML Masters" due to the increased flow can cause a wider and more impressive variety of things to be created by SFML users, which can draw in more "newbie" users, and what you have is like a social version of a jet engine where the faster you go the more air you take in and the faster you go.
The interface or abstract class would be inherited by the Sprite and Text classes. Its function is to provide the programmer a way indicate that a specific texture or text should be clipped to a small rectangular region, and that the region is what is being drawn. You could use the state of the marquee to scroll the text side to side or to indicate that the space should be a loop like what you might see on big LED signs that advertise various things. You could also set the state to scroll continuously or discreetly and be commanded by time or call-- so you could implement a sprite sheet with the marquee system, or you could create a very long and narrow sprite that represents hundreds of projectiles and just loop it as described above for looping text.
In strata 1 it would include finer control, so that the region that it is drawn onto isn't specifically a rectangle, but can be any user defined shape and pair of edges belonging to that shape to form a "ribbon". There might be more rendering control so that people can create layered special effects using hardly any texture space or any more overhead than it takes to change local view space coordinates and do some clipping and "stretching" on the texures.
Now that isn't something I necessarily need in SFML or probably something that most people need. I'm just giving an example of what stratification is.
The point is to make MASTERING sfml easier by reducing the skill curve. You reduce the amount of options and you also reduce the complexity. Then people can master a subset of the functionality of SFML proper, and when they are content with that and really are being held back by the lack of options they can move up one stratification level and learn more things and do more things. That increases the rate at which newbie users develop into expert users.
The Stratas do not have differing design philosophies, they just have different audiences. Strata 0 does not try to provide a way to do everything with enough effort, it is supposed to provide an extremely simple interface for doing simple things that allow you to "get a feel" for what SFML is and what the higher stratas do in the general sense.
People who are experts with SFML or who are practicing software engineers probably could just read the documentation and know pretty much instantly what SFML is capable of. What I'm saying is that it isn't necessary to limit your audience because you can have your cake and eat it to. You can please everyone. You can have power for those that want power and simplicity for those that need simplicity above all else, just by stratifying your API. The cost of that design direction is the same as the cost of splitting your userbase into 3 parts, or subcommunities. If there isn't enough motivation in one subcommunity it can fracture the userbase and cause the "pipeline" to fail.
In order to prevent that from happening you would just need to carefully consider what each sub community needs from a media library and carefully design the stratification to meet the needs of the user base. That means writing software for the consumer rather than software for the sake of fulfilling a philosophical idea of what "simple" ought to be.
If software can bring people together, cause them to want to instruct eachother, communicate a tangible sense of achievement (through stratification), endow a sense of responsibility, and be powerful enough to do everything the user could want while being concise enough for the user to comprehend then people will use it regardless of what the word or idea "simple" really means.
As for HOW stratas are implemented, whether by having one API be a subset of another or just artificially through the tutorial is something I consider an implementation detail. It doesn't matter how such a thing is implemented as long as the implementation is effective and it actually organizes the community into discreet classes of users.
The fact is that newbies who ask questions some times get answers that they can't understand because the person answering them presumes an understanding about many different things, when a simple and less accurate explanation which is atleast comprehendable would be infinitely more useful. People iterate. They learn, unlearn, and relearn until they approach an understanding that represents the truth. Giving someone a terse answer that you worked for 3 years to understand may not be appreciated, and this causes a communication breakdown between these classes of users.
By putting people into classes of other people who have roughly the same familiarity with the API, they can work off of eachother's expertise by providing answers and questions that everyone in that subcommunity can understand. By putting incentives to higher strata communities to answer outstanding questions or problems that the lower strata community cannot resolve on its own, you build a positive flow, where some users in a lower community eventually become practiced and familiar enough with one strata to master then next higher one and to contribute to the associated next higher sub community.
The increase in the total number of "SFML Masters" due to the increased flow can cause a wider and more impressive variety of things to be created by SFML users, which can draw in more "newbie" users, and what you have is like a social version of a jet engine where the faster you go the more air you take in and the faster you go.