PROJECT: Add on to RPGmaker3 has begun!

Kittykicker · **Posted:** January 22nd, 2008, 10:15 pm

I made a name less game sitting at 4.3%. It took me one day to do.

You can download the file, it's on the 3rd save slot.

Perversion · **Posted:** January 23rd, 2008, 1:10 am

Kittykicker wrote:

2. NO VARIABLES.. We will have one lucky person at the end
of the game to work on that.

Meh....count me out, then. I wouldn't begin to know how to make a game without using variables. Or at least, to make an interesting one.

The only way I'd contribute is if it was possible to make a self-contained minigame (using variables) that would not affect anything else anyone has added.

And adding all the variables at the end, IMHO, is counter-intuitive, as it would essentially rework everything that came before, and you already said that you didn't want people altering what someone else did.

Meh....good luck with this, but unless I can make a minigame as mentioned above, count me out.

EDIT to add: See my long, rant-y post in the Add-on Project discussion thread (I could not figure out a way to link directly to that individual post, but you cannot miss it....it's the wall of text) for some more advice and my feelings on the project.

Lantis · **Posted:** January 23rd, 2008, 10:42 am

I'm not familiar with RM3, but don't you use a switch and/or variable to keep people from repeating old scripts?

Like, "you need to go here"

and instead of saying that again say, "are you going yet?"

Kittykicker · **Posted:** January 23rd, 2008, 6:28 pm

Quote:

Rules
(rules are subject to change at anytime as problems occur)

1. You may NOT delete any work that is not yours.
If you feel something must be changed contact the person
before changing there work. You may add text onto someones work but you may not delete the old text or work.

2. NO VARIABLES.. We will have one lucky person at the end
of the game to work on that.

3. You will only be making 5% of the game at one time.. It took me
one full day to make it to 5%. With our busy lives, I don't want everyone
to be waiting up for slow pokes.

4. You will be given 1 week to come up with your 5%. It only takes 1 day to do. You take too long your turn is forfeit!
If you can get your game in right away we can set the next person up to add onto your game ASAP.

5. If you wish to add more at a later date you can as long as everyone who wanted to partake in the project has gotten there turn.

6. 5 sprites/characters per 5% turns! If someone did not use up all there people then you may use what they have not on there turn.
RPGmaker3 only lets you use up to 100 people.

7. You may add to the story teller and cover story of the game before it starts. [/color]

This is all I can think of so far.
If you agree to these terms you may upload at any time.

First comes first serves. Place your request here to add onto my game.

Ok, these where rules I had going on "goats" idea that variables would be too sloppy to follow. So I took it on my self to try to get rid of that problem. But I guess people still have other opinions that need talking about before moving forward.

Like a field of corn... I'm all ears.

Lausen · **Posted:** January 23rd, 2008, 7:24 pm

I was thinking we could asign shared variables. Someone would get 1-3 the next person would get 4-6 and so on.

Also I say anything you make/add to the game that has internal variables is all yours. No one could take it. I think this would solve the problem for the most part.

Perversion · **Posted:** January 23rd, 2008, 7:48 pm

:facepalm

I did not say variables would be too sloppy to work with, and that we should completely eliminate them. My suggestion was, no matter what your contribution was (including characters, storyline, quests, events, variables, any technical details), you would need to make a list of what you added to make it easier on the next person in line. Sure, you only spent 4 hours making your portion, but that's because you're the first person in line. Imagine being the 4th person down the line, getting the file, and having to spend that 4 hours looking through the edit screen, sending PMs or IM to the people who worked on it before you in order to figure out what is even going on.

So my advice stands:Limit everyone to 5-10% or whatever, that's fine. Impose a five character limit or whatever, that's fine. Impose a time limit, and require people to post their place in line so two people are not working on the same file at the same time, that's fine. These are all good guidelines. But please do not stifle the contributors' creativity in tems of how they want to use the coding. And each contributor MUST attach a word or text file to their contribution (in a folder with the game file) when they upload it for the next person. This text file must contain some basic information on what your overall contributions are (who each character is, what you added to the plotline, etc), and very detailed information concening any coding you did that might need to be utilized or expanded on further down the road. If all your coding is involved in making a side quest that will have no bearing on anything else people might add, that would be okay, but people still need to know this for the future. But if you decide to incorporate some system of collecting X amount of items (for an example), and are tracking these items by variables, the next person needs to know that if they make a side quest where you find one of these items, they would need to know that Shared Variable 1=amount of raccoon feces the party has collected (for an example).

Also, are there going to be random battles? Are there going to be ANY battles? If so, there's going to need to be some way of balancing the battles (it's hard enough for one person to balance by himself-it goes back to the Kittykicker "trial and error" method-but imagine having everyone try to create new dungeons or new world maps, and trying to balance the battles without completely revamping any sort of levelling-up and stat-increasing system that is currently being incorporated into the game...it would be hellacious).

