I've been thinking about this lately, and I wonder how much of the problem is a result of the games themselves. A majority of games, and almost all "real games" (as categorized by people who identify themselves as gamers), are not only violent, but portray violence as the most straight forward way to resolve conflict.
If someone is truly engrossed in a medium where the default interpersonal resolution method is to "defeat" the opposing party by whatever rules are deemed legal by the system, it's not hard to see why every time that person is provided with an alternate viewpoint it would be met with toxic hostility.
If the only tool you have is a gun or sword, everything looks like a target or monster.
As a side note, I've been finding puzzle and adventure games much more appealing as of late because it's not all about killing other people.
I get that a lot of games aren't about such things, even if weapons and shooting are their medium; but it seems like a few choice games recently have been about that and it's really awkward. The new Killzone is about two racist factions where you basically play the bad guys, for example.
On the other hand, games like League of Legends and Counter Strike may have death, but they have about as much impact as getting shot with a paintball round. It's a way to say 'tag' in an effective way (Counter Strike) , or to push someone out so you can complete your objective (League of Legends), and those are just normal sporting activities.
I don't know. Pardon me while I wave my cane and yell loudly to get off my lawn, but I agree with you about these sorts of issues in recent games.
I agree, but there are problems with dressing up a game of "tag" like Counter-Strike in the clothes of violent conflict. The other day a contractor came to my house as I was playing CS:S. He asked if I was in Baghdad. He translated the Arabic on the walls. I realized he might find this game incredibly offensive. Racially ambiguous terrorists fight whiteish police in often middle eastern locales (dust2...?). The game itself is normalizing or maybe is just an example of normalized, simplistic, xenophobic ideas. It is a game of tag and strategy that you might compare to american football in some ways, but its stylized to attract people interested in participating in this "world" of us vs. them, all conflicts are solved by violence fantasy land that has none of the nuance of real life. Is that a problem? Is it a symptom of some of the attitudes the author talks about re. insecurity and fear in "gamers"?
I see it less being an issue of violence, and more of an issue of conflict being the only means of resolution. It's become so pervasive, that a game where you don't fight or compete against SOMETHING is considered very weird.
As for puzzle and adventure games, have you tried Antichamber or Gone Home? Those two are among my favorite games to have come out this year.
I'm working through Gone Home right now. I had no idea what the story was going to be about when I bought it. I thought it was a horror game. It's good so far, to say the least.
I shall continue playing it in the coming days / weeks.
One perspective is that this "real gaming" is like a sport with the physical component completely removed and the players completely segregated. There's zero stress to your cardiovascular system and zero possibility of physical injury due to contact. In other words you're free to run your mouth while enjoying the hormonal surges of high competition in an anonymous setting. I don't think that makes a trash talker a maladjusted social misfit though.
They're running Macs or Linux and never see the garbage when they're designing their sites. The poor rendering only occurs when you use GDI to render the text which is only used by Chrome on Windows (and Firefox in Windows XP, but not Vista/7/8).
This is a reaction to Arielle Schlesinger: "In the scope of my research, a feminist programming language is to be built around a non-normative paradigm that represents alternative ways of abstracting. The intent is to encourage and allow new ways of thinking about problems such that we can code using a feminist ideology." And she wasn't joking. http://www.hastac.org/blogs/ari-schlesinger/2013/11/26/femin...
Do it for yourself. Don't worry about comparing your work to others. If you make something you yourself are proud of, then what does it matter if Notch or Terry Cavanagh are participating?
I suppose you're right. I was surprised at how few people took part in the mini I did (#40 http://www.ludumdare.com/compo/?p=221661).
I wonder whether the main LD entries get more or less feedback than the minis. It seems like it could go either way. The larger volume of submissions could make it less likely that people find yours.
There's a pretty decent discovery mechanism. The more you rate, the closer you are to the front page. It's not perfect, but I don't think I've gotten less than, say, 50 people rating my games (http://www.ludumdare.com/compo/author/mscottmcbee/ If you're interested).
Rate others, leave comments, and people will play your game.
I think this is mostly a reflection of tech/science reporting. Batteries are hard. They're complex with many factors into what goes into a good battery. But the moment a lab creates one with good energy density, headlines just say "Scientists create batteries 20x greater than your iPhone" without paying attention to the fact that it has 20 charging cycles before it's useless.
I don't do much web development, just a product once every year or so to play around with an idea. Always in PHP. A few months ago I was asked by a close friend to help them with a not-so-serious site. I decided that I'd use Rails, because, hey, I've heard nothing but good about it from HN and the like.
I was absolutely blown away by how much work it required to get started. That, and how painful it was to explain to a non technical person how to make visual changes.
I was told by a few friends I vented to that what I was doing was "too small" of a project, or "Rails is meant for web apps" which confused me because I assumed a site where you could upload images via a form and then browse and view them was right up its alley.
Edit: A lot of comments are talking about wrapping my head around the framework, MVC, ect. I had no problem building the initial application. My sore points are more about deployments and updating smaller things, like the image of a link. non-technical people don't often remember "oh, and if you want your change to show up, go to this folder, open 'restart.txt' and change it in some way. doesn't matter what, just add a space to the end".
You're making the mistake of conflating PHP the language with Rails the Framework.
I can do your app in Rails pretty damn quickly at this point (with one of my current skeleton frameworks I can add authentication administration and other nice features pretty much "for free" as well)
But tell me I have to do it CodeIgniter or Laravel and I'd be completely lost for days.
By the time your "non-technical folks" are editing templates, you have a problem regardless of your language/framework. If you only have enough knowledge to "add an image" stay out of my HTML!
> You're making the mistake of conflating PHP the language with Rails the Framework.
I've heard someone call PHP "the C web framework". I thought it was fitting, and in addition, it seemed that even as a C web framework, it was a failure.
If you were to start with a nearly blank slate in regards to your PHP knowledge + Laravel as a framework for example, throw in Composer, learning about Eloquent ORM and so on, you'd likely be facing the same reaction.
I'd like to also point out that if you want to do software dev by the book applying various sofware engineering principles and not just stringing something together that works, you're pretty much forced to use a framework. (either due to lack of time or lack of skills for building one the right way).
Sure, sometimes the most important thing is rolling something up quickly, but other times your project will be used by more than a handful of people, and/or you'll have expectations of producing monetizable value and anticipate regular maintenance/upgrades for which a different strategy is required.
3rd generation full stack web frameworks (django, rails, etc) are optimized for 6 month happiness, not 6 hour happiness
They take longer to get set up, but as your project grows the incremental work to "change one small thing" stays relatively constant, whereas coded from scratch php or lightweight frameworks tend to have complexity of a change that is exponential with the number of lines of code.
It's a question whether the investment is worth it for what you're trying to do. Sometimes, quite reasonably, the answer is no.
I've got my django routine to the point where it takes me about 30-45 minutes to spin up a new stack that I'd be happy to code on for years -- to me that's a relatively minor investment for huge rewards.
Yes, that's because PHP operates at thermodynamic equilibrium and creating order from those states requires the expenditure of energy.
Rails is great for creating a site with a form where people can upload images, it's a 20 to 30 minute project in rails, pretty much just take any rails blog tutorial and add paperclip. (Note, it's not a 20 minute project for anyone who doesn't already know rails)
Rails is not for non-technical people. Rails is like a great jig, if you're a master craftsman it's going to save you a lot of time, if you're not don't bother, just tweak things until they fit together. If you're someone who has spent the last 5 years building furniture by tweaking things then you will love a jig.
Requiring a professional is a flaw, not a virtue. It's particularly problematic in our industry, where the end-user and most of the people involved in the production are not professional programmers.
> Requiring a professional is a flaw, not a virtue.
Your statement depends entirely on the context. I agree that requiring a professional to assemble my IKEA furniture would be a flaw. Requiring a professional to assemble my custom marble kitchen countertop totally makes sense and I'd hardly slam IKEA for not having such a package in Aisle 12.
Wow this is a really intriguing philosophical difference. I'm a big fan of specialization. I think it is the only way a complex society could possibly function. I'm glad that as an end-user of cars, airplanes, trains, medicine, MRIs, television, movies, wine, beer, liquor, the legal system, government services, etc. etc. etc. I don't need to be an expert in their design, development, and maintenance. It's great that because of its nature, software is more accessible than most things, but that doesn't mean it should all be made by non-professionals. There's plenty of room for both non-professional and professional tools, and neither approach is fundamentally flawed.
There's nothing wrong with professionals building tools for other professionals. PHP surely requires less activation energy for a tiny project or a new developer, but that doesn't mean Rails et al aren't providing useful options for full-timers.
I spent most of my life in PHP, and now spend most of it in Ruby/Rails and mobile development. Believe me, people can make utter messes no matter the language. This is not as strong as an argument as you think it is. I've seen my fair share of terribly coded Rails apps as well as PHP ones.
Funny, but not necessarily true. With PHP, I do as you say and spend, if I know the language, 1 hour max setting up a CRUD list/view/admin.
With Ruby, I have to spend, at least 3 months learning the concepts behind the Rails framework and what the article OP mentions just to get to that 20 to 30 minute mark.
If anything it's all meaningless, and what everyone should understand is that while the closer you are to the web server itself (CGI+PHP, Node.js, Classic ASP), you can quickly create any type of code, at the loss of organization and order.
In frameworks (criticism of Rails can also be attributed to Wordpress IMO) you have a much larger ramp up time learning the concepts and conventions, and once familiar, are able to LEVERAGE those patterns.
But don't bother me with PHP vs Ruby. I run SSI on nginx. It's not even in the same league as those two. BUT it's even easier to spin a basic 5 page website. All tools have their specialties.
I think your first two lines are a bit unfair. In the first line you say it takes you an hour while mentioning in passing already knowing the language.
In the second you say it takes 3 months because you have to learn the framework. Honestly if it takes you 3 months to understand rails well enough to do a CRUD app there is no way you're learning PHP well enough to do the same CRUD app in less time.
The problem is learning PHP actually makes you worse at PHP.
The only possible way to program PHP is to be pretty much ignorant of everything in which case PHP will actually do kinda what you wanted. If you learned PHP then either it's not actually doing what you think it's doing, or some config variable changed and would have done what you thought except it didn't, but don't worry just add some code to change that config variable for a while, and then change it back.
PHP is zen.
There is a story of a young, but earnest PHP student who approached his teacher, and asked the Master, "If I work very hard and diligently, how long will it take for me to learn PHP?"
The Master thought about this, then replied, "Ten years."
The student then said, "But what if I work very, very hard and really apply myself to learn fast. How long then?"
Replied the Master, "Well, twenty years."
"But, if I really, really work at it, how long then?" asked the student.
"Thirty years," replied the Master.
"But, I do not understand," said the disappointed student, "at each time that I say I will work harder, you say it will take me longer. Why do you say that?"
Replied the Master, "When you have one eye on the goal, you only have one eye on the path."
I think the big problem with PHP is the fact that you can find so many tutorials online still not having caught up with current practices, not just in terms of language updates or security, but in terms of software engineering. Not knowing any better and how to distinguish between quality learning material, newcomers will happily put into practice what they've learned on good 'authority' to be correct. Same applies for many books on PHP. There's one particular very prolific and popular author, whose PHP books are always revelled, yet if you read them, he's not actually teaching at a standard a lot higher than what you can find other places. You end up having to spend more time having to re-learn stuff and trying to forget bad approaches...one of the downsides of it being a language with a longer history that Ruby+Rails.
I'm not personally a huge fan of SSI, however, it's simple and understandable, and things do what you think they do.
What I like about it is clean separation, a few command for common things, and if SSI doesn't directly support what you want you just hand it off to another program.
Ruby is my favorite language but I had kept out of Rails for years besides hello-world stuff. The amount of layers upon layers upon layers makes one's head spin. And if something goes wrong, you better hope you are using the exact same toolchain as the audience on StackOverflow is using, because that's what they'll be expecting you to have as well.
I was in the same boat, I had spent years creating PHP websites and then was faced with the Rails framework. When you're first getting used to MVC, it seems very counter intuitive. I ended up using Symfony to get used to MVC while sticking with PHP, and now have switched to Rails and wouldn't dream of going back.
When you're first starting with it, especially moving from creating PHP files, it seems very counter intuitive and over complicated. But once you get used to the layout, you understand why it really is far superior for creating websites.
I know the author emphasizing a point, but the steps that he's described end with two vastly different results:
1 - A php script on a server with a script with some code on it.
vs
2 - A full featured MVC framework, complete with version control, database integration, easy deployment, which is easy for other developer to jump into, etc etc
A lot (a majority?) of websites aren't made by people that need those things. A lot of people just want to get their ideas up on a page so they can show their friends. The thing I walked away with from the article was that PHP is still active in part because it has such a low entry point for those people, where as Rails does not.
Like you said, they're very different entities, but a lot of people can't tell or don't care about the difference.
I don't know about you, but when I decide to do a project, I'll often use a new technology that I'll struggle with, because I want to learn and grow as a developer. Giving up because something is hard is a poor excuse. Period.
You're right, you didn't. But, would you use rails again for your next project? The tone of your comment sounds like you'd like nothing to do with it next time around.
I didn't mean for my comment to come off as snobby, I just hope you don't discard rails/ruby (or branching out from php) because you feel it's not the easiest to work with out of the box (even if only for non-technical people).
No, I'm not out right discrediting it, but given how little I do in web and how small most of my experiments are, I probably won't use it for a long time just because I don't need what it provides.
It's funny too that upload functionality is mentioned here in your base requirements, because that alone is a whole bunch more steps when deploying to a PaaS like Heroku. You don't have a local filesystem, so you have to find and use gems like carrierwave, signup for Amazon S3, create a bucket, configure it in your Rails app, etc. etc.
> ...I assumed a site where you could upload images via a form and then browse and view them was right up its alley
Ah, your assumption was correct but incomplete. Doing that and a bunch more is right up its alley, but if you're doing only that, there are much easier ways.
shameless plug but next time you want to do a web-app/site consider our product (crudzilla.com)...it is basically a web-dev-to-deployment solution in one package.
