Thursday, March 14, 2019

Why I started a patreon account

When I first considered making a patreon account is when someone on reddit mentioned that I should do it.  I already knew several other creators who had made one.  A lot of them in the free/software culture space didn't' seem to get much money from it, so I figured it would be a waste of my time.  Then I changed my mind. I read all kinds of things, like wait till you have a big following to make one, or do it as a last ditch effort. 

I read this horrid page where some guy sounds like he is begging for money, yet he still got over 1,000 a month, that is less than minimum wage, but still, he got the money because he is semi-famous.  I realized more and more it has nothing to do with cool rewards you get from subscribing or the merit of the work being created, but rather, how popular the creator is, that is how many people know about his or her work, that more or less determines it.

Free software has a marketing problem.  We make so many cool things, but people would rather pay micropayments for mobile games, waste money on a fancy graphics rig and play games that are boring (with terrible game play) or buy indie games on steam, only to deal with the fact that none of these options have the modifiability or customization options of free software games.

Why do we do it?  Traditional proprietary software offers easy monitization options for the developer, including micropayments, pay once and we are done (as long as you still have the account/drm key/ disk), or pay a subscription fee for monthly online access(mostly replaced with micropayments for cosmetic items or even to get through the game faster).  The developers take these options, but if they fail to market the game properly, they still make little to no money at making the game.

But here is the thing, making a game free software with free cultural assets does not really change the monitization options all that much.  You might think, OMG! its so revolutionary, but it is even less revolutionary than the old Red Hat business model. You can still sell virtual items on a server and charge for "premium accounts." Yeah, the source code and art work is free, but server admins time and hardware is not. As far as single player offline games go, there is always the pay up front before the game is finished model.  That is people pay before it is even done. Once a game is done, you don't need to pay over and over every time you make a copy of the disk or put it on a different computer.  Its not like the developer is actually doing any additional work because you made another copy of some game, you did the work, not the original developer.  Same thing if you decide to modify the game.  It just makes sense for people to be paid for actual work done, rather than the printing of fake money.

So in conclusion, I think that we should pay live people for work they actually do, rather than dead people who arn't doing anything anymore, and despite what they ancient greeks thought, we don't put coins in dead people's eyes anymore.

Tuesday, February 19, 2019

Why PVP based Multi-Player Online Roleplaying games should be open source

This is a post based on a reply I made on Reddit.  When I read the initial post, I realized how my game is using the power of open source to solve some inherent issues with PVP based Multi-player Online Role Playing Games.

The first issue mentioned was performance.  While open source itself does not help directly with this, the Wograld policy of keeping system requirements low helps a lot with this issue.  Who cares if the graphics are beautiful if you can barely play due to the frame rate.  Forget about pvp then, because performance will be so abysmal for many people that you will hardly be able to pvm.

