the butter on the muffin wrote:
Hi there all. I was going to start a massive project in my spare time, and I was wondering if I could get any suggestions to start on the right foot. My idea is to start an open-source, platform-independent LARP (specifically Minds Eye Theatre) character tracker, akin to Grapevine (if anyone's heard of it). What I (ideally) would like features to include:
- characters generated in a GUI, stored in XML format for ease of manipulation
- a 'proposal' mode for players to submit character ideas over the internet, and a 'storyteller' mode for approving proposed characters as well as functions like adding experience to characters
- the ability to expand as new things become available
So, any suggestions?
Sounds like you've barely scratched the requirements stage...
Suggestion 1: Flow Chart
Suggestion 2: Pseudo Code it.
Suggestion 3: Learn a good language(s) (Like Python - but I am biased. Java is likely better for this).
Suggestion 4: Keep it modular - that will help with expandability. It also help us when you come here and have a bug you can't find or other issue.
#1 You are OLD! I shouldn't fib though, since I too have done a flowchart or two.
They are rarely used these days though. I'll occasionally flowchart something that is tricky. However, they are now sort of shunned because they don't help much when doing proper OOA/D.
Software engineering has changed considerably since the days of flowcharts. He should start by creating some use cases - basically, a story board of how the different users will interact the software. After that, he should be in a good position to write a requirements document.
I wouldn't say flow chart for everything - but for something that is so modular I would do it. And not those Nambie Pambie single flow systems you likely learned
With one arrow to each box, silly shapes you have to follow and mandatory rules like "you must start with an input box"
What do you think a story board is? Its a modern flow chart. Until he can fully visualize what he wants to do and how the "boxes" must interact with each other I just think he will be hitting walls and going back too often.
With the introduction of countercurrent and concurrent methods, flow charts are not the linear things you might have in your head. Granted, you don't see them published very often, but they do get used. By programmers? Maybe not. By really good programmer in supersecret privacy? Maybe
I could have said:
"Create a logic table"
Now thats old school
Oh, don't get all JPL on me.
As you sort of said, traditional flow charts aren't really done anymore. Not in vogue. Replaced. History. Use case diagrams, which don't actually need to be a diagram - a text description is fine, are usually the first step now. From there a reqs doc is more likely to contain all the essential information, a couple of steps from that point, he can start to create class diagrams, sequence or activity diagrams, etc. If a paticular module is tricky, he might want to create a flow chart for it.
How is the OOP going btw?