How do you plan your scripts/systems?

[Harzach 2517]

This might be a dumb question, but I have no background in writing code other than what I have learned here.

 

I started building a new training scenario for my group last week. Partly out of necessity, and partly out of a desire to challenge myself, it quickly grew into the most ambitious bit of scripting I have faced to date (of course, some of you would see it as a cute bit of fluff). I started taking notes as my idea grew, then shifted to a classic outline form as more features/details evolved. It helps with keeping track of what I need to do and how each piece fits into the system, but I am having a difficult time visualizing it as a whole - I am still planning upward.  

 

How do you prefer to organize your larger projects at the top level? Do you even? Should I?

[HazJ 1289]

It may be easier for me to answer your question if you could tell me what your training scenario will have, etc and/or what you have done so far and how.

[Harzach 2517]

It's not really about the specific project, I'm just wondering how people who actually know what they are doing organize their workflow.

[HazJ 1289]

May seem like an obvious answer but not sure how else to explain it...

I use project management system (RedMine/GitHub/etc) and a shit ton of planning before I even do any coding. I always start with the necessities and concept base then build upon it. Though, with basic/simple scripts or anything small / standalone I just get stuck in straight away.

[Harzach 2517]

As I said, obvious to folks like you who know what you are doing :D

[pierremgi 4890]

The good method is what is convenient for you. You can start with the playable units. Do what you want with their loadout, the respawn/revive, then their tasks.

The core of the mission are tasks anyway. Most of public missions are: sweep a baseor an area, kill someone, blow up the tower, find evidence or grab intelligence, steal a vehicle...

  Nothing really new under the sun but you can add some spicy stuffs : blow oil tower and have a great fire on pipeline, find underwater crates inside wreck, find a boss and change the relationship with resistance...

You can add spawning enemies, spawning civilians,  add vanilla or custom supports. Arma is "modular". You don't need to do all that stuff at once. On the other end, keep on mind creating functions. You can use them in other scenario. Just adapt.

MP mission must be written for MP as soon as you're opening the editor! SP can be compatible but scenario can be slightly different (no (vanilla) respawn system, switching unit with same behavior  is not evident ).

 

Last but not least, with several players and a bunch of enemies, your server will "burn out". If the FPS is not impacted, you will see apathetic  enemies waiting for the bullet which will deliver them. If you want to keep a good response and reactive AIs, spawn small.

[HazJ 1289]

If you have a good and solid concept. The start should be easier. You don't have to plan all the simple specific stuff out. Just the core, end-game, etc... It doesn't have to be even written but it sometimes does help. If it is a big project then get input from your community, etc... Use forums or something (Trello) to discuss it and have people throw in ideas. Project management systems play a big part in later development too. For example, take Authority by @Tankbuster - This mission was first created many years ago and we are all still building on it still. The current GUI (in the mission atm) was made and plans were made to have it adjusted. Here is a screenshot to give you an idea:

Then obviously I reply with some concept designs, ideas, etc... Then BOOM. The magic happens. Anyway, you get the idea. lol!

[Harzach 2517]

6 minutes ago, pierremgi said:

The good method is what is convenient for you. You can start with the playable units.

 

First part makes sense. Second part - well, my question is not even that specific. Just asking how you all organize your workflow. From general concepts to specific applications or websites that help you to manage projects.

[Mr H. 402]

It also helps to have templates. When I first started building missions I used the (now mostly outdated) F3 framework. Now I have changed it up to a point where you'd barely recognize it. I also have a template for function headers, for addon making etc. + saved compositions in the editor. This saves you some time for things you do for every mission.
For bigger projects I do some research first, what commands will I use? etc.
For UI making it helps to plan ahead with a pen and paper, the old fashioned way.
I also found that its good to start writing stuff away from arma and organizing it before hand, even if I often have to correct a lot of stuff once in game.
As someone said above github project planner can be very useful too.

[Grumpy Old Man 3546]

I usually keep stuff split by functionality/content as much as possible.

 

Stuff that should be tweaked goes to a separate file into mission root for ease of access, like multipliers for enemy units, customizable parameters etc.

data related stuff also goes to a separate file inside /script/GOM/something, like unit loadouts, arrays of positions etc.

Then I put everything that's CPU intensive into pre/postInit calls where possible.

 

Helps keeping things in order, especially when you reach a total of 150+ .sqf files, heh.

That's about it.

 

Cheers

[HazJ 1289]

I also have 3 folders with sub folders inside.

client

server

shared (also known as common)

 I also make sub folders in functions folder: core, etc etc

 

EDIT: Maybe a bit OTT but I like it very tidy lol.

