View Full Version : BR pbems 3.5 edition - automatic site building
darkon
11-18-2005, 10:01 PM
For years a thought has been going through my mind. What if an application existed (like the one for 2nd edition - BirMail) that is based entirely on MySQL and PHP (or ASP) and automates the turn processing, site building and site management procedures completely. An application that fully incorporates everything a Game Master might need. For example.
1) Turn processing. Using a random generator procedure (PHP incorporates one I believe) resolves the turn for the DM. However he may step in any stage of the procedure and allocate a modifier for the dice, if he so wishes. In addition he may manually resolve a few turns. Then the machine automatically sends the turn results (via mail and web form) once the turn is completed. At most a few tens of clicks are needed by the DM (a day at most for the turn processing)
2) Updates the site with the turn results. The DB is automatically updated via scripts from the PHP or ASP engines, and no DM effort is needed.
3) Email management. The engine determines what mail addresses are available to the players and what are not. I mean that not all players should be able to send mails to every other player in the game. Also the time the mail takes to reach its destination should depend on the proximity, and various other conditions. And last but not least, a player should be able to send a predetermined number of mails per turn. Thus a limited yet realistic correspondence should occur during 1 turn of the game, setting the pace, and giving the DM some time to breath.
4) Battle resolution engine. It needs no introduction.
Though the project is massive, I believe that BR does not lack on people who are able to program in the aforementioned languages. It needs only organisation and long time commitement. Any ideas - thoughts - criticism?
PS: I guess that an application that offers the elements of the above, as well as interactivity and a dynamical environment where the DM may determine the parameters he wants to change, would be the ideal boost the BR pbem community needs.
Thanks
Jason
Benjamin
11-19-2005, 12:29 AM
If you look through various threads, you will see that this is being done by various people. Alas, I do not think it is a web-based program that they are working on. I'm sure, though, that you could jump into one of these working groups and make a web interface. :)
Good luck with it.
BrennanHawkwood
11-19-2005, 01:32 AM
That is very similar to the type of system I have been talking about possibly building. (Though I'd probably use ColdFusion since that is what I am familiar with). The other big difference is I would probably reduce the reliance on email for communicating turns and go with a web based (forum-like) interface.
Question
01-06-2006, 07:52 PM
So whats the update on this?
darkon
01-12-2006, 02:07 PM
The project never started. Apparently there was not much interest from the community.
Question
01-12-2006, 06:43 PM
Wasnt there quite a few people offering to help?What happened to them?
ausrick
01-13-2006, 03:10 PM
I think some people are still working on it. . . inbetween their Day Jobs, running and playing in their own pbems or table-top games, doing other projects, and of course U.S. Thanksgiving, Christmas, Newyears, and myriad other holidays are all just passed, (Not sure why society seems to end-load all the holidays, makes for a long spring and summer) writing applications for most people probably got put on the back burner to simmer for a while. I know Bluntaxe's application is pretty far into it, but I think he said he had to take a break for a while. I know several people have been in contact with him on it though I am not sure how they are progressing.
It seems to me that a lot of times these online collaborations get put on Hiatus if they never survive to the "Dev Team" stage. This is because you get x amount of people all working towards the same thing, but they're doing it independantly, and like in this case I've seen no more than three different DB's all tracking the same kind of things but in different ways. I am guilty of this too. When I had posed this question about working on some sort of domain tracking database a while back. I found out all sorts of people were working on their own. Some using ColdFusion, some using .NET. Most of what people were working on were very robust and took into account every aspect of the game. I was mainly looking at getting out of the tediousness of having to track domains and do all the math with a pencil and paper. . . and I've been trudgeing along to that end, but certain calculations have stumped me on how to make a relational DB represent them. I've had to take a pause because even when I started I had 7 or 8 other BR related projects i've been juggling.
And I blame my education. :p What I mean about that is in my programming classes in college, and I suspect in other people's educations as well, they never taught us how to be team programmers, it was always individual projects. And I assume they thought that we would learn those skills once we got out into the work place where I suppose we would have an IT Manager delegating responsibilities. Well, I landed in a support related position and am not a coder by trade (Not to mention my other degree is in art which lands me lots of satisfaction but no profit) and so I can write "Hello World" just fine but I don't have a clue how to be part of a software Dev. team.
So I guess what I think would be needed to move forward on some of these more amazing and robust apps would be to have someone step forward with a team leader type attitude saying "I need (a) amount of volunteers who are good with (b) language" and "I need (x) amount of volunteers that are good with (y) database language" because at the moment it seems to be a lot of individuals with their own individual ideas working on it individually, and that leads to burnout.
Question
01-13-2006, 05:36 PM
You are right, if this project is going to get anywhere we need to compile resources. Having a dozen different DBs is completely useless when you could have one guy working on the DB and the other 11 other parts of the project.
bluntaxe
01-13-2006, 08:05 PM
Ya, my project got held up because of holidays, and now because I've moved to a new laptop that doesn't have the .NET installed on it right now. I'll hopefully have that corrected soon and post my current version for people to review/look for more bugs. (that was another thing. I kept finding things I wanted to fix before posting a new version).
I could probably use at some point a volunteer to start adding data to the database, but I keep running into things that make me re-think the structure. So that might have to wait until it is close to done.
Gortlock
07-18-2006, 07:06 PM
Ya, my project got held up because of holidays, and now because I've moved to a new laptop that doesn't have the .NET installed on it right now. I'll hopefully have that corrected soon and post my current version for people to review/look for more bugs. (that was another thing. I kept finding things I wanted to fix before posting a new version).
I could probably use at some point a volunteer to start adding data to the database, but I keep running into things that make me re-think the structure. So that might have to wait until it is close to done.
Any progress report? I would love to have an automated Br db aid!
bluntaxe
08-02-2006, 07:33 PM
Any progress report? I would love to have an automated Br db aid!
Current Progress: Limbo...
I did pull it up, clean it a little and compile it if anyone wants to take a look. I'm not sure how helpful it would be in the current state.
1st: Install the .net framework
http://www.bluntaxe.com/files/BR/dotnetframework.zip 19.9MB (you might want to pull this directly from Microsoft or some other faster server).
2nd: Install the program
http://www.bluntaxe.com/files/BR/Setup_BR.zip 5.8MB
gazza666
08-07-2006, 11:54 AM
Another guy and myself from my group are working on something along these lines, though at the moment it's a rich client rather than a web application we're building (selfishly, we're making it for our own tabletop game rather than the benefit of the masses).
I don't have anything ready to go for this in particular, but I do have 3 utilities I wrote that might be of interest:
EGen, an "encounter generator". You plug in the EL you want and the terrain you want, and it will spit out an encounter for you. It "knows" about all monsters in MM1-3 and the Fiend Folio at present, and all generated encounters are "legal" in the sense that they conform to what the Organisation entries for each monster say (for example, a monster listed as "Solitary" will only ever be encountered alone via EGen). It's mostly for random encounters. The generated encounter will give you the number and name of the monster, the CR, and also the source and page number.
NGen, a "nation generator". You give this tool a population size and a breakdown of the commonality of various races, and it will spit out a list of every single person in that population by class and level (it doesn't name them or anything; you'll get results such as "1059 1st level elven commoners" and the like). It generates this by default using the DMG suggestions for city generation, although it also has a couple of standard alternatives and can be fairly easily reconfigured for other situations.
TGen, a "treasure generator". Feed it an encounter level, and it will roll up the treasure for that encounter. This isn't really complete; it doesn't know about every single wondrous item, for example, although it is capable of generating weapons and armour and (I think) scrolls and potions; it defaults to just saying that there are X medium wondrous items or something similar. When I get around to finishing that off (fundamentally it's just a case of data entry from here) it should probably be integrated into EGen.
I'm pretty sure publishing these violates WotC copyright, but if you are interested in any of them give me a PM and I'll package them up for you.
Powered by vBulletin® Version 4.2.2 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.