See, THESE are the things that need to be addressed BEFORE undertaking the project instead of coming across these problems midway through the process, and then saying, "Well, what do I (we) do NOW?" Obviously, we do not want this game to be incredibly complex, but if we do not even figure out what we are doing about battles before the thing is started, there will be some problems down the road, and I think the goal here is for everyone to have fun with it, and not get the file, and realize that they have been painted into a corner.

Like I said, we do not need anything complex. But some simple guidelines and a bit of preplanning (trying to anticipate any eventualities that may arise, and addressing them before the thing is actually started) will go a long way toward improving everyone's experience with the thing. And if everyone is enjoying the process, instead of getting frustrated at every turn, more than likely the game will turn out better. And as Dray asked, you DO want this to be a success, right? Read your PM if you've not already done so, where I sound like a motivational speaker concerning success and failure.

That's my input....take it or leave it.

TheAsianInvasion · **Posted:** January 24th, 2008, 12:36 am

Perversion, you bring a lot of valid points to the table, and I applaud your persistence in this matter. After reading through these two threads and being a third party impartial representative, I propose that the following method be used in the implementation of this project.

Sorry Kitty, but The Bolt On method just doesn't work in this case. This has been proven before by others in what we commonly know as the Open Source Community.

Open Source Best Practices wrote:

Best Practice #1: Learn how to Extend The Software
If you have to "hack core" (change core files) to get it to do what you want, you're probably doing something wrong.

This advice holds true for most other open source projects; always perform investigation into the tools and techniques the software makes available for customization. These may include a "skinning" or "themeing" system to customize the look and feel, the ability to extend functionality through modules, extensions, and add-ons, or configuration options that can be altered to fit your needs.

Your first goal when working with open source software should be to try and "get in the heads" of the developers of the software, and determine how they intend for the project to be extended. While it can appear easier on the surface to just bolt on a chunk of functionality you're missing, doing so means inadvertently undoing all the collective work and thinking the community around your project has poured into the problems you're facing. Learn what tools and techniques are available to you, and you'll have a much easier time building your project.

If you create a general outline for the story, everyone will have the general picture of where you want to go with it. Consider it like writing a term paper with an Introduction, the main body, and of course the big finish. Everyone who participates is part of the drawing board team. Talk amongst yourselves on this, and come up with awesome ideas. Just because you don't know how to write variables into the game doesn't mean that you should omit them. Pass the variable onto someone who knows what they are doing. DOCUMENT EVERYTHING! It will make it easier in the end to troubleshoot if something does end up going horribly wrong.

Open Source Best Practices wrote:

Best Practice #2: Do. Not. Fork.
The second you change any of the default core files of an open source project in any way, even for something as small as changing the text here or there, you have created a "fork." This hurts you in a number of different ways:

Difficulty in getting support. Your changes may cause subtle bugs to appear, and you're going to have a very hard time finding other people to help you track them down, if they can't reproduce the problems themselves.
Difficulty in upgrading. Each change you make, no matter how minor, needs to be carried over each time you upgrade the site's code base. If you forget a change, your site behaves differently. If a security patch changes a line where you've made a customization, you then have to hunker down and do a bunch of analysis and testing as you attempt to merge the changes and ensure that you're still getting the proper fix.
Maintenance headaches. Because this is your code that you've written, you're on the hook for maintaining it, testing it, and improving it. More on this and why it's a bad thing in a bit.
Resist the urge to fork, and instead...

Forking isn't necessarily a bad thing within this small group, but the key is communication and documentation. If you dont tell someone you changed something then the project team is lost.

Open Source Best Practices wrote:

Best Practice #3: Participate within the community
There are many advantages to using open source software, but probably the biggest advantage is the virtually limitless resources involved in the open source ecosystem. Millions of people around the world are testing the software, fixing problems, and adding new features. It's simply impossible to reproduce this kind of momentum with a small team (or even a very large team).

Let's imagine a scenario where you find a bug in your open source project of choice. Your natural inclination might be to just troubleshoot and fix the bug in your local copy, and then move on with your day. After all, we're all busy people, and client deadlines aren't getting any shorter.

