Author Topic: Remote Pair Programming  (Read 36654 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Remote Pair Programming
« on: May 21, 2017, 02:05:36 PM »
Would anyone here be interested in trying out remote pair programming? (As in screen sharing + Skype or similar). I'm thinking something informal, just to play with the concept and some tools.

If so, reply with a suggested date and time (including time zone).

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Remote Pair Programming
« Reply #1 on: May 21, 2017, 04:45:33 PM »
I've done this in the past, but right now would be tough for me. I'm in the process of moving, so my days are chaotic at the moment.

Personally I've had better luck with Google Hangouts than Skype for screen sharing and multiple participants. I think Slack has something as well, but their app requires a bit more setup.

In either case, what is the topic of interest? OP2 programming, or do you have some other thing in mind?

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #2 on: May 21, 2017, 10:14:40 PM »
Hooman,

Do you mean Pair Programming as described in Agile Software Development? https://en.wikipedia.org/wiki/Pair_programming

I would be interested in participating. I'm proficient in C# (for a hobbyist anyways) and get around enough in C++ to code the Outpost 2 levels. Any other language and it would probably turn into more of a teaching session than me actually contributing.

I've done some game jams before where myself and 2-3 other people get together and work on programming a game together. Typically a clone of an older game. We throw up a list of feature for the game on a Trello board (https://trello.com/) and then each pick a feature to work on. We typically start from scratch and work for a day on it to see how far we can get. In the beginning you step on each other a lot because the code base is small. So it requires someone being pretty good with revision control to sort things out if 2 people end up modifying the same area in code simultaneously. I think this is different from Pair Programming though since we are all typing code simultaneously. In Pair Programming, only one person is typing, while the other is reviewing/suggesting strategies/planning ahead right?

How long are you thinking for the session? A couple of hours? We should probably pick some sort of topic/goal for it as well though? Maybe something that could be completed at least in rough form in a single session?

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #3 on: May 22, 2017, 07:45:05 AM »
Quote
Personally I've had better luck with Google Hangouts than Skype for screen sharing and multiple participants. I think Slack has something as well, but their app requires a bit more setup.

See, this is the kind of stuff I need to figure out. There are a ton of different software setups to do this sort of thing. The only way to really know what works well is to try a bunch of them out. It will depend on the task at hand too. Some people use Remote Desktop for Windows and might perhaps code in Visual Studio, other people might use "screen" in a shared terminal on Linux and code in "vi". One person might host the session, or the session could be hosted on a server, perhaps even a temporary virtual machine from a cloud provider. Communication could be two way, or it could be a conference call. It could be voice only chat, or it could be video, and maybe that depends on bandwidth, or maybe that depends on screen space, or maybe that depends on privacy concerns and insecurities.

I don't really know what I'm going for at this point. I was thinking start with Remote Desktop for screen sharing, and Skype for voice. That could provide a baseline experience. Could take things from there and try out other stuff in the future.

Quote
In either case, what is the topic of interest? OP2 programming, or do you have some other thing in mind?

Honestly, at this point I'm more concerned about how to get a session going that what would actually be accomplished. I figure something OPU related would be obvious, but what exactly is kind of arbitrary. Could be working on a new level, hacking OP2, working on a remake project, website updates, extracting game resources, blender, or whatever people have interest in. I'm going to say making an OP2 level would be a nice default project.

Quote
I've done this in the past, but right now would be tough for me. I'm in the process of moving, so my days are chaotic at the moment.
See what you just did there? You expressed interest, but avoided commitment. Why? I'll give you a hint, it likely has nothing to do with moving. That's just the easy surface level excuse. Think what's behind your last question about what will be worked on. Is it perhaps more to do with concerns of not knowing enough, not being able to follow along, wasting someones time, or even just looking stupid? Yes, I just called you out on that. ;)


Quote
Do you mean Pair Programming as described in Agile Software Development? https://en.wikipedia.org/wiki/Pair_programming
Yes, that's exactly what I'm talking about.

Quote
Any other language and it would probably turn into more of a teaching session than me actually contributing.
That is one of the points of pair programming. It spreads information.

Quote
...I think this is different from Pair Programming though since we are all typing code simultaneously. In Pair Programming, only one person is typing, while the other is reviewing/suggesting strategies/planning ahead right?
Correct.

Quote
How long are you thinking for the session? A couple of hours? We should probably pick some sort of topic/goal for it as well though? Maybe something that could be completed at least in rough form in a single session?
I was thinking start with an hour, though maybe leave it open ended in case people want to continue longer. The first session will likely be more about fighting with tools trying to get it all working than actually accomplishing anything. A rough task of creating the start of a new OP2 level might be good.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Remote Pair Programming
« Reply #4 on: May 22, 2017, 06:25:59 PM »
Quote
I've done this in the past, but right now would be tough for me. I'm in the process of moving, so my days are chaotic at the moment.
See what you just did there? You expressed interest, but avoided commitment. Why? I'll give you a hint, it likely has nothing to do with moving. That's just the easy surface level excuse. Think what's behind your last question about what will be worked on. Is it perhaps more to do with concerns of not knowing enough, not being able to follow along, wasting someones time, or even just looking stupid? Yes, I just called you out on that. ;)

Well, I am interested or I wouldn't have replied at all. You did call me out (and that's okay), but I also figure you aren't really interested in all of the excuses in your thread. It's not really that I'm moving but that I'm taking a new job, and moving to another state is part of that. I know my next job is going to be more demanding than my current, but I'm not certain how much more yet. So I'm avoiding commitment because what I DON'T want is to say "yeah, I'm in!" and then disappear for several weeks. Then come back and have no time for side hobbies while I settle into my new job. (In my opinion, that's a bit of a jerk move.) Also, in approximately a week I will be without internet connection for an indefinite amount of time (might be a week, might be a month).

