Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/caarrie/public_html/glompzilla.com/Sources/Load.php(225) : runtime-created function on line 3
Common Pitfalls in Project development.
*
Pages: [1]
  Print  
Author Topic: Common Pitfalls in Project development.  (Read 6186 times)
0 Members and 1 Guest are viewing this topic.
Bamko
Administrator
Member
*****
Posts: 19


« on: March 03, 2011, 02:23:51 AM »

I want to ask some project leads from other projects to comment here about why their projects have stalled.  So far most none seem willing.  IMO either do not want to face it or are so busy working behind the scenes (no recent activity according to cite news, forum or wiki though...) that they do not have time for researchers like me.

It seems to me a common thread running through Indie Projects is that they grab an engine that someone knows a little about, and begin with a lot of energy.  Every problem with the engine is seen either as a feature, or an opportunity to recruit or develop coders that can work around it.  Great progress is made.  Then a settings culture is developed before they have a playable framework.  Settings is specific, as such it can suck up an infinite amount of time while fragmenting any team.  After a while even the biggest advocates seem to get bored with it.  I believe this is much like any fad, no matter how awesome you think Harry Potter, LOTR, Or Star Wars is, MOST people will not put in all of their free time for more than a few years learning it.  The human mind just looks for something different, anything different. But alas, they have put so much work into the project, to abandon the settings would be blasphemy!  Yet they find it harder to work on it, Real Life (RL) seems to become more alluring.

Couple that with the team realizing that the engine they have become married to, with the work they have added to it, also should probably be scrapped and started over, or their code has become so complex with so many hands working on it, and their libraries are full of unfinished models that no one wants to finish...

So the team finds it harder to stay motivated.

I think the answer is that most of these teams should be working together, explore the CURRENT options that are out there, build skills developing those options or libraries, and develop the settings as a separate project. I would just wait until you have a game system that you can use for it, THEN put it in game when it is fresh and new enough to still be exciting.

I tried to get people to see this was what has always happened with MOST Indie projects.  But alas, they thought they were smart enough to do it alone.  Trouble is it has nothing to do with intelligence.  

We do not have to work together at The Glomp, but we SHOULD work together on finding good starting points and developing usable frameworks, somewhere.  Then we can develop our worlds and make our games.  

Tell me what you think, why I am wrong, whatever.   Please include enough info about your experience and opinion about indie projects in general and projects you have been involved with in particular.
« Last Edit: March 03, 2011, 02:54:46 AM by Bamko » Logged
Jastiv
Guest
« Reply #1 on: March 13, 2011, 08:12:35 PM »

I saw this post as soon as I checked out this site and knew I had to respond.
First of all, I did not originally intend to make myself lead developer of a project.  It just happened that no one was working on anything like what I was doing. Yes, I know there are other rpgs, most noteably the project I forked from, but none of them had the same or even close enough design goals.
Basically it comes down to this, I loved Ultima Online, but felt it had a lot of features/problems that needed fixing.  In addition, it is of course, non-free software, so it has all the inherent problems that come with that.
I seriously doubt real life is ever going to seem more alluring than the game. (basically I hate the game mechanics irl, but all I can do about it is exploit the bugs and complain about the devs)

Honestly, I don't really know why other projects die out or fail to get off the ground, all I know is what I personally experienced.  If you want a detailed blog about why more was not done about the wograld project, why we have not made a release yet, (or why there were not as many commits as one would hope) you can go here.
http://wogralddev.blogspot.com/
Logged
Bamko
Administrator
Member
*****
Posts: 19


« Reply #2 on: March 14, 2011, 06:19:23 AM »

Well, I looked at your blog a bit.  First post in 2007. 
Ultimately, the real thing holding back the games, is the bad documentation. It isn't finding programmers of C or any other popular language, it isn't finding artists, no matter what programmers would have you believe, art is so easy anyone can do it except for some programmers. It isn't the sounds or music, because the game would play just fine without that and you could add it later.
In the end, it is the whole herding cats problem, getting the programmers and artists to use the version control system, for example, or setting up the website or just simply communication that holds projects back.