An alternate, and more effective, approach is to do the following:

Search for the bug. When you very first encounter a bug, before you even attempt to fix it, your first instinct should always be to search for the bug in the issue queue or bug tracking software used by the project. It's possible someone has already found the bug, and reported a fix for it. If so, you just saved yourself some work.
Report the bug. If the bug isn't there, the second thing you should do, again before you even attempt to fix it, is submit a detailed bug report. Often, developers are very active on issue queues, and they are also more familiar with their code base, so they can often find and get to the root of a bug before you can.
Submit your fix. Assuming someone in the community didn't get a fix out to you before you figured it out, always submit your fix back. Not only is this good "karma," as you've just saved the next person from having to do this (and karma in an open source community is your very best asset), but often you can get good feedback from other developers as to whether or not your fix is the best solution, and either way, you help ensure the fix gets put into the "official" product, which means you no longer have to maintain it.
Let's use another example. A client needs some crazy new feature for a site you're building.

Search for an existing module. Even if there's not a "100% fit," a 90% fit (or even 50% fit) is a better starting place than nothing.
Submit a feature request. If there's a module that will work as a starting point, just as with bug reports, before you start coding anything submit your intent to work on the additional functionality. You may get other people interested who will offer co-development, testing, or even just some cold, hard cash toward its development. Or, the module author might chime in with how they already tried it, how it didn't work, and how to use X instead.
Contribute new code (a new module for example) to the community. If there's not already something out there that fits your needs and you need to build it, submit it to the community in whatever they're using as a "forge" system (CVS, Subversion, etc.) If possible, the best thing to do is place your code there as early during the development as possible. This allows others to try out your changes and provide testing, bug reports, and usability feedback long before it reaches your client's site. Procrastination can create more custom code for you to maintain: lots of people have really good intentions of committing stuff back when all's said and done, but often it's easy to get side-tracked.
Work out of the issue queue. When you add a new feature to your module, make a feature request for it, attach a patch, and commit it. When you fix a bug, make a bug report for it, attach a patch, and commit it. The discipline you show here will help pay off ten-fold by getting more eyes on the code, and by making changes small and easy to isolate should something go wrong.
By pushing fixes and features back "upstream," you help ensure that future sites you build will have the functionality you're looking for, rather than having to constantly re-invent the wheel. You also turn into a collaborator on the project, rather than a user.

Use your team. Volunteers from the Mag who want to be part of this all have different talents. THEY are your resources. Trial and Error at one point was your learning curve, but now you all have seasoned ideas and methods to put the ball into play. ASK before doing, and if you fail while trying, ASK anyway. Afterall, isn't this kinda why this site was created in the first place? As a collaborative meeting place for RPGM gamers?

Open Source Best Practices wrote:

Advantages of following best practices
Working in this manner has the following advantages:

It helps save you time. You might find answers before you even begin your quest. Another developer can come along and code something before you even have the chance to do so.
It earns you karma. In addition to the "warm fuzzy feeling" that contributing gives you which is a reward in its own right, open source communities tend to be "meritocracies." Opinions of individuals are generally weighted by the community, either consciously or subconsciously, by the level of contribution they've given to a project. Gaining a reputation as a contributor often means your questions get answered sooner, and it also means more business for you as new clients see you being committed to the platform, and other contributors in the community refer additional work to you.
It increases the quality of your code. More eyes mean more testing, more feedback on the approaches you've taken to problem solving, and in the end more flexible, usable, and easy-to-understand code and functionality.
It lets the community help maintain your stuff. Putting stuff out in the community means you increase your chances of someone other than just you using your code. And that's a very good thing! These other people will contribute their own bug fixes and features to your module, and help test it for bugs. They can also help with upgrades between major versions. With custom code, you are the only person who is able to do this.
Disadvantages of following best practices
There are not really any, other than it takes a bit more time to do up front. You can help offset that by building that time into your contracts, and by client education. Explain to your clients about how open source is different, and that in order to get the very best "bang for their buck," it's important to leverage the community development model. This will help ensure that they enjoy all of the benefits of open source, including not being "locked in" to a proprietary fork, having the highest-quality code, and being "future proof" for upgrades.

As you can see there is logic to the madness of planning before reacting. There is a reason why UNIX is inherently more stable than any Microsoft platform out there... and UNIX "IS" Open Source. Good luck in your planning, and I hope all goes well.

