Post: #9

(08-26-2013 02:41 AM)RanXerox Wrote:  My suggestion is that, as you discover them, write down your very specific requirements. For example, saying "Pre-T2A, T2A, or UO:R (with only one facet) look and feel" has a lot of broad connotation... so narrow that down as specifically as you can. Then collect all those requirements in one document/wiki so that when you start building it out, it can be referenced.

An excellent suggestion. I was a bit vague in my initial post, and I actually did create a wiki last year, detailing in pretty specific terms what I am hoping for in various areas. I have been editing it since I reconsidered the project a few weeks ago, and also since I have refreshed my experience of the game via a few free shards, which spawned a few new ideas (and maybe killed others). I am still refining my design, and including it on the wiki, but I have a fairly firm idea of how I wish various systems to work.

I agree that my definition of era is a bit vague, and is more an issue of aesthetic than application (a matter of a certain graphical style, mostly graphics and items that do not fit my vision, which I am likewise detailing). As far as the actual mechanics of each era, I need to look more into it, as much as possible, as I played T2A way back in 1998-99, prior quit to UO:R, and have only played various free shards on and off over the last few years. Basically, I know what I want to do, but am not certain what is the best way to go about it.

Quote:My final word of advice is: Requirements are not just a statement of system behavior, they should also be explained as to why they are a requirement, and whose requirement they are.... this is very helpful when you discover limitations and need to decide whether that requirement should be (or can be) changed or not. Don't hesitate to add "limitations" to the list of requirements.... for example, maybe something is impossible to do (perhaps because the client software doesn't handle things that way) so including that detail as a requirement, imposed on you by the client software will help so you don't forget about it.

I have done this as well, though not much in the way of actual technical aspects yet, as I am not a programmer. I was working with POL before, and included various notes on where certain information is stored, certain systems that will work for the shard, commands, etc., including links, as well as a growing list of artwork and items that are incompatible with my vision. If I am to change to Sphere I will need to create a new section to deal specifically with the way Sphere handles things.

I began the wiki with a general outline page as my mission statement, with a section on each feature/system I wish to implement, why I want them, and how they fit in with the overall theme, which I am likewise condensing into a separate, easily digestible mission statement. I tend to start out with "if possible," on most descriptions (save for things I am certain can be, or have been implemented). I likewise linked many of these more detailed systems/features to individual pages on each subject.

Your post has inspired me to further refine these, and to clean up the wiki a bit more, particularly the bits related to POL. I also prioritized my system/feature list, first priority being getting a basic foundation and world set up that I can work ad experiment with, and come to understand. Most POL script packages are so customized, and contain so many features that I do not like, that it is difficult for someone with my lack of knowledge to weed through it and decide what to keep and what to toss. With Sphere is seems easier to turn features on and off.

Quote:Once you start building the shard, you should link the implementation back to the requirements so you know where they got implemented. You should write a test case for your requirements to ensure you know how to prove they are working, and you should ultimately have a test plan to be able to run through all the tests in a reasonable amount of time.

So:

1. requirements (with details on whose it is, what is is about, and a link to where in the code it was implemented)
2. implementation (with details on which code files were used to implement the requirement, linked to a test case to prove it works)
3. test case (with explanation on what steps to follow to test the implementation and therefore the requirement)
4. test plan (a guide to step by step through all the test cases in a efficient way)

My suggestion is to store all this information in a wiki so its easy to collaborate on and manage.

This is excellent advice as well. If I do embark upon this, I can see that it is going to be quite the task. I quite agree that detailed documentation is of enormous importance. Thanks or the advice!

---

(08-26-2013 04:40 AM)Mordaunt Wrote:  Sphere and spherescripting is probably the easiest to pick up if you don't have any programming knowledge.
If you have other questions we also have an IRC room (click chat at the top of the page) which often has people in that can help.

From what I have seen so far, I quite agree. Thanks for the information. I am sure I will be visiting the forums and IRC quite bit as (if) my project progresses.

---

(08-26-2013 06:26 AM)Rattlehead Wrote:  i would like to add a couple things

i started scripting in sphere 10 years ago (or more) and at that time i had no programming knowledge at all, not even a spec, so i learned it, from the original taran tutorial, spent a couple hours a day for a couple weeks, picked up on it pretty quick

so after a while, the sphere devs released the MySQL features, which instantly gave me something else to learn, SQL is different from most other programming languages (at the time i didnt know this tho) and went and read everything i could about SQL

long story short i now know HTML, PHP, MySQL/MSSQL, Javascript, ASM and have mastered most of them i am familiar with C++ and C# yet i still use sphere and sphere only, as the possibilities are endless with sphere, even tho C# is a full featured programming language, it cant hold a candle to spherescript, and i believe its becus spherescript was written specifically for UO unlike C# thats a general language for thousand of other things. i havent found anything i couldnt do with sphere yet, anything and everything i came up with, i have been able to implement, and if it wasnt for sphere i would still be a noob with no programming skills at all

So Spherescript and SQL different languages, but can both be used in Sphere? I am reading up on the MySQL tutorial. Thanks for the info. Can you point me to any other good tutorials?