dylanstrategie - Coder/Mapper Application

[dylanstrategie]

Byond ID: dylanstrategie

Age: 19

Gender: Male

How would you define yourself? (Coder, Mapper, Spriter): Started out as Mapper two years ago, and still proficient as that. Got a lot of Coder experience during that time, really sharpened up in the last year or so, to the point of knowing my way around everything except really heavy system stuff like ZAS or some of the datums. Oldcode isn't pretty too, most of the time.

If Coder, what languages? DM nearly exclusively.

Any previous experience developing with SS13? Two years of mapping and coding in total for a public server branched from Bay codebase. From beginner tweaks to more daring projects as I gained experience.

Proof of any previous or current work: https://github.com/dylanstrategie contains a proof of my pretty significant work in the last year (478 contributions recorded as of posting this). Over the year before that, even more, although intensified this year give or take a few months.

How well do you know Git? I use Git CLI, I know my ways around all common commands, from the very basic commit-push structure, to updating repo, basic rebasing, unstaging commits, etc. I have Git Worflow down too, making forks and opening PRs.

Your primary job is server development, not policing the server. You may be given Moderator-level of access but you should *not* be invoking any administrative actions unless there are no moderators or Admins online. Do you understand? (Yes/No) Yes, I get that. I'd be part of staff, but not supposed to take administrative actions unless no-one is around to assist.

Anything else you'd like to add? I'd like to disclose immediately that I'm still a basic codermin (mostly moderator tier) on another server. I'm not supposed to show up around the clock here, so this wouldn't break my availability. As for risk of bias, I feel capable of handling players who are rulebreaking no matter what server they come from, although I doubt I'll be doing a lot of administration as a developer here

[Feweh]

In a funny way, what really worries me is you had to ahelp asking where applications for dev was because you couldnt find it on our forums.

[dylanstrategie]

I recall ahelping about a few things, but I'm pretty sure I found the dev apps by myself. Are you sure that was me ?

[freemysoul]

Two posts and literally joined the forums today. So I've just checked your notes and I'm seeing NO notes which are a good sign, From my knowledge on VB, CSS and HTML your coding looks solid though more along the lines of debugging. My personal problem here is your a new player (From what I can see), I'd say play on the server for another month and get known before reapplying.

However I have no real power over who joins the Dev team.

[forwardslashN]

Thanks for showing interest. I'd like to know why you're specifically interested in coding for CM, and why you think you would be a good addition to the team. Aside from that, what would you say is your most daring coding project and what have you learned from it? Id's also like for you to think of a single game feature that you really like and explain why, and then how you would improve that feature if given the opportunity.

[dylanstrategie]

I am mostly interested of coding for Colonial Marines because I really like how the server puts a novel spin on Space Station 13, and the Aliens theme certainly fits well within its framework. From the general station maintenance, the more complex systems that SS13 integrates like atmospherics (although not used intensively on this server, as of current) to the redshirt experience the Marines tend to get due to the semi-complex health system, even the specifics of the interface and player interaction that makes using your gear just complex and slow enough to not feel like a superhero at all times.

I believe I can be a good addition to the team because I have both lots of general experience and a bit of expertise in Mapping (enough to write a wiki guide, otherwise enough to undertake significant projects like completely fixing a map's piping to remove pipes under walls, or redoing entire areas) and Coding (most likely still not enough to take on very tough systems like ZAS, the Powernet, complex datum systems like the controllers, etc. But otherwise, I've done enough work in all categories to know my way around, from simple bugfixes, runtime investigations and value tweaking to completely overhauling how items work or making things from scratch)