We all only have so many hours available to us. So yes, on some level I'm a bit selfish and I'd like to know what's being worked on before I commit. I value my family and work time above my personal time, so I have to figure out what I'm "not" going to do in order to support another branch to my gaming hobby. Currently I've stopped programming in order to focus on improving my modeling skills. Also, my experiences over the last several years has proven to me that my timezone is often a hurdle. If you look at my user stats, you'll see a very distinct time frame of activity for me (when I'm not working or taking care of the family).

But really, I don't mean to hijack the thread. I am interested in discussing the possibilities of this thread and want to participate in seeing it come to fruition. I just can't give a solid commitment yet. Hopefully that makes sense.

Also, I'm not specifically familiar with "pair programming," but sounds like I might have done some simply in practice without knowing what it was called. Sounds kind of like the goal is that you're more interested in figuring out how to set all that up, and less concerned about the project itself?
« Last Edit: May 23, 2017, 12:36:12 AM by White Claw »

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #5 on: May 22, 2017, 10:33:07 PM »
Why don't we shoot for a 2 hour session for the first one? First hour to get a workflow going and the second hour for actually trying to do the pair programming.

I currently do not have a Linux machine, so would have to be on Windows for me to participate.

I would prefer either VS2015 or VS2017. The bulk of Outpost 2 stuff is already on VS2015, so maybe that makes the most sense? Or we could go with the newer version so it remains relevant longer.

If we stick to the Outpost Universe repository then I guess Subversion makes sense for the revision control. I am comfortable with Mercurial as well.

What about 1-3AM GMT Monday the 29th. That would be Sunday evening US Eastern Time. Not sure what time zone you are in Hooman. I could easily push that several hours later if it helps out?



My idea for the Pair Programming:

I would like to see a utility library for Outpost 2 related non-scenario tasks. Things like

1. Retrieving a list of filenames from a VOL file.
2. Adding a new file to a VOL file.
3. Removing a file from a VOL file.
4. Pulling information from a MAP file like height and width of the map and specific tile IDs.

I know a lot of these problems have been solved in the past, but I don't see their source code in the repository yet. (Maybe I'm just missing it). Basically I would like a library that could be used by Outpost 2 utilities to shorten and simplify their development time. I haven't found solutions to these problems posted in a way that I can digest without major research on my part.

