Multi-programming

[Hooman]

Multi-programming: like pair programming, but with more people.

I was thinking we should have a general online programming session here on the weekend. It would be free to join for whoever was interested. If you're shy, you wouldn't need to actively participate, you could just treat it as a webinar. A topic will be chosen that is fairly simple to get into without prior knowledge, so it should be accessible to people with little to no programming experience. The topic will also be chosen so more experienced programmers may be given exposure to a new area of programming they may not be familiar with yet.

For the topic, I was thinking of re-implementing some damage calculation algorithms from Outpost 2. To add some flavour, this can be done while following a Test Driven Development (TDD) process, where unit tests are written first, and then code is written to satisfy those tests. That would provide an introduction to automated testing of the code, while also testing the tests.

I'm going to tentatively suggest hosting the session on this Saturday:
2018-09-29  14:00 UTC
2018-09-29  15:00 London
2018-09-29  10:00 New York
2018-09-29  07:00 San Francisco
2018-09-29  04:00 Honolulu  (4am, sorry Hawaii)


@Brett, not our usual hours, I know, though you also said you'd be busy for the next little while.


Please reply if you are interested. (You may suggest an alternate time).

[leeor_net]

Definitely interested -- we talked a bit about this earlier today but definitely count me in. I don't expect to be doing anything at that time as it's still pretty much morning for me (well, it is morning for me but 10am seems late these days). Anyway, I'll be there.

[lordpalandus]

I might be interested, some other time.

Saturdays tend to be my crunch-time day for getting last few features out the door for the weekly game update. Plus, I'm UTC-7 so that would be 7am for me. Sometimes I'm up at that hour, if I don't go to bed at 2am from a code marathon (I'm a night owl) other times I'd be up around 10am.

This week I'm quite busy anyway, as I'm doing a lot of UI work, bug reports, and suggestions, so I'm swamped for this week regardless. Got 5 different people providing feedback this week, (from my usual 1-2) and so I got a lot more bug reports and suggestions than I normally do.

[Vagabond]

Hooman,

I am actually on the East Coast of the US now. Moved my family yet again, so 'the usual' time has changed. Sorry for not mentioning earlier.

What is the end state of the damage code? Are we just reproducing it in C++? Will it somehow still interface with the game or something?

What are you thinking for code sharing? Are we using TeamViewer/Discord? Or are you talking about we all commit to a repository together and chat as we do it?

There may be a hefty intro required if others are not familiar with the chosen unit test framework and or repository (if we are using a repository). Not that this is a problem as it is all good to learn. Just pointing it out.

Not sure of my weekend plans yet. Will talk to my wife and try to get back by end of Thursday.

-Brett

[Hooman]

@Leeor, glad to hear it! 

@lordpalandus, well if by chance you make it to bed early, the testing part could be really useful for you. 

@Brett, Ahh yes, you mentioned you were going to move, but I wasn't aware you'd already moved. That may simplify time issues. 

The damage algorithm will simply be reproduced. It could be used in a calculator or simulator, i.e. 5 laser lynx versus 4 microwave, who would win, and with what probability over multiple simulations, or effects of targeting single units versus spreading out the fire. I was planning on using JavaScript for this one, with the Jest test framework, which should be easy to learn.

If this does result in a battle simulator, we could post an interactive version on the website. 

I've been quite pleased with Discord for audio, and was planning to use that. For screen sharing, I was thinking of using an online IDE with multi-user support. I'll need to do a bit of testing today and post the details. That would minimize installation requirements for participants. As a fallback, TeamViewer should allow multiple participants.

[lordpalandus]

I do do a lot of unit testing in my game. It is the only way to catch some of the more nefarious logic errors, where code will refuse to run, seemingly for no reason, but there is always a reason with code. Either it is a poorly chosen comparison statement, nested if/else improperly, or a minor typo with a string (unfortunately, 2.7 python doesn't have enumerators, though it does have the enumerate() function), is what it usually happens to be.

As for the damage algorithm, how were you planning on implementing Concussion and Penetration damage types? As I recall, Laser is full Penetration damage and Microwave is 50/50, and typically the laser would lose due to the way Penetration damage works; otherwise the Laser should have more points of damage overall, compared to Microwave.

Will there be a recorded video of the session, for those of us that don't make it though? To watch as an after-the-fact, kind of thing?

[Hooman]

At this point I don't think I'm setup to make a recording of the session. That's something I want to look into for the future.

Are you using PyUnit for Python unit testing?

[lordpalandus]

No.

I make custom unit tests as the need demands.

[Hooman]

Are the tests simple pass/fail reporting, with summary output of all test results? Do they run fully automated with a single command, or does it involve manual interaction or play testing?

I have a feeling you may be doing play testing, or some kind of ad hoc testing, rather than unit testing.

[lordpalandus]

It highly depends on the current needs of the situation.

One should use the appropriate testing method for the job, rather than using the same method for all circumstances.

Yes, I do a lot of playtesting and ad hoc testing. However, whenever I do anything heavy with numbers, such as balancing stat progression, I will use unit testing. One doesn't need to do unit testing at all times; often playtesting or ad hoc testing is sufficient.

EDIT: https://www.softwaretestinghelp.com/types-of-software-testing/

Here is a nice long list of different kinds of testing. I'm sure I've used each one at least once by now.

[Hooman]

Quite right, yes, the various methods have their uses. I was tempted to add something about the uses of different testing strategies, but perhaps I'll save that for a separate thread.


Anyway, we'll be covering some automated unit testing stuff. Hopefully we can dive a little into filesystem watchers to automatically run the tests when source files change. That part should be fairly language agnostic, so you can use it with any language you want.

[Vagabond]

I'll be available at the given time on Saturday. Are we just meeting in the IRC Chat Room?

-Brett

[Hooman]

I will be on IRC. That will be a backup chat method if any of the other services experience any difficulties or disconnections.

I was looking back at my notes on cloud IDEs. I think CodeEnvy might be worth a try for this. As there are a few unknowns, I'd recommend people have Team Viewer available in case we need to switch to that. And of course Discord for audio.

The software make take a bit of time to download, install, or create an account. People may want to try pre-installing things, or pre-creating accounts to make sure the software works.

[leeor_net]

So the Husband usurped my time and decided what I'm supposed to be doing tomorrow in the morning... so I'm not sure if I'll be available. -_- I will definitely try to make myself available though!

[Hooman]

Boo! If he wants you, he has to fight me for you! 


Since this is relevant to the topic, I thought I'd provide a link to an old post:
Outpost 2 Damage Calculation

[Hooman]

Session starts in a little under an hour.

I'll be on IRC for anyone that needs help getting setup or started. For joining the session, I think I need to add you to a Team on CodeEnvy.