Other than that, I firmly believe that as long as a coder respects an absolute minimum of coding quality (extremely basic things like absolute pathing, respecting the project's case, and avoiding wonky workarounds because oldcode is not pretty to look at already), is willing to learn coding if they are still novice, and works in tandem with the rest of the team, it's better to be with them than without. Everyone works on SS13 for free, so it's not as much of a conventional developing experience as freelance contributions towards a project. Only expense to have more coders is that the repository and task management becomes harder.

I think that my most daring coding project has to be an attempt to rework a mostly obsolete gamemode, Meteors, into something that could be played and not just used as admin punishment. In all senses of the word really, not everyone was a fan of a survival holdout gamemode with no player antags, it took a LOT of background technical work and optimizations (fixing explosions so they don't lag horribly notably) and the scope of reworking an entire gamemode is massive (and still unfinished to this day). I've learned a lot from it however. Understanding of gameplay flow on a general SS13 server and what players expect from the round (interactivity, agency, near-constant events and a degree of challenge), some of the more nitty gritty stuff like performance and optimization (it took a long while to slam hundreds of meteors into a station per minute without tetanizing amounts of lag) and how to handle value tweaking and player feedback, especially if there was a technical problem and feedback is more hectic than usual.

As far as game features that I like go, there's a lot of features and facets of gameplay integrated into SS13 that are always interesting to work with, but if I had to pick a single one on Colonial Marines, I would say that the way xenomorphs and marines detect eachother caught my attention the most recently. Right now, Xenomorphs just straight up see all humans in view (albeit that's how NVGs have always worked, inbuilt sight flags are pretty awful) while Marines have zero ingame ways to track down xenomorphs outside of direct sight or basic flushing maneuvers in tight corridors. The way Marines and Xenomorphs encounter eachother is important for the entire round's gameplay, and adding both ways of detecting enemies and bypassing this detection increases the tension and general paranoia of the round.

I think I could improve that system, given a bit of luck with sight flags (in short, bypassing them and adding a new system). Maybe taking some inspiration from Alien: Isolation and making it so Xenomorphs still have perfect night vision (they do have very sharp senses according to lore) but can't see people through walls unless they do something inherently noisy or visible. Moving at full pace, interacting with objects, obviously making noise through breaking stuff, firing weapons or talking. On the other hand, if they are stationary and silent, only direct sight would work. This would make for interesting strategies for both Survivors and small Marine divisions, without breaking the main use of Xenomorph sight which is having a general idea of where the loud guys with the big guns are, even without direct sight on them.

On the other hand, Marines could get their motion tracker. A clunky device that takes up a full hand and pings in a range, but that can only spot moving threats (in sorts, kinda like Xenomorphs, minus the night vision and sound detection), allowing Marines to get a tell of Xenomorphs moving in on them unless they are stationary or potentially in Stalk (Walk) mode, which Xenomorphs never are currently. Of course, the major downside of the item would be that sporting a motion tracker makes you a moving, obvious beacon that pings regularly when a Xeno is nearby, which can doom you and your squad if you're trying to scout. And it's not 100 % reliable if the Xenomorphs are smart.

[forwardslashN]

Interesting response. I've been thinking on how to rework sight, and given than 510 introduced PLANE_MASTER, it is a distinct possibility. Can you tell me how you went about optimizing the meteor code to not lag the station? Doesn't have to be detailed, just curious. Efficiency is something I always keep in mind when working on CM, as we have a lot of action on screen, and we need to balance that around existing mechanics.

[Sailor Dave]

The thing with the motion tracker is that we did have one for a little while that worked almost exactly as you described, but it was quite laggy. I'd like to see a different approach to it, as the method I used wasn't very efficient, even if it looked impressive. If you feel like you're interested in tackling the issue, I could show you how I set it up and perhaps we could come up with a solid alternative.

[dylanstrategie]

Interesting response. I've been thinking on how to rework sight, and given than 510 introduced PLANE_MASTER, it is a distinct possibility. Can you tell me how you went about optimizing the meteor code to not lag the station? Doesn't have to be detailed, just curious. Efficiency is something I always keep in mind when working on CM, as we have a lot of action on screen, and we need to balance that around existing mechanics.

Optimizing Meteors code took two things. The most obvious thing was "fixing" explosions, although this wasn't done by me but another coder contributing. Simply, instead of using BYOND's inbuilt range procs that can start lagging horribly once you enter the double digits, he used a special spiral block proc that, as its name implies, goes through tiles in an outwards spiral. This might sound irrelevant, but it had a brutal effect on how long bombs take to process. I believe the way they're set up now, the server is perfectly capable of taking "terminal" admin explosions (500 dev) with "only" a 10 to 15 second hang. 10 devs only skip a second's worth of frames, bigger bombs vary but still scales exponentially past a certain threshold.

After that, there was another very weird cause for lag. Even with the explosion proc sanitized, having a ton of explosions at once, even relatively small, caused a hang. And I noticed after some investigation that meteors simply crashed into eachother and exploded, or chained explosions, a lot. For the sake of simplicity, I made meteors pass through eachother and ignore explosions, and this pretty much eliminated virtually all remaining lag (although there's still a slower refresh if playing above cinematic FPS) by both allowing me to use a lot less meteors to the same destructive effects and staggering explosions as much as possible to avoid stacking calculations. All of this with really minimal gameplay effects.

[forwardslashN]

I have sent you a test via PM, all instructions included.

[SnipeDragon]

We could use a mapper with coding knowledge at the moment, it would be nice if you were able to work with the mappers on their projects directly.

Based on your responses so far, if you are still interested, I'll give my +1.

[SecretStamos (Joshuu)]

I really like your answers. You seem very serious about this.

[dylanstrategie]

I'm still interested

Also yeah, kind of the reason I started coding is so I could supplement my mapping

[apophis775]

Ok, I've talked over this with dev staff, and we are going to accept you. Please PM me as soon as you can to get added to the Git and the Slack.

[dylanstrategie]

Alright, I've noticed it and I have sent a PM on my end. Should be set up soon hopefully