Anyways, maybe we could pick a couple of processes out like processing the MAP or VOL file manipulation and try to write them into the library. I would lean towards the MAP file reading first, but maybe VOL would be easier to start with.

Thoughts? I had another idea if this doesn't sound appealing... Also happy to work on a new scenario as well, we just have to promise to finish it if we start it. :)

Part of my motivation is that I want to write a console program that can read the tiles from a .MAP file, select the proper tile from the BMP sprite sheet and then splice together an image of the map in variable sizes. I currently do not know how to access the data from the MAP file though, so it feels fairly out of reach for me to solve. Having a library that solved these tasks would be very helpful.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #6 on: May 23, 2017, 02:12:43 PM »
@WhiteClaw: All very good reasons, especially the family time! The new job thing is also a big time concern, ... starting next week! Luckily, I'm impatient and want to do something this week. :D

As for time commitment, this doesn't need to be long term. It can be treated as a one-off, lets try this, ok, done.

As for your activity spike in your stats, it shows up as 8pm for me. That's hardly a problem.


@Vagabond: 1-3am GMT works for me, and yes I can do 2 hours. That's 9am-11am in my current time zone. Your activity spike in your stats is 1pm for me. I've marked your time in my calendar, though feel free to update if you chose a slightly inconvenient time thinking I was in a different time zone.

Your project ideas sound excellent. Even better than a new level. I'd actually also wanted to make a utility that can produce scaled images of maps. The VOL and MAP file processing code sounds like a good starter project that would lead into such a project. I also have a few other odd ideas such code could be used for.

I'm currently using Linux, though I've installed a remote desktop client that should allow me to connect to a Windows machine. Probably easiest if you host, though I can look into setting up a Windows virtual machine if you want me to host.

I suggest installing HxD if we're going to do work with binary files. It's an awesome hex editor for Windows. It would allow us to look at the data and understand the format easier, before starting to write code. Optional though.

It might help to do an SVN checkout of the OPU repository. There is code and info in there we can likely pull as reference material.

I'm familiar with SVN and Git. There has been interest in moving stuff over to GitLab or GitHub, so that might be interesting to try, though I'm open to using Mercurial. That would be something new for me to learn. We could even try doing commits to more than one version control system and see what happens. :P

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Remote Pair Programming
« Reply #7 on: May 23, 2017, 07:24:28 PM »
I've been wanting to do this with you since you PM'd me about it a couple of years ago... but I'm also an extreme introvert and am very nervous about using voice chat software. Not because of privacy reasons (don't care about that, i have nothing to hide) but because I'm very awkward and voice chat creates a much more personal connection vs. text chat.

On the flip side, it's a lot easier/faster to convey ideas via voice chat especially when it comes to an activity as difficult as programming.

To relate to another post, I would personally recommend Discord. It works so much better than skype and hangouts and is much, much lighter weight without advertisements and you don't have to install software to use it -- you can use the app through a web browser interface.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #8 on: May 24, 2017, 01:34:02 AM »
Leeor,

If there is a fourth person, we could setup two teams and switch team members for a second session. Or I don't mind bowing out of the first session and then participating in a second session maybe a week later if you want to jump in? I'm certain you can run circles around me in C++. No guarantees my children won't be arguing in the background during part of the session though. Perhaps my wife will be kind and take them out somewhere during the pair programming.


Hooman & Leeor,

Since we are working on Outpost 2 related code, I think it would make sense to push it all into the Outpost Universe Repository using Subversion. If we want to start corporately using GitLab or GitHub, I am happy with that though. Either way, I already have a copy of the repo checked out to my CPU. I'll grab the newest version this weekend.

I just downloaded and installed HxD. It is working opening random files, and seems to let me edit the files. Not sure how to use it gainfully though... If I have some time, I'll try to find a tutorial on using HxD or something in the next couple of days.