The next two issues are things that are directly resolved through the useage of open source for both the client and server of the game.  Bugs were explictly mentioned.  A lot of games (I'm looking at you Runescape.) have ongoing bugs that are never fixxed even though the developers probably know about them. With open source, the playerbase can directly fix bugs and actually commit a fix in order that the bug just goes away.  Eric Raymond is famous for his quote "With enough eyeballs, all bugs are shallow." Well, now by having all the code, both client and server open source, it will be shallow enough that finnally the bugs can get fixxed.

The second issue deals with game balance.  Ideally, the developers will understand game balance and how communities work.  They should understand the underlying dynamics, and while they should listen to the players, they shouldn't necessarily give them what they ask for, instead they should make a game that creates a healthy and thriving community, and not one where all the players quit over time because game balance is too broken. Sometimes, the developers fall into blind spots and never actually understand how communities work.  If that happens, the original game code still exists and the community itself can fork, and players can play a balanced non-broken game instead of a broken one.

The last issue mentioned deals with cheating. Some people think closed source software somehow prevents or lowers cheating, but looking at all the closed source proprietary games with cheating problems proves that closing up the source code does not prevent cheating.  Instead, some games though they could prevent cheating and still have certain calculations running on the client side.  Cheating can be prevented by running things on the server side.

Friday, December 7, 2018

Twelve Years of Wograld Development, a Look Back on My Biggest Mistakes

When I started Wograld, I had no idea how much it would effect me and completely warp my life. I honestly wish I had had a different time coming into my early twenties, but unfortunately, twelve years later, I cannot imagine things any differently. I do suggest if you have a passion for something more worthwhile than game development, do that instead, don't waste your life. Unfortunately, I do know people who won't listen to me, and who will do game development as a hobby or even as a career regardless of what I say, so this rest of this post is for those people, or people thinking about becoming one of those people.

1. Not learning to code sooner and not putting more time into coding. Coders get a lot more respect and have a lot more say in the direction of a project rather than writers, artists or musicians, so learn some applied logic people, sure, it might suck, and segmentation fault might suck, but do it anyway, do whatever you have to to learn it. I mean whatever, and then keep practicing.

2. Believing that marketing is just traditionally pretty boothe babes in high heels and has absolutely nothing to do with your open source project.

 

If no one ever hears about your project, no one will ever test or play it. You can't rely on the open source community to care about your game, you have to reach outside that traditional demographic because almost everyone in the open source community falls into one of the following demographics

1. believes games are a waste of time and wishes they would go away or

 2. already has their own game project they are working on. 

 

I wish I would have taken that life coaching class earlier. Sure, it might have seemed like an utter waste of money to some people, but it was where I finally got introduced to the concept of marketing, and I started to actually think about it in a different way, rather than as some kind of evil to be avoided at all costs.


3. Not worrying about burnout, at the same time not realizing that I can't give up even when I sort of want to give up.

 

There are a lot of abandoned partly finished projects for a reason. People get busy with life (hopefully, the other possibility is to awful to think about but unfortunately has probably happened to some developers) I didn't have a way to sustain my focus and attention. I distracted myself with playing really bad repetitive games, like diablo2 until my windows 98 machine died, because I was just too miserable to do anything else. Don't do that people. You do have to play games so you know how to make them, but once you understand the basic game mechanics and have had fun, there is no reason to play them over and over again while they make you feel sick. Its like eating a bunch of icecream because once upon a time you enjoyed it but now you are puking up your guts.


4. Not having the humility to work on other peoples' projects.

This is a really really hard one for me to admit. I started my own project with this big ego, thinking like I would be the next Linus Torvalds of game development or something. It seems funny now, or maybe just a bit insane, well okay, a lot insane except for the lack of a word salad. Instead, I should have worked on other open source projects, sure that horrible open source roguelike that kills newbies when they so much as look at it isn't going to be my favorite, or that real time strategy game with ugly graphics, but if I had worked on projects even though I didn't enjoy playing them very much, i would have gained valuable development experience whether it was in code, artwork or something else. I suggest you do so too even if you have your own pet project that is going to be really awesome and not tedious like open source game x, that you have decided to work on for a bit instead. Alpha testers are always wanted. Please download from the latest git, compile and run it, and not from he releases that are probably already out of date (unless for some reason the project has things that don't compile in master, but I don't think most well run projects do.

The project should have from 1-20 active developers, and by active, that means commits to the repository within the last month. On the low end, you might not get a response for your help, on the high end they might have more newbies wanting to help with the project than they can possibly use.



Wednesday, November 21, 2018

Wograld Alpha 0.1.0 newbie tower





I want people to know that, yes, I did release a video on the awesomeness of my
game development.  These days it seems everyone wants videos, so alright, here is video.  Go clone the git right now , read the README, compile, run and start playing!!!  Alpha testers, there is still time to get involved and shape the future of
this game.

Friday, October 12, 2018

Gitting up to date

Wow, I know it has been quite some time since I updated this blog.  Believe it or not, I actually am continuing to work (well, a bit on and off) on the project. As of this year, we made the long in coming move of moving to git.  Sourceforge ended CVS support back in November, and that is what prompted our decision (well, actually my decision to change.  At first I wasn't sure, should I import all the 10+ years of project history with all the *** in it or, just start over fresh with the latest stuff.  I decided to leave all the old *** out, because its just not really useful to new developers anymore.  This project has come a long way since the half-baked fork of crossfire days.  So much artwork has been replaced.  I redid some folders to make it more newbie friendly (no more separate arch folder for the server, and the new music files, are naturally included with the client.)  I realize I don't have to stick to the old and poorly thought out conventions from the old game. 
So once I switched to git, we have been making regular commits, and git isn't really that hard to learn.  Its actually easier than CVS.  I don't bother with all those separate testing directories.  I just test it right in my sandbox.  It makes it so much easier. I just simply don't include changed files that don't need to be included, and check with git status to make sure I included all the right files and none of the wrong ones before I commit. 
We have done a lot. A lot of artwork, a lot of music, a lot of code, but there is still much more to do.

Tuesday, December 16, 2014

Bank Boxes and Bugs

Last weekend, my lead programmer finished implementing bank boxes. I kept saying how most RPG's have bank boxes.  For those who do not know about what that means, let me explain.  Characters in computer role playing games often have an inventory where they carry stuff they might need in the course of the game.  That can end up being a lot of items with no real way to organize them.  In addition, in some games, items can be lost upon death or stolen.  Characters may also have a weight or item limit for what they can carry around.  Bank boxes allow characters to put items in them for later usage.  In between adventures, the character can visit the bank box to deposit or take out items.  This bank box can be only accessed in certain usually safe locations, such as towns.  The rest of the time thesse tiesm are not accessable.
Most multi-player online roleplaying games of any size have this feature, so I knew that wograld should have it as well.

I tested the bank boxes and I have not found any bugs with the feature so far.  Unfortunately, I found another serious bug that will have to be fixed before we can even consider a permanent multi-player server.  That is, if you disconnect the client a certain common way, the server will crash.  I have told him to fix that. 

Friday, June 13, 2014

Back to development

I finally had a chance to get back to wograld development.  I was actually ready a couple months agotoget back to work on the project a couple months ago, but I wanted to redo my computer with a new set of distributions on it, so I did that in April.  I got that done, and then I had an awful month in May. My cat got very sick and died, and I also had my car totaled.

June is started out well, I got a chance to test some code, add and remove things from the bug tracker, and commit more artwork.  I can't believe I forgot about the bug tracker for years. I think if I had used it more from the beginning, I would not have to keep track of so many things in the development, particularly in cases where I put the project down for a bit and picked it back up again.
I've been daydreaming about writing a book on free software project development, but then I realize half the information I think should be included in the book, I don't actually know, I could ask someone else, but I'm not sure they would know the answer either.  Also I don't want it to get into too much of an argument, such as what distro is better, what desktop GUI is better or what programming language is better etc.  I know people get very opinionated on these things, I know I do.  I don't want the book to be come across as too biased even though I have strong opinions on those topics too, I know not everyone shares my opinions.

I guess you could ask questions like  Should your project use a bug tracker? Should your project use version control? I guess you can get away with not using them if its a very small project, but I've found anything more than 4-5 files it would probably be better to use version control anyway.  With the bug tracker its nice to keep track of things even if no one else ever reads it, because then you know what you fixed and what you did not fix yet.