And this post has some interesting looks behind the curtain, but I find it better when authors speak for themselves rather than quoting their old comments.   Point of this thread is to give people a place to talk about pitfalls in projects they were involved in. 

I would be interested in understanding what you mean by "Bad documentation" but I like to live by a rule that you should make enough comments, notes, or whatever, that if you were hit by a bus tomorrow, the work you did today could be picked up easily by someone in the near future, without requiring a reincarnation on your part.

On a side note: 
Quote from: Ibid 2008
I thought, oh, free software project, what more do you need to know besides how to program in the language the project is written in right? Wrong. I did not know all the stuff I would have to learn, and as embarrassing as it is now to admit it, I didn't even know THAT MUCH, when I began the project

THAT is exactly the intent of Glompzilla, or "The Glomp"; to look at projects and define them honestly from the point of view of what is needed to actually use them.  It is difficult to do, but I find that other sites have lots of marketing information, but after I DL all the files and spend 20-100 hours looking at a project, I find that it is not quite where they promised to be.   If we can pool our resources, we MAY find the project that meets our requirements, to join or to splinter into what we want to do with it.  Worst case, we find that no one TRULY is working on what we want, and we can form teams and get on it. 

Welcome to the Glomp, hope to see you poking around.  Let me know if you still agree with those quotes, They are a few years old, but since you pointed me there, I went there :p



Logged
Jastiv
Guest
« Reply #3 on: March 14, 2011, 12:57:41 PM »

Documentation in the below refers to the sourceforge documentation.  Since I posted that, they have improved it quite a bit.  I was able to figure it out after the improvements.

Quote from: http://wogralddev.blogspot.com/
Quote
Ultimately, the real thing holding back the games, is the bad documentation. It isn't finding programmers of C or any other popular language, it isn't finding artists, no matter what programmers would have you believe, art is so easy anyone can do it except for some programmers. It isn't the sounds or music, because the game would play just fine without that and you could add it later.
In the end, it is the whole herding cats problem, getting the programmers and artists to use the version control system, for example, or setting up the website or just simply communication that holds projects back.


In reference to the flustrated with my project team post, well, I guess they were slacking off and just needed some more modivation. I did not actually fire anyone on the team.  So they are still there, and still active on the project.

As far as the knowing what you need to know, other developers have commented on that as being a problem as well. I think making a list of stuff would help first timers get up to speed faster. In fact, I have a quick list. Feel free to add to it.
1. How to set up a website
2. The project version control, how to use it.
3. shell scripting
4. the build system (in my case, autotools)
5. the debugger (in my case gdb)
6. the main language the project is writen in.
7. the dependancy hunt library functions that are used on the project.  most projects use something besides standard c (else all you are doing is making a text based game probably) x11 seems like it is the least problematic since it is unlikely to change much since so much is built on top of it. SDL seemed stable, but they messed that up fairly recently.  Most of thesse should probably be included in the code base rather than installed seperately through the package mangler.

8. any scripting languages that are used for the program (optional, not all programs have this) it could be something like perl or python or both (or please not LUA, I hate LUA with a passion)

9. art work creation skills (or if you are lazy you could resize bad graphics from elsewhere, but it will look awful)
10. music and sound effect creation skills (optional)
Logged
Pages: [1]
  Print  
 
Jump to:  

Recent

Stats

Members
Stats
  • Total Posts: 134
  • Total Topics: 96
  • Online Today: 3
  • Online Ever: 305
  • (November 15, 2018, 12:00:32 PM)
Users Online
Users: 0
Guests: 1
Total: 1

User

Welcome, Guest. Please login or register.
July 24, 2019, 02:27:46 AM

Login with username, password and session length

ShoutBox!

Permissions

TinyPortal © 2005-2012