Can someone point me to an article or documentation on what you mean by remote desktop client and maybe how it is used in Pair Programming. I've never dealt with anything like this before. I was thinking screen sharing and pushing/pulling code through the repo when switching who is driving for the pair programming. Sounds like Hooman is talking about both people controlling the same computer.



Seems like we agree on making a utility library for Outpost 2 related tasks. I'm thinking C++ (happy to try a different one if desired though). I think programming a utility application is much quicker in C#, but C++ is probably easier for cross platform work and more member of the community have a working knowledge.

We will need some way to test the functions as they are written for the utility library. I'd rather not directly connect the library to an application. We could do 2 projects in the solution, the library and a simple test application project that references the utility library. Maybe the test application could be a simple console application. So you could type things like:

 * ADD Maps01.vol NewMap.map
 * READ Maps01.vol (lists all files in maps01.vol)
 * REMOVE Maps01.vol NewMap.map
 * TILEID NewMap.map 1,1 (returns proper tileset/tileID. not really sure how this is done by OP2)
 * MAPWIDTH NewMap.map (returns width of map in tiles)
 * MAPHEIGHT NewMap.map (returns height of map in tiles)

Nothing necessarily useful for the sample program, just prove the library is working and show a sample of its use. I would probably skip a lot of error handling and other things just to keep it simple, quick, easy to read, and easy to work on.

I'm not crazy about testing this way. Maybe there is a better way to test the library functions though. Unit testing or something else?

What about naming the library OP2Utility?

Also, I'm assuming so far one utility project. Would it make sense to have several smaller projects. Like OP2VolReader and OP2MapUtility instead of one project for all of it?

We should probably consider moving the details of the project into a separate forum thread and leave this thread for discussing the tool chain/dates/pair programming strategy.
« Last Edit: May 24, 2017, 01:35:52 AM by Vagabond »

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Remote Pair Programming
« Reply #9 on: May 24, 2017, 01:43:46 AM »
I don't know anything about the Discord chat, but google hangouts does not require additional software and adverts (at least not in my experience). You just log into google (I use chrome), start a hangout, then pass the link to someone and they can join. I'm not pushing for Hangouts, just saying that it's also web browser capable and pretty much only requires a google account.