client -> functions folder has core, displays, etc as mentioned above...

[Rydygier 1317]

Hm. Besides very few very general framework rules for bigger projects that emerged from pure experience (more habits, like having one or few big files for functions definition alone, one for "main loop" where applies and one for defining variables and init phase, sometimes subfolders are involved (sounds, pics, portions of sqfs), if the project is that big...) I don't really. My brain somehow does and order somehow appears from the chaos of possibilities, details depend on the project. And I don't even try to keep in my conscious memory all the code all the time in all details. Focusing only on actually written piece, rest stays only as a rough shape in the corner of my mind. Also AFAIR never tried to draw a diagram of planned logic, that stays in the head, although sometimes I note my "todos" list as new ideas appear and struggle with math and geometry in my notebook when required. The most messy code, I ever created was so messy beacause I wasn't writing it from the scratch, but had to build own code on the top of someone's else. 

[Grumpy Old Man 3546]

51 minutes ago, Rydygier said:

Hm. Besides very few very general framework rules for bigger projects that emerged from pure experience (more habits, like having one or few big files for functions definition alone, one for "main loop" where applies and one for defining variables and init phase, sometimes subfolders are involved (sounds, pics, portions of sqfs), if the project is that big...) I don't really. My brain somehow does and order somehow appears from the chaos of possibilities, details depend on the project. And I don't even try to keep in my conscious memory all the code all the time in all details. Focusing only on actually written piece, rest stays only as a rough shape in the corner of my mind. Also AFAIR never tried to draw a diagram of planned logic, that stays in the head, although sometimes I note my "todos" list as new ideas appear and struggle with math and geometry in my notebook when required. The most messy code, I ever created was so messy beacause I wasn't writing it from the scratch, but had to build own code on the top of someone's else. 

 

Been there, on my own stuff.

Involved various functions spread all over the place.

Wasn't much of a problem when working on it,

coming back to this mess after a 6 month break on the other hand made me just start from scratch again, heh.

 

Cheers

[TeTeT 1523]

I usually follow a simple top down approach for the main task, at start consisting of a number of systemChat messages spread over functions eventually. For the individual sub tasks I either use a separate mission or debug console for proof of concept work. Those code pieces are then integrated into the main task step by step. Sometimes the result of those sub task 'experiments' have quite an influence on the main task, as it didn't work out the way I planned it at start. Then I overhaul the main task approach.

 

I second GOM's notion that coding is usually a fight against some sort of chaos, what made perfect sense when writing becomes a mess after a few months. 

[HazJ 1289]

35 minutes ago, TeTeT said:

I second GOM's notion that coding is usually a fight against some sort of chaos, what made perfect sense when writing becomes a mess after a few months. 

Yup. Don't forget:

OR

 

[Mr H. 402]

About that: It's true that reworking your own code long after you wrote it or working on someone else's code can become nightmarish! So I try to name my variables with very explicit names.
I very often browse other people's code to see how they did this or that and sometimes you read things with variables named in a single letter like if (_c) then {_b setDamage 1}; that's an awful way to name stuff IMO.
Browsing other people's code and github's is the way to go. Un-pbo-ing stuff is a good way to learn. (Also a reason why I hate obfuscating).

[HazJ 1289]

I agree with bad naming conventions as well. It is very important. As for comments, I don't really do them (not in SQF at least) even though I should or if I do, I remove them all once it is all working and ready to go lol.

[Grumpy Old Man 3546]

Another thing to add to the systemchats all over the place mentioned by @TeTeT,

I usually put in a function that's used to hand out debug info to either hint, systemchat and/or .rpt.

 

Can be called from any function since it's initialized via preInit and has useful parameters:

 

GOM_fnc_debugging = true;
GOM_fnc_Debug = {
	params["_override","_output","_message"];
	if (GOM_fnc_debugging OR _override) then {
		if (1 in _output) then {systemchat _message};
		if (2 in _output) then {hintSilent _message};
		if (3 in _output) then {diag_log _message};
	};
};

//this way you can enable debug messages like this:
_localDebugging = true;
[_localDebugging,[1,3],format ["Error in %1",_fileName]] call GOM_fnc_Debug;
//will print the error in filename message in systemchat and .rpt log if GOM_fnc_debugging is set to true

GOM_fnc_debugging = false;
[_localDebugging,[1,3],format ["Error in %1",_fileName]] call GOM_fnc_Debug;
//will print the error in filename message in systemchat and .rpt log only if the local debugging flag is set to true

Just made this out of memory, the real function is a bit too intertwined with other stuff from my library but should give anyone a better idea on useful debugging stuff.