Perversion · **Posted:** January 24th, 2008, 2:28 am

Well, I'm not sure how impartial you are, considering you're married to her...

But, yeah...great input. And the reason I'm being so persistent in this matter (as you put it) is because I think KK came up with a very interesting idea that I think could turn out pretty damn well with the right backbone and focus behind it. I thought I would lend the experience I have in creating RPGM3 games to this endeavour in order to make it something really fun and creative for the Mag community, without it falling into utter chaos right after it's begun.

I'll be honest, even though I'm a member of the Mag, and I'm trying to keep up with my job as an editor, that's about as far as my Mag community involvement really goes (I post at the Pav A LOT more than here). I was hoping that if I was to partake in a project like this, it would integrate me more into the Mag's own unique community. I mean, it feels like, even though I'm a contributor to the actual issues of the magazine, I'm apart FROM the community rather than a part OF the community. And when I saw the original thread about this idea (which is quite by happenstance, as I rarely ever spend time browsing the forums), I decided that I'd like to get involved.

I'm sorry I turned this into some big drama (as KK calls it); that was not my intention. I'll stand by what I've said before, and that is, I think KK comes up with some good ideas, but might have some trouble following through on everything that might be involved. She just needs to get rid of the, "I've failed my whole life, so if I fail again, it won't really matter, and at least I tried" attitude, and try to segue that into a, "I know I can succeed at this, but I need to be willing to ask for some help along the way, and not feel like a failure if I cannot do everything myself," attitude.

Not that I know her that well, but that's just what comes across to me. If I didn't ask for help, I wouldn't be where I am, both in game creation and in life. To quote an old Yes song from the 80s, "You've got to WANT to succeed."

Now I'll stop pretending to be a motivational speaker/psychoanalyst, and allow things to proceed as they will.

Oh, and thanks, Mr. Invasion Guy.

And KK, if I didn't think you had some potential, I would CERTAINLY not be wasting all this time on you.

Kittykicker · **Posted:** January 24th, 2008, 4:05 am

Thank you Perversion. I feel honored that your time is wasted on me. :XD

Now, not to waste anyone else time.. I'm going to tell you what I know...

Ready?

I know nothing.. Hows that.

I own all 3 rpgmakers. RPGmaker3 is the easiest for me to use. And I'm not really that interested in story, or variables, battles or good endings. However I do like to play games that have all those things.

What I do enjoy doing is landscaping, map building, and making hidden paths. I find it hard for me to pretend to be other people. I'm like that with any RP game.

I know RPGmaker may have not been the right choice of games for me to pick. But it was a cold lonely February a year ago and I needed something to do as I waited for FF12 and Zelda TP to come out. I'm just being honest.

I was talking to Lantis earlier and I said. "I'm more of a follower then a leader. I'm flying by the seat of my pants
just to see something new" I'm kinda almost sorry I made this thread. I really don't want the responsibility. But something needed to be done for any kinda new fun to happen so I threw it out there.

Kinda like how I asked Jamos to be my helper in the RP forum. I had this big forum to my self and no one to help
run it. I don't like feeling alone on a big project. It's kinda over whelming.

So yeah.. landscaping.. I should have stuck with Sim city or something. I beat the one for the Apple computer using just the RR tracks. But anyways..

I don't think I can be much help.

Perversion · **Posted:** January 24th, 2008, 4:45 am

I didn't MEAN I was wasting time posting all of this...I meant, if I had not thought it was worthwhile to be posting on this subject, I would not have wasted my time doing it....meaning, I'm NOT wasting my time...I guess that didn't come out right, did it?

Kittykicker · **Posted:** January 24th, 2008, 1:06 pm

So.. I can do my part. What I know, that I can do. I know that much.

But everyone else who knows what they can do can do just that.

I really don't know enough about the problem at hand. I don't know much about variables at all. Or switches. I kinda find it a pain. So I kinda avoid it.

So for me to make rules regarding how we should plan to use variables threw out the game.. I'm really the wrong person to talk to. I tried using them and I found it frustrating when I found a bug then I had to undo and back track all my work.
At least with other stuff like making maps and placing people.. If I don't like something I can always delete. But to delete a variable I will braking a whole chain of events. And that can screw everything up. I don't wanna worry about that.
But that does not mean others can't do it.

I sent a PM to Bo. And the way I said it was... Its like being a contractor. Some people can build a house from the bottom up. Others can just do plumbing or be a roofer. As far as rpgmaker. I'm just good with making pretty land forms. And I still see other peoples work that I want to study. I know theres tricks on making really nice mountain slopes.