I think the best time for me would be somewhere around 6-8am GMT (if I'm doing the math right).

Funny enough, I hadn't really thought about my profile spike time till I started doing the math. The time there actually corresponds to when I initially get home and have a chance to respond to any posts. I don't think it corresponds to when I actually might be free for an hour or so of computer time.

Saturday or Sunday are probably the only days where I might be able to swing something like this. My other evenings are already full. I'm not sure if I'm comfortable with someone remoting into my computer, but screenshare via something like Hangouts or whatever would be doable. Also, I'm quite introverted like Leeor. So I feel your pain there. It can take a little getting used to. I'm fairly comfortable at voice and screen share, but I'm still not a fan of turning on the video.

I'd say that given I don't do much OP coding, maybe it would be more of a point-and-talk to me about where the repo is and all that. Or, if you're interested, we could freestyle some Blender basics, since you were asking about it the other day.

Cheers

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Remote Pair Programming
« Reply #10 on: May 24, 2017, 03:23:51 PM »
I don't know anything about the Discord chat, but google hangouts does not require additional software and adverts (at least not in my experience). You just log into google (I use chrome), start a hangout, then pass the link to someone and they can join. I'm not pushing for Hangouts, just saying that it's also web browser capable and pretty much only requires a google account.

True, but Hangouts has an annoying habit of being flaky when you actually need it to work. I've found discord to be much more reliable in these situations.

Also, I'm quite introverted like Leeor. So I feel your pain there. It can take a little getting used to.

I'm doing my best to try to get over myself. I still find it odd that voice chat over the 'net is so threatening to me. I know I have a tendency to stumble over my own words so it probably comes down to thinking I sound like a bumbling idiot.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #11 on: May 25, 2017, 01:35:29 AM »
Just watched a video on pair programming. Some good info on remote pair programming as well. I think worth the watch if you have 30 minutes. Obvious bias towards pair programming, but we are all here discussing it, so maybe that is appropriate.


The speaker doesn't really see sharing screens and passing the code back and forth as actual pair programming. Passing it back and forth through a repo and not sharing the IDE means a lot of down time and there is a lot of delay to switch who is typing (driving). I think ideally you should be both able to type at the same time. Not that you should type at the same time, just that there isn't any barrier to switching pairs. It is like source code that takes 3 minutes to compile. I start compiling it as least often as possible to avoid the down time. I think the same would happen if you had to commit/push and the pull the code and then switch whose screen is being shared.

I don't have any issues with video sharing on top of the voice sharing. I think video sharing each other's faces is probably the first thing to go if bandwith is an issue. Without audio sharing you would be forced to type everything into chat though which would really defeat the purpose of pair programming anyways.

We could probably save a lot of bandwidth by somehow just sharing the screen contents instead of the pixels. I mean when I type a letter, it sends to the other person's CPU that the letter was typed instead of sending a capture of my screen. This would probably help with the latency too. https://www.quora.com/What-are-the-best-tools-for-remote-pair-programming

I'm sort of swimming in the options right now though. Maybe tomorrow I'll take another look through them. I'm guessing we are looking for a free option. I don't mind paying a nominal fee if a good option requires it.
« Last Edit: May 25, 2017, 01:37:46 AM by Vagabond »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #12 on: May 25, 2017, 05:01:52 PM »
Quote
I've been wanting to do this with you since you PM'd me about it a couple of years ago... but I'm also an extreme introvert and am very nervous about using voice chat software. Not because of privacy reasons (don't care about that, i have nothing to hide) but because I'm very awkward and voice chat creates a much more personal connection vs. text chat.

I know exactly what you mean. I've put off pairing for years due to similar concerns. I'm actually not comfortable with video at this point. That does feel pretty personal. That's one reason why I prefer audio.

I figure audio is a bare minimum. It would be very awkward to share a session with someone you had no verbal communication with. You don't want to type to each other in the code window, and having to tab about to type in a communication window would be weird and slow. Too much context switching, and it takes you out of the code.

I had actually thought of using Discord for this. I want to start with more common tools as a baseline first. Basically I want to convince myself how common tools probably suck, and the lesser known tools provide a much better experience. I figure these other tools exist for a reason, and I want firsthand experience to justify using them.

@Vagabond: We can have multiple sessions. I actually expect multiple sessions. I don't expect more than 2 people at a time. Though that might be interesting to try. Scheduling could be difficult with more people though, and some software might limit to 2 people.

Quote
Not sure how to use it gainfully though... If I have some time, I'll try to find a tutorial on using HxD or something in the next couple of days.
Don't worry about it. I mostly just use it to quickly look at binary data. I don't generally do anything fancy with it. Besides, hex editors tend to be fairly simple tools with not a whole lot of features, so you can just sort of learn it on the spot.


As for Remote Desktop, I may be a bit confused. As I just read, and now vaguely remember, using Remote Desktop will actually log out the local user before logging in the remote user. Not very useful. Instead, use Remote Assistance, which lets both users be logged in at the same time. I also vaguely remember you can enable or disable control for the remote user. I was planning to use Remmina to connect. Not sure if it supports connecting to an existing desktop session such as with Remote Assistance. From what I understand, it's the same underlying protocol.

My idea was to use voice chat, screen sharing, and shared control. The last one could potentially be worked around if voice instructions are clear, though that gets a bit away from the idea of pair programming.

This also simplifies software use somewhat, since it only needs to be installed on one computer.

There are alternatives to screen sharing. I've heard the Cloud9 IDE can link with someone else so updates are visible to both. It's a shared editing environment, but isn't a full desktop environment. It can be a bit faster since it's just keypresses and actions being exchanged between two copies of the software running on both machines, with no need to send images. Not having the shared desktop means you can't share external tools, so it's not quite a full replacement.