Pretty much the backbone and mandatory for medium+ sized projects.

 

Cheers

[Varis 34]

You are talking "software engineering" and everything around it. There must be tens of thousands of books about the subject.

 

My top layer is the people layer. Is there a leader to the project, who does marketing, collects user feedback, and who codes what module / area etc. Then there are process and practice areas. How do you record issues or how do you track your progress and plan the scope of upcoming features. Do you have users who will do most of your testing? Read a short description about the Scrum process, it gives you a de facto industry standard how it's done in the professional world. Pay attention to the backlog, sprints, sprint grooming etc subjects, they can be useful ideas/areas to you.

 

One important aspect is a coding standard. I'm not sure if we have good guidelines for ARMA, but at least you should think about what kind of objects/classes/functions your script needs and how exactly you will name them. Already writing down a couple of names in advance can help you organize stuff quite a bit. Also to break the work into smaller chunks so you can see a concrete progress and can plan better. Tons of planning sounds good but don't overdo it - instead keep it simple and learn from your previous projects for the next. Success rate is higher if you keep it small and easy at start.

 

Also think in terms of Minimum Viable Product - what do you essentially need to create any kind of a complete system? Target that first and add the bells and whistles when you have released the first version, or just want to work on something "fun" for a while and can't stress about milestones etc.

 

Version control (git) is good and when you have multiple developers it's a necessity. However you don't need it at start unless you're really serious - there is a slight learning curve so it can be added later (same for most of my stuff above). 

 

Also please consider licensing. Is this open source, public domain or do you want to keep all the rights to yourself? What happens if you go AWOL and don't even read your ARMA messages. Are others allowed to maintain your code or make their own versions to suit their fancy?

[HazJ 1289]

I also use extensive debugging like you @Grumpy Old Man except my debug mode is set in config macro. To expand upon what you said though:

There is also a few others that people might find useful.

-showScriptErrors (most obvious and should be used)

https://community.bistudio.com/wiki/BIS_fnc_error

RPT is a good one. There are tools out there which highlight by using certain characters making the process easier, etc... Along with syntax highlighting and all those. Anyway, I am going a bit off-topic.

[Varis 34]

Also it could be extremely fruitful to have a mentor... just someone more experienced that can answer your quite basic questions and give some advice/ideas. But I guess it's more of a luxury to most.

[POLPOX 778]

In my cases, almost every things start from “What can I do with this script command?” For example, my favorite work Animations Viewer in Artwork Supporter is made from a script command: configClasses.

When I playing with the command, I thought “Oh, so now searching through configs is now possible? Then, can I improve or even remake the Zeus' Animations Viewer that is hard to use?” and BOOM! It's done.

So that's why I don't have missions to make, haha.

[johnnyboy 3797]

This is a great thread and its fun to hear how everyone approaches scripting.   I've been a programmer all my adult life.  In work, I'm much more disciplined and usually pseudo-code in high-level English and do a module breakdown before I start coding.  But Arma scripting is fun and creative so I'm much more chaotic.  For missions, I write  up notes for a progression of tasks, character dialogue, events etc.    But as I actually build them, Arma limitations or new ideas tend to radically change the whole design.  Like others, I keep a running to-do list of which 10 to 20% ever actually gets done.  And many scripts and missions evolve just because I have a funny or strange idea.  Property of Mabunga mission evolved because I wanted to see AI drive boats on the swampy Lake Limni on Altis, and it pissed me off that they couldn't.  JBOY Dog evolved because I love dogs, and I was sad that they were useless in vanilla Arma.  Other scripts were inspired by monkeying with atttachTo and setVelocity (birds of prey, fish jumping, flying chickens, burning barrels, Tanoan longboat, etc.).

 

I support all the good advice above (debug function for toggling display of script variables, organizing scripts logically in folders, descriptive variable naming, version control, etc.).

[pierremgi 4890]

1 hour ago, johnnyboy said:

  And many scripts and missions evolve just because I have a funny or strange idea.

And also because Arma engine doesn't like fantasy and it's a pain in the b..tt working around some psycho-rigidity (setUnitPos, setPilotLight, selectWeapon (launcher), ...).

 

1 hour ago, johnnyboy said:

I support all the good advice above (debug function for toggling display of script variables, organizing scripts logically in folders, descriptive variable naming, version control, etc.).

 

Yep! Before making sqf and functions, I write in sublime text2 (poseidon), I quickly test the code in a trigger set to true. It's easy for debugging. Same for helping on forum.

[atmo 29]

http://www.log-expert.de/

 

Is a very handy tool. You can open up the .rpt file and use filters to just show you what you are interested in....

 

Atmo