Bo:

Quote:

there are so many things one can do without variables, modes, etc.

Everyone can make fields, towns, dungeons, classes, abilites, characters, weapons, armor, accesories, items, monsters, monsters units and even unassigned storytellers without once writing any code, using any variables, or adding any modes.

All of that could be done later (like a second round).

Even then, if someone created events and non-playable character mode contents, all someone really has to do is indicate what events and characters and we can "look it up" to see if we want to build to it, so long as it was not too complex.

What I said before was making a Gothic Cathedral in that it will still "work" (i.e. be playable eventually after testing) but it might not make sense as an overall game. To me that would be fun.

I myself would love to work together on a this type of game, but that is DIFFERENT from what you suggested. That would require extensive planning and task assignment from the start. That is a different project than simply building on each others work.

If it is for RPGM3 I'm in either way (at least to some extent).

Like Bo, theres still others that really just want to charge in and start working on this. But...

like you said.. theres a lot to talk about first.

1ce · **Posted:** January 24th, 2008, 4:18 pm

Indeed, much left to talk about. Seems most people like building landscapes with rpgm3 and don't care about the rest of the project, like stories or character development.

And honestly, I'm terrible with rpgm3. But I'd still be willing to give the game a shot.

And TAI gives some important insight about how the community should work together to tackle this project. Using KK's example, we hve the blueprints and the foundation to being working on it.

TheAsianInvasion · **Posted:** January 24th, 2008, 10:39 pm

Perversion wrote:

Well, I'm not sure how impartial you are, considering you're married to her...

Doubt me if you will, but know my intentions are still in the best interest of the community. When I see people start to go off the deep end on someone and I think it was unwarranted, I'll say something... I find that sometimes I'm more of a mediator. I'm not a frequent contributor on the forums, but when I do post, I like to make it count for the better. So yeah, I may not be 100% impartial, but I understand KK does spend a lot of time here, and I too would like to see a project idea like this bloom. Even if it means counseling my wife on what was actually said, I will still act in the best interest of the community, because when the community is happy, she is usually happy too.

Now that we are all now generally on the same page, we can create a general outline. Like any good movie, you have the opening scene, the main plot, the excitement and drive followed by a spectacular ending. If we can each brainstorm about the type of story, I know KK suggested comedy, and thats fine and all, but it does need to be agreed upon by all if it's going to work as a group effort. Anyone want to fathom a story board?

ErikaFuzzbottom · **Posted:** January 27th, 2008, 2:50 pm

I was under the impression that there wasn't any story planning planned, and everyone just waits and sees where each person takes the quest.

Kittykicker · **Posted:** January 28th, 2008, 1:18 pm

^I was kinda thinking that too.

Perversion · **Posted:** January 28th, 2008, 4:44 pm

That was also my impression....I was kinda thinking this would not involve a lot of plot/character/etc pre-work....the add-on thing COULD work, and might be interesting....my only suggestion was for some guidelines/preplanning in terms of technical stuff that might trip the project up.

TheAsianInvasion · **Posted:** January 29th, 2008, 1:52 pm

Well perhaps I was mistaken as far as posted suggestions. We do live together, and the topic of a potential comedy was spoken of. Either way, what guidelines can we think up that may stop problems before they happen?

Kittykicker · **Posted:** March 27th, 2008, 3:46 pm

BUMP!

Instead of rules for now... How about we just work on a case by case basis..

Download the above game. Let us all know what your plans are. You don't have to go into detail about your story or where you plan on really putting anything. But if you plan on using switches or many of the 100 limit people please tell us what your using before doing it.

Lausen · **Posted:** March 27th, 2008, 4:28 pm

Well I'm going to start working on my five percent right now, if you don't mind? I plan on working on the inside of the town.

Edit: I have an idea as for a story. I want to discuss it first though. Seeing as the characters you have in there, I was think of a Pav V Mag war. Two massive empires going at it. It might be fun, seeing how I know it will end up being a comedy.

Kittykicker · **Posted:** March 27th, 2008, 4:48 pm

Yes that's fine.

Ok So your going to be the next person to work on it.
Let us know when your done.
I will look at it and will send someone else to work on it.

	It is currently November 23rd, 2024, 2:43 pm
View unanswered posts \| View active topics

PROJECT: Add on to RPGmaker3 has begun!

Who is online