Maximum PC

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.

Manta

#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

Manta

If I am coding anything I still do some basic flowchart just to help me organize my ideas and how the program will work basically. The college I graduated from in 1999 was still teaching a programming logic class that required lots of flowcharts. I know they still teach the class because I talk the the instructor for it and now the mostly use Viso for the flowcharts rather than the old plastic templates we used when I took it. Ah memories lol.

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?

Damn... plastic templates in 1999! Sucks.

For a small project of say one to three classes, I'll normally do some use cases then spend some time thinking about the reqs. At that point, I'll identify the modules and attributes/operations for each. If there are enough methods and attributes, I'll go ahead a do a class diagram on scratch paper.

When coding a module, I'll normally use a piece of scrap paper and try to draw the algortithm, or what is happening, on paper (usually a couple of squares w/ arrows everywhere). If I'm pretty sure that I have it down, I'll write down a quick pseudo-code outline mainly so that I don't forget something (actually, i'm usually doing this while walking through the normal case).

I like the XP idea of writing down some test cases before doing the code. I normally pause for a minute to think a little about the corners, but I rarely write the test cases before hand.