We can discuss the specifics of the project during the session, and perhaps just let it evolve as we go. I figure C++ would be a good choice, though I'm open about language. I've dabbled with this idea in D, and also thought about using JavaScript. You can use NodeJS to run JavaScript outside the context of a web browser. NodeJS provides API libraries to access the file system and other such resources, much like any other programming language.

@White Claw: Google Hangouts is one of the options I wanted to try. I've also noticed Google released a Google Chrome plugin for screen sharing. Might be related, I'm not sure.

Quote
I think the best time for me would be somewhere around 6-8am GMT (if I'm doing the math right).
That works out to 2pm-4pm for me. Quite convenient. Weekends are no problem.

I would prefer solutions that don't put the host at risk of funny business. If there is shared keyboard and mouse editing capabilities on a desktop, the possibility would exist for them to go opening strange programs and typing in strange commands, though I would also assume in a shared screen environment the local host would notice this and kill the connection. And also never pair with that person again.

Quote
I'd say that given I don't do much OP coding, maybe it would be more of a point-and-talk to me about where the repo is and all that. Or, if you're interested, we could freestyle some Blender basics, since you were asking about it the other day.
Those are both good ideas.

@leeor_net:
Quote
I'm doing my best to try to get over myself. I still find it odd that voice chat over the 'net is so threatening to me. I know I have a tendency to stumble over my own words so it probably comes down to thinking I sound like a bumbling idiot.
All the more reason to practice with people who won't mind.

@Vagabond: I think I've actually watched the video before. Indeed, there are a lot of resources out there.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Remote Pair Programming
« Reply #13 on: May 25, 2017, 10:05:07 PM »
@Vagabond: Thanks for the video. I will have to check that out (possibly tonight).

@Hooman: I'd be willing to try to give it a go this weekend, but I'm still not certain what my schedule will be on Saturday or Sunday night. This is our last weekend before we move, so we plan on going out and about during the weekend. I suspect I'll be home in the evening, but it's possible we might still be out in town. I'll try to be more "firm" tomorrow. We can meet up in IRC before hand too?

Since it's a "lets try this and see," then perhaps we can do a little bit of both OP code stuff (tutorial for me) and Blender (tutorial for you). Though that might be a lot to try and cram into an hour.
- I'm open to suggestions on where to start on the OP side, and if there's any particular software or whatever that I should install first, let me know and I'll try to get it done before hand. I already have MSVS 2015. I do more C#
- If you want to try Blender, go ahead and install it (if you'd like) and we can figure out what we want to do. If you have a specific goal in mind, let me know. Otherwise I can just run through the introductory basics.

@Leeor: I'm happy either way. I don't get paid by google or anything, it's just what I've used in the past. I've had descent luck with screen share on it, but I've also experienced some issues. Also, we all sound like bumbling idiots, so no problem!   ;D

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #14 on: May 26, 2017, 02:30:42 AM »
I just installed Chrome Remote Desktop. It seemed to be well regarded for pair programming and is free. Unfortunately, I cannot even share my Windows 10 PC with my wife's Windows 10 PC. It will recognize the 2 computers are talking and ask for final verification. When clicking yes, it immediately goes to a text box saying the entered authentication code is invalid. Quick internet search revealed it is a problem for others but no solution. Tried turning off firewalls and running in admin mode on both CPUs to no avail. We are not using any heavy antivirus software either, so not sure where to go with it.

Unless someone has another idea for troubleshooting, I think Chrome Remote Desktop may be out for me. If my wife's machine is the problem, maybe just trying a different machine would work...

https://chrome.google.com/webstore/detail/chrome-remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp?hl=en (Not sure why there needs to be 380 characters on the end of the link? I feel like google should be using cleaner links than this.)

----

I was able to get TeamViewer to connect my wife and my computers together. It has built in chat, audio, and video. The software costs money for commercial use but is free for non-commercial use. A single window popped up at the end of the session saying you are using the free version, do you want to purchase the paid version with something about thanking you for your honesty. All seemed to be fairly tasteful and otherwise without advertisements. Not sure if anyone has any good / bad using TeamViewer before?

It is available for Linux, MAC, and Windows.

https://www.teamviewer.com/en/

----

I looked a little at the built  in RDP (remote desktop protocol) on Windows 10. It is called Remote Desktop Connection App. Played with it a little and was fairly confused. I think if Remmina is set to use RDP protocol, it would in theory be able to talk with it. I would have to sit down and play with it some more before being comfortable going this route. It might be nice because it wouldn't require installing something as heavy as TeamViewer, but definitely more confusing to understand (for me anyways).

----

I already use Discord on occasion. I would be happy using it for voice and chat unless we went with TeamViewer that has both functions built in already. I would prefer it to Skype. I've never tried Google Hangouts, but would be certainly willing to try it out.

----

Seems like video is out for the pairings.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #15 on: May 26, 2017, 04:24:25 PM »
I can try to be around IRC on the weekend.

Mixing OP and Blender stuff would be cool.

Suggested software/setup (depends on what will be done, I'm including some extras):
TortoiseSVN  (most things)
Checkout the OPU repository  (most things)
Microsoft Visual Studio, with C++ compiler installed  (levels, extensions, some utilities)
HxD  (binary file viewing and editing)
OllyDbg  (disassembly/reverse engineering, patching)
Notepad++  (text editor for any coding outside visual studio, possibly web development)
PuTTY  (web server maintenance)

We don't have plans to use the last few, but if someone is interested, those topics can be touched on as well.

I've also installed Chrome Remote Desktop, Team Viewer, Discord, and Skype.

My initial reading on Remmina and Remote Desktop/Remote Assistance sounds like that might not work as I'd hoped.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Remote Pair Programming
« Reply #16 on: May 27, 2017, 02:02:24 AM »
I would just use TeamViewer for screen sharing. It's free for non-commercial use, it has a built in voice and text chat feature and it's about as effective as you can get for this sort of thing. As for bandwidth, that one is difficult -- it has an optimization for speed over quality which gives you a fairly rough image with a lot of jpeg artifacting but it works and only sends the portions of the screen that change though over really slow connections there is some latency. Nothing that can't be overcome though.

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #17 on: May 27, 2017, 08:03:24 PM »
Leeor, thank you for the suggestion on TeamViewer!



Hooman,

All the software choices sound good. I have everything mentioned installed except for PuTTY.

I'm willing to host as discussed earlier. I'll clean my laptop's desktop off today so we can work there without it being super cluttered.

If you are available, we can move up the start time to 2300 GMT on Sunday (2 hours earlier than previously agreed). It would fit a little better for me, but not a problem if you want to stick to the original time.

I'll try to message you on Discord or the Outpost IRC room if you are not on Discord around the start time.

I'll start pushing resolution 1366x778 initially unless you need something else. If lag/video quality is a problem we could try dropping my screen resolution a little and seeing what that does.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #18 on: May 28, 2017, 06:27:19 AM »
Ahh yes, screen resolution. I should mention my cheap, small, portable travel laptop only has a max resolution of 1366x768. Anything more means scrolling or scaling.

I can do 2300 GMT Sunday. That might actually work better this week.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Remote Pair Programming
« Reply #19 on: May 28, 2017, 12:38:44 PM »
@Hooman: I was on last night for about 1.5 hours, then I realized that I probably screwed up. I said Saturday, which for me it was...but it was actually Sunday GMT. Hopefully I didn't leave you hanging. Sorry dude... :-\

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #20 on: May 28, 2017, 12:53:04 PM »
We never really set a specific day or time. I wasn't sure when to expect you. Thinking back, I may have uncharacteristically been sleeping at the time you were likely on.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: Remote Pair Programming
« Reply #21 on: May 28, 2017, 01:58:36 PM »
Hooman sleeping? That is uncharacteristic...  :o

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: Remote Pair Programming
« Reply #22 on: May 28, 2017, 05:12:12 PM »
My thoughts on sleep  :P


On a more serious note though, sorry to have been sleeping at that time. I seem to have had the times mixed up. For some reason I was thinking I needed to be around either early morning or late evening. Also compounded by my poor sleep habits as of late.

Offline White Claw

  • Hero Member
  • *****
  • Posts: 854
Re: Remote Pair Programming
« Reply #23 on: May 29, 2017, 01:30:11 AM »
Yeah, no worries. Looking back at my message, I also see that I wasn't clear at all (it's been a busy couple of days). Maybe we can try to set up another time in the future, though it may be a bit before my schedule is settled. My internet gets turned off in about 36 hours, then I'll only be on mobile to check the forums.

Cheers

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: Remote Pair Programming
« Reply #24 on: May 29, 2017, 02:31:42 AM »
The first pair programming session was a pretty big success. It took us about an hour and a half to slog through the technical details of software setup. and then we probably spent about 2.5 hours split between pair programming and reviewing Outpost 2 internal data.

I had a great time and learned a lot in the process.



Environment Setup Details

Chrome Remote Desktop would not secure a connection between our computers (I think it was on my end, but not sure).

Next we tried TeamViewer. The initial link setup was easy. Screen quality was good and lag was only bothersome when scrolling through a lot of text. (Hooman can speak to the latency better than me since I was the host.) It took us a long time to get audio setup. Hooman could hear me but I couldn't hear him. We eventually tried audio through Discord with TeamViewer. There was an extremely annoying echo in Discord when TeamViewer was on. Turning off TeamViewer and Discord would transmit the audio fine. We eventually got TeamViewer's internal audio function via VoIP to work.

After about 1.5 hours of fiddling, we got it all up and running at 1366x778 resolution without much lag. We live geographically distant from each other, so I was pretty happy with the screen sharing and audio quality. My kids only burst into loud crying once during the session, so it wasn't too embarrassing. :)



Pair Programming Results

We reviewed the info on the repository on how Map files work. (By review, I mean Hooman taught me and then showed me how to use a hex editor, very nice of him). Then we started a C++ console project. The repo contains all the backend code for the map editor. Within this code is a a C++ file for representing and parsing a map file. It is designed as COM compatible and didn't include a couple of the details that have been discovered about the MAP file format since it was created.

We elected to create a new struct to represent the map data. The newer version is be a little easier to read without the COM decoration and uses some more modern C++ features like std::vector. It was also key for me to work through to learn what was going on since I'm not a great C++ programmer. We ended the pair programming session having read most all the data from the MAP file into the MapData struct in C++.

I'm going to spend a little time cleaning up the code and then will post it to the Outpost 2 repository. Need to figure out where we want it in the repo though.



Project Goals

I think where we are going with this is creating a console application that can render images of Outpost 2 maps in different sizes. IE you could render a map at 50% of its normal size. The current map editor only produces the small thumbnails and only in BMP format. I am happy the map editor has the functionality it does, but I would like to see more.

The next step should probably be either gaining access to VOL file contents or mapping tileIDs from the map to their respective tiles on the sprite sheets. There is a file in the OllyDbg section of the repo with a lot of info on the VOL format.

Tentative Project Goals:

* Able to render a map at a custom size in common image formats. Probably at a minimum BMP and PNG or JPEG.
* Able to handle batch rendering of multiple maps if desired.
* Able to read required content out of VOL files to include WELLs, Tile Sets, and Map files.
* Separate the console application from the backend code so if someone ever wanted to create a new Map Editor, they could plug in the imagery code to allow quick rendering of maps in custom sizes and common image formats.
* Try to create a useful library for how to manipulate VOL files and MAP files. I think this may already exist in the old Map Editors code though.

I should probably let Hooman comment if he has any different goals though since it is half his work. And enough rambling for now.