Planning Code in a team

[Guest]

Preface (You can skip if you want)

Spoiler

 

I downloaded 2 free programs to design classes & plan logic.

Spoiler

Not important but...

Nclass is the class designer (from sourceforge)

Violet UML Editor is the UML designer (Maybe from source forge?)

From my previous thread asking about documentation, I was able to convince the leads of my project the importance of documentation. Some changes in leadership based on immaturity & laziness put me into the lead programmer position & now someone else wrote the design documents of "This is what I want, these are the things that should also be included." It has a lot of mechanics & features listed, but it's not complete. Without these documents, I doubt I could have planned accordingly to fulfill these requirements without drastic troubles. Now that I'm designing classes & logic... I would like some help in directing my associates. Hopefully this thread can assist others hoping to work on large projects.

PS, I've never worked in an organized team. I was hoping to be lead/organized but, I guess that's not happening

 

 

The main discussion of this thread:

Some questions I will answer

What is my team's capabilities?

What did I do?

What am I planning?

What do I expect?

 

Some questions I hope you will answer

What should I do?

What should I expect?
How can I improve?

Anything I did right?

Anything additional?

 

My answers:
 

Spoiler

 

My team's capabilities:

My entire team is a large conglomerate of volunteers hoping to develop a video game. My associates in the programming department is mostly made of high schoolers (or younger) and early University students. (3~ good guys & 2~4 MIA) They can write some decent code, but aren't much for planning at the moment. Our last prototype was stitched together by my direction in about 2~ weeks with spaghetti code.

 

What did I do?

Right now, I planned most of the classes in Articy:Draft but that isn't free, so I remade my classes in NClass. As we're making a large scale project using an OOP language, I mainly plotted out where variables are stored & inheritance.

I designed 1 non-gameplay system in plain English using Violet UML.

 

What am I planning?

I plan to design all the classes & data storage in NClass & assign programmers to plan out their logic with Violet UML before writing any code so new programmers & existing programmers can modify/follow logic based on the intended outcome. Programmers will be required to specify the class in which they intend to work in. If programmers need additional class variables or variables to change location, they will let me know.

 

What do I expect?

I expect programmers to feel creatively inhibited & demoralized because I am limiting how they're allowed to write code by defining variables in classes & a disdain for bureaucracy. When a programmer wants to add a new feature not in the design documents, they will send me a UML layout & class design.

 

 

Can anyone help give me advice, personal accounts or thoughts on this process? If you use planning or planning software, thoughts, opinions, observations? also the questions I asked above:

Spoiler

What should I do?

What should I expect?
How can I improve?

Anything I did right?

Anything additional?

 

Thanks to you all for your help!

[Guest]

The topic is a bit broad like this, no?

1 hour ago, fpo said:

Our last prototype was stitched together by my direction in about 2~ weeks with spaghetti code.

I would start here with the team. Go with them through the thought process of why you consider the code to be spaghetti code. About what changes to it would bring what benefits and so on. If it was your direction some reflection on how it all turned into this sort of code may be good as well 

 

If the team are mostly volunteers it's important you agree on a work mode rather than have one person decide on it. You make them spent their time with UML. Would you want that would it be the other way around? 

 

I am not convinced at all that for the team you have that UML is of any use here. It brings a lot of formalism to what may not even be in any way object oriented code or structured the way UML assumes. Games written based on a Game Engine may end up being a lot of scripts. Games have some very different things going on compared to enterprise software (like handling global state or being totally ok with something like that in the first place).

 

There is nothing wrong in doing some software design and drawings. But for that you need a pen and some imagination of squares, boxes and arrows. Any more graphical syntax seems too much. And if the last game was created in two weeks, whats your timeframe here? 2 weeks don't sound like any UML to me. Even 2 months don't.

 

It seems more important your team learns how to create games in the first place? John Romero (one of the Doom guys) often recommends starting in 2D games using something like Corona.

 

It's more important to what a player should be able to do in the game rather than the code being specified in UML in advance. I would never put UML first.

Are you creating a game at all?  (I only assumed this).

 

But the story stays the same. What does the player (or user) need to do? What is the easiest thing to implement that allows you to do that (or at least a part of it). Refactor, Polish. Go to the next thing (try iterating together, you, your team, your players/users).

 

It's very good to care about the code quality. But the decisions need to be suitable for the situation at hand - not the one you would like to plan for.

 

[Guest]

2 hours ago, wemu said:

The topic is a bit broad like this, no?

Yeah, I was hoping for general advice on leading a programming team.

2 hours ago, wemu said:

I would start here with the team. Go with them through the thought process of why you consider the code to be spaghetti code. About what changes to it would bring what benefits and so on. If it was your direction some reflection on how it all turned into this sort of code may be good as well 

The reason it was spaghetti code is because we had a few random scripts here & there with features not really planning to interact with other systems. Most of this was written with our last lead in charge. He was removed & I had little time to make something complete with what we had. (It's very basic compared to the final premise)

2 hours ago, wemu said:

If the team are mostly volunteers it's important you agree on a work mode rather than have one person decide on it. You make them spent their time with UML. Would you want that would it be the other way around? 

I would like to UML everything. I haven't given out any tasks for a while since the game's design wasn't fleshed out enough. I don't know if I should have them wait any longer since they'll probably leave.

2 hours ago, wemu said:

I am not convinced at all that for the team you have that UML is of any use here. It brings a lot of formalism to what may not even be in any way object oriented code or structured the way UML assumes.

What does UML assume?

2 hours ago, wemu said:

Games written based on a Game Engine may end up being a lot of scripts. Games have some very different things going on compared to enterprise software (like handling global state or being totally ok with something like that in the first place).

We are working in Unity & creating a large scale networked game where many systems are intended to be intertwined. (I know this is a stupid project idea for the people making it.)

2 hours ago, wemu said:

There is nothing wrong in doing some software design and drawings. But for that you need a pen and some imagination of squares, boxes and arrows. Any more graphical syntax seems too much. And if the last game was created in two weeks, whats your timeframe here? 2 weeks don't sound like any UML to me. Even 2 months don't.

It was only the prototype. It's not going to be completed in a matter of months. I want to plan the game out as much as I can for scalability so a long time later, we don't have headaches.

2 hours ago, wemu said:

It seems more important your team learns how to create games in the first place? John Romero (one of the Doom guys) often recommends starting in 2D games using something like Corona.

I am not the project lead. I am the programming lead. We can make games but I need help creating infrastructure. The project has been in "prototype" for about a year. I joined the project a month ago & turned it into more than an idea guiding people how I could just aiming for the prototype.

2 hours ago, wemu said:

It's more important to what a player should be able to do in the game rather than the code being specified in UML in advance. I would never put UML first.

Are you creating a game at all?  (I only assumed this).

We are creating a multiplayer 3rd person shooter with light RPG mechanics.

2 hours ago, wemu said:

But the story stays the same. What does the player (or user) need to do? What is the easiest thing to implement that allows you to do that (or at least a part of it). Refactor, Polish. Go to the next thing (try iterating together, you, your team, your players/users).

The design document outlines this. I want to outline the code structure.

2 hours ago, wemu said:

It's very good to care about the code quality. But the decisions need to be suitable for the situation at hand - not the one you would like to plan for.

For this large scale project I feel planning is important. I don't think we should just wing it & write single use code.

[Dat Guy]

A Golden Rule:

Planning software never works for you.

[Guest]

On 7/8/2019 at 2:07 AM, fpo said:

What does UML assume?

it is a specific syntax and formalism that assumes people can write it and properly read it as well. And not all UML terms necessarily translate too well in your programming language.

I encountered quite some situations where even senior developers would misunterstand some of the diagrams. 

Also, these diagrams suggest being true. But often they are not.

And some UML tools allow you to disable custom mode and turn on strict mode. Haven't met many people that are then able to create a diagram... not the most humane technology - but that is just my opinion.

 

On 7/8/2019 at 2:07 AM, fpo said:

The design document outlines this. I want to outline the code structure.

That certainly is an important goto. But to outline structure, any combination of squares and arrows may be enough already and better to understand for your audience of the diagrams. There are some approaches to have them generated and have them "alive": https://leanpub.com/livingdocumentation

So the structure you want to go for is in the code, the result is checked against rules and the resulting generated drawings.

 

On 7/8/2019 at 2:07 AM, fpo said:

For this large scale project I feel planning is important. I don't think we should just wing it & write single use code.

Yes, planning is important. Think about it!

But still! Evolution is also important. Learn as you go, refactor against what you learned. That is also an important habit. Do some planning ahead! But don't plan things you will not implement. drawing this line is also important (and very hard to do alone. go team!).

 

[Franck]

On 7/13/2019 at 6:22 AM, wemu said:

That certainly is an important goto. But to outline structure, any combination of squares and arrows may be enough already and better to understand for your audience of the diagrams.

Agree. 99% of UML got misunderstood by someone at some point but in 21 years experience i have yet to see a square with arrow flow chart fail.

[Guest]

On 7/8/2019 at 6:11 AM, Dat Guy said:

A Golden Rule:

Planning software never works for you.

I think I was more so planning workflow & creating documentation.

I modified the "Waterfall design" to basically boil down to:
1. Read the design requirements (Main planning phase)
2. Assign task to individual
3. Individual prototypes & writes UML

4. Individual rewrites code based on the UML for the actual program.
There are some agile arrows pointing to earlier steps.

On 7/13/2019 at 6:22 AM, wemu said:

it is a specific syntax and formalism that assumes people can write it and properly read it as well. And not all UML terms necessarily translate too well in your programming language.

In my modified waterfall design, I had them draw out UML based on "prototype" code.

On 7/13/2019 at 6:22 AM, wemu said:

And some UML tools allow you to disable custom mode and turn on strict mode. Haven't met many people that are then able to create a diagram... not the most humane technology - but that is just my opinion.

I found a free program called Violet UML.

On 7/13/2019 at 6:22 AM, wemu said:

That certainly is an important goto. But to outline structure, any combination of squares and arrows may be enough already and better to understand for your audience of the diagrams.

Yeah so I outlined the classes in one program called NClass where I show inheritence & what variables I predict. Then when programmers complete their UML, they will tell me what variables they actually need & we adjust the NClass document.

On 7/13/2019 at 6:22 AM, wemu said:

So the structure you want to go for is in the code, the result is checked against rules and the resulting generated drawings.

 

Yes, planning is important. Think about it!

Yeah, I am only planning code that's inside the design document.

On 7/13/2019 at 6:22 AM, wemu said:

But still! Evolution is also important. Learn as you go, refactor against what you learned. That is also an important habit. Do some planning ahead! But don't plan things you will not implement. drawing this line is also important (and very hard to do alone. go team!).

Thank you for the input!

1 hour ago, Franck said:

Agree. 99% of UML got misunderstood by someone at some point but in 21 years experience i have yet to see a square with arrow flow chart fail.

How did you clear up the misunderstandings?

[Franck]

24 minutes ago, fpo said:

How did you clear up the misunderstandings?

Flow diagram / execution diagram never failed so far. Not saying perfect but there hasn't

been a problem where someone didn't understand the logic of where we were going.

 

Using modular approach spec of each module and create multi level flow diagram. A bit like you would split task in AGILE