Great question!

First and foremost, try to avoid games that are "asset heavy": RPGs, RTS, MMOs, Metroidvanias, CCGs, SIMs, MOBAs, Adventure Games, Management/Tycoon games. Also avoid multiplayer or networked games, anything requiring good AI, and specialty equipment like ARGS or VR. If this is your first game, I also recommend AVOIDING a game with an explicit story (unless you are doing a text/graphics-based interactive novel game in Twine or Ren-Py where the whole game IS a story. In which case, keep it BRIEF). If you do include a story, the entire script should be readable in under 3mins.

Instead, focus on games that are more "system" focused: Puzzles, board/dice/solitaire, simple shooters, platformers, casino games, simple physics games (angry birds/flappy bird/breakout), tower defense, music/rhythm, simple farming, infinite runners, beat-em ups, and physics-based sports (bowling, golf, pool).

I recommend making an explicit schedule (I make one in Google spreadsheets). Make sure you factor in things like people's jobs/schooling, sleep, and other life requirements to figure out how many hours you have available for development. Then, cut the number of available hours in HALF. You want to plan as if you were making a game in just the first 2-3 days, then let the rest of the time be for bug fixes, polish, testing, menus, tutorial creation, sudden life requirements, and coverage for under-estimating how long something will take you.

Split your time between Design/Level Design, Coding, Art, and SFX/Music. But schedule more time for coding and things you are weaker on and try to minimize the impact of stuff you don't know how to do or don't care about. (Eg: Don't make a music game if you don't know how (or care about learning) to write music.)

IF YOU HAVE A TEAM:
Factor in extra time for communication. Make sure your team agrees on how to stay in contact (email, Discord, Texts, etc). I recommend having someone in charge of setting up a Trello board that breaks down everyone's tasks. Also be sure to setup an agreed upon way to easily share files (Dropbox, GitHub, etc). If you have dedicated teammates for assets (art/sound/music) obviously they will make the assets, but the designer/producer needs to help them breakdown how much time to spend on each asset or level.

IF YOU ARE GOING SOLO:
I'd recommend dedicating 4hrs on design, 2 days on coding/dev, 12hrs on art, and 6hrs on sound. If your game needs dialog writing, databases, or level design work; add another 2-4 hours for each.

EITHER WAY:
Consider your personal/team's strengths and weaknesses. If you are an artist or art-heavy team, you'll probably need MUCH longer to figure out the code than to pump out assets - so your game should be extremely simple and pretty. If you are a coder/code-heavy team, you may want to focus on a creating cool mechanics and reduce your art to basic shapes with fun shaders.

Good luck!

It is 2 weeks  not 1 week

Good question!

Without knowing what system you are using, I'll speak in generalities using an example. Pick-ups are little more than pretty event triggers for doing some mechanic in the game (add points to a score, increase health, add or switch a weapon, replenish bullets, increment a goal object number, etc...)

Let's assume you want to have a pick-up item for a shotgun. Let's also assume that picking up a new weapon occurs when you walk into a floating pick-up icon of that item. Upon triggering the pick-up, it immediately adds the new weapon to your player's weapon inventory and switches to that weapon.

First, implement the shotgun mechanic, the inventory system, and the ability to switch weapons.

Next, create your pick-up indicator (like a floating icon image of the shotgun). Add a collision box to the icon and place it in the level. Setup a trigger so that when someone collides with the pick-up, it will:
 - 1) check to see if the weapon is already in your inventory
 - 2) if not, add the weapon to your inventory
 - 3) switch to the newly added weapon
 - 4) delete the pick-up (unless you want it to remain, like a health/bullet recharge station or save point)

Pick-ups are ideal items to make as a one generic thing with a variable or flag that sets which item it is a pick-up for. (Just check your flag to set which icon/sprite to use.)

ENGINE SPECIFIC IMPLEMENTATION:
Unity: Here's an example of implementing this in Unity:

Glad to answer this:

It depends on what kind of job you are looking for, what kind of studios you are considering, and what your background is.

I always recommend any newbie get involved with their local IGDA chapter. (https://igda.org/) Don't expect this to land you a job directly, rather use it meet other devs and learn the layout of the local dev scene. I used to Chair my local chapter.

Keep in mind 3 things: 1) Game studio jobs are some of the most sought-after positions in the world. 2) Studies have shown that 80-90% of industry hires go to someone who is personally connected to someone at the studio. 3) Many devs experience joblessness for a year or more at the start of their career, meaning that you may be competing with experienced professionals even for entry-level positions.

For entry level positions, small indie studios might be more willing to take a chance on a newbie; but a large studio is more likely to have slots for someone. Still, some studios have explicit relationships with major colleges to fill their internship/entry-level positions. Some simply prefer to hire from 1 or more specific programs due to having found high-quality hires there before. Sadly, some studios will also blacklist graduates for negative past hiring experiences. (From what I've seen, FullSail and The Art Institutes are on a number of blacklists, while MIT and Digipen are on a number of preferred hire lists.)

The hardest jobs to get are those in design, writing, and art (possibly also music, but I'm not as familiar with that area). The easiest position to get is a job programming tools, as a technical artist, or doing network programming. I'll try to breakdown the various job types.

Writers generally need to have succeeded in another medium (books, movies, TV, or game design). The exception to this is if you are willing to do the drudge work writing "barks" or if you can land an entry-level job doing missions/quests for an MMO/giant free-to-play.

Game Designer is the single most sought-after, and least understood, position. You need to have a portfolio for this, what goes in it depends on whether you want to be a level designer, combat designer, UX designer, or another kind of designer. Sadly, there is also a lot more room for discrimination here. Studios will "niche down" to distinguish hiring a third-person sci-fi stealth action game designer from a first-person sci-fi stealth action game designer; but if its an IP intended to target women or kids, suddenly ANYBODY is fine in the role. (Seriously, I've seen a studio hire someone who said they didn't know what a game designer is but thought "it sounds fun" and made them the lead designer for a game targeting females.) You should learn how to work in Unity, Unreal, and Godot (because it is up-and-coming and makes you look good for understanding it). For some reason, being a designer for a sports title used to stigmatize you so you could only work on sports titles after that, not sure if this is still the case. Designers are the most likely to be out of work, so its best to have a solid fall-back skill (like coding, art, or writing).

Artists have to be AMAZING at their craft and have a KILLER professional portfolio. For some reason, 99.9999% of artists want to be "concept artists", so next to no one gets to be one. I've been told the easiest job to get in art is as a UI artist. Apparently, very few people like doing that. If you specialize in 3D art/animation; learn in Blender, but download and get used to the experience in Maya. Learn Photoshop no matter what.

Game Music/SFX artists are rarely hired in-house. When they are, they have a track-record for success elsewhere. I know next to nothing about freelance or contract music/SFX.

Programmers are the ones most often called "devs". If you want to get a job as a coder/dev, learn C++, C#, Python, Java, and get comfortable with both Unity and Unreal. It seems like 85% of coders want to be "gameplay" programmers, so that's a hard role to get. Tools, database, and network programming jobs are easier to land; but you'll likely be stuck doing that for the rest of your career. Build-up a portfolio by contributing to open source projects on GitHub.

Producer/Project Management - learn SCRUM and AGILE. Full stop. If you haven't doing this professionally for another tech company, expect this to be a difficult junior position to land. This SHOULD go without saying, but be aware of the culture you are developing. Be open and welcoming to people of ALL genders, races, religions, game preferences, etc. We have seen plenty of producers and leads properly ousted for harassment, we don't need more toxic harassers.

Tester jobs can lead to other jobs at a studio, while senior and lead testers can make a decent living. At the entry-level, these are often filled by new graduates from university CompSci departments and students from specialty programs (like Digipen). You should learn to at least read code in python, C#, C++. Get used to Unity and contribute to open source projects on GitHub. Learn to write solid bug and reproduction reports.

Community Management / Social Media jobs are often heavily sought after, but are more likely to exist at studios with large multiplayer or networked games. I'm not really up on this.

Here's a couple of useful resources:
https://www.gameindustrycareerguide.com/about/start-your-career-in-video-game-de...
(This is THE place for insider-industry news aimed at devs.)
https://www.gamasutra.com/

Good Luck and feel free to ask any follow-ups!

10 minutes. 30 tops.

But keep in mind, there are 2k+ participants and the average attention span is less than 9 seconds, so get to the "cool parts" as FAST as you can! =)

Thank you! 

And I love your Dr. Zoidberg pic! ;)

I can take a stab at it. Feel free to post your code in reply or email it to me if you prefer.
I'm heading to bed, but I can look at it tomorrow.

You are right to focus on mood via sound design here. Scary/creepy/anxiety-focused games rely heavily on sound to illicit those feelings in your players.

The easiest way to start is by listing out all the "moments" or mechanics your game needs sound effects for. Possible Examples: Footsteps, creaking doors, getting pick-ups, burning fire, building items, destruction/explosions, eating, attack sounds, breathing, leveling-up, etc. Part of good sound design is deciding what needs to be heard and what doesn't, or when something needs to be heard.

Sound effects can achieve 2 things: 1) inform the player of a state change, 2) illicit mood. Great sound design can achieve both simultaneously. For example, imagine your game has a mechanic where the player can freeze to death at night. Every evening, there is a heat bar that fills up if the player gets close to a camp fire and slowly empties the longer a player wanders away from his/her heat source. In that case, you may want your player to hear the crackling sound of fire whenever a player gets close enough to a camp fire to effect his heat bar, and have the sound effect fade the further away she/he/they gets. You might also decide to replace that fire sound with a chilling wind sound to indicate they have wandered too far from their heat source. Without this gameplay mechanic, the crackling fire might be too insignificant to warrant a dedicated sound effect and you may decide that the only time you hear a fire is when you set one so the player can keep their focus to other important sounds.

After you have listed all the sound "moments" that your game needs, start thinking about what emotions or impressions you want to evoke in each instance. For example, when getting a pick-up item you could do the classic gamey thing of using a happy ding/chirp/boop that alerts the player something good has happened, but that might not fit your mood (unless you want it to provide a "hope in the dark" moment). Instead, you might use the sound of, say, fabric rustling to evoke the sense of your player stuffing the item in their pocket or a backpack. Or you might use different sound effects for each pick-up item. A bullet or weapon pick-up might trigger a gun cocking or loading sound, while picking-up food might trigger a munching sound (if you eat it right away) or the sound of your player saying something like "Mmmmm" to remind the player of how hungry they are supposed to be.

If you are going to make your own music, look for instruments that fit the mood you want. This can inspire the way you move forward. Here's a famous example of a horror "instrument" that could provide some inspiration (heavy on the reverb).

Cool. You have a solid base for a potentially good shooter game here. Let's start with a few important notes:

1) There doesn't currently appear to be a difference between the various "enemy" shapes, which can be a bit confusing. Players are used to different sprites/enemies indicating a mechanical difference they need to react to. (Eg: differing attack types, differing health/attack strengths, differing speeds, etc.) Each of these differences should require the player to employ different attack/defense strategies in order to keep the game feeling varied and fun.

If these differences already exist in the game, it wasn't clear/obvious; so consider how else you can communicate this information to the player and/or make these differences more exaggerated.

If they don't already exist, consider adding differences to each enemy so it forces your player to change up their tactics. Also, don't add differences at random, consider how various differences will practically impact a player's strategy. Then only add ones that make for fun and interesting strategies. Trade-offs are great for this! (Eg: Small & fast enemies are easier to kill, but more likely to damage you; while big & slow enemies take longer but could do more damage to you. So the player has to consider which to go after first.)

2) It doesn't feel like there is an explicit goal for the player to accomplish (other than avoid failing/dying). Think of adding some kind of clear goal to accomplish, such as: survive a "wave" of enemies (then rest and heal-up for the next wave), traverse an area to get to a goal, protect another object(s) in the area, collect something, etc.

3) There is very weak "feedback" to players for what the actions they are taking (Good or Bad) in the game. This feedback is sometimes called "game feel" or "game juice". I'll link to some resources below for more information on this.

Once you have these 3 items nailed down, not only will you have a really satisfying game experience but designing a boss fight should be easier because the boss will simply be a ramped-up challenge of the existing strategies/mechanics already in play. 

And if nothing else comes to mind: make your boss HUGE, let them give/take LOTS of damage, and have them release very small/fast minions you have to get through at the same time.

(Also, the quit button on the pause menu isn't currently working.)

I hope this helps! Please feel free to ask any follow-up questions.

Here are a few resources on "Game Feel":

What is Game Feel:

There are a few ways to do this depending on what the other "something" is that you are checking for and how you intend to use it.

Something to keep in mind - unless you are doing a physics-based game (like angry birds or breakout), you probably don't want to use a RigidBody. If you are making a game that needs a RigidBody, it is often better to simply put your collision detection code on the non-RigidBody object. (Eg: In a "Breakout" clone, have the StaticBody blocks detect when they are hit by a RigidBody ball, rather than having the ball detect when it hits a block.)

If you are sure you want to use the RigidBody's collision detection to detect when it has collided with other BODIES (not Area2Ds), then you can simply check "Contact Monitor" for the RigidBody and set its "Contacts Reported" to a number higher than 0 (I recommend 1, but no more than 3 or 4). Then you can use the RigidBody's "body_entered" signal from the node tab.

To check if it collided with a specific item, you can use either "is_in_group() or "extends".

Examples: 

func _on_MyRigidBody_body_entered(body: Node) -> void:
     if body.is_in_group("Bullet"):
        #code for being shot by a bullet

If you want to detect AREAS as well as BODIES, another option is to simply wrap an Area2D that around your RigidBody (though the Area2D's collision shape has to be OUTSIDE the Rigidbody's collision shape). Then you can use the Area2D's "on enter" signals to detect when the RigidBody has collided with something. This is especially useful for when you want to have an early notification range. (Think of how Peggle slows down and zooms in when a shot attempts to hit the final peg...you can reproduce that effect by wrapping a large Area2D around either the ball or peg and have it kick off the effect if there is only one peg remaining.) 

A final option is use Raycasts, but there can be problems with this approach. 
https://kidscancode.org/blog/2018/03/godot3_visibility_raycasts

Here are a couple of useful videos related to this subject. Though neither provides a very straight-forward answer to your question, it might help if you run into problems as this can be a fairly complicated space to navigate.

Under COVID, remote work has exploded. I don't have access to any specific statistics, but almost everyone I know is working remote right now. Here's an article from this summer talking about it: https://venturebeat.com/2020/06/12/how-the-pandemic-has-transformed-work-in-the-...

What I do know, is that many people are already expressing a desire to continue doing remote work after the pandemic is over. Some want to be 100% remote and others want a healthy mixture so they can still spend time with their coworkers. (Personally, I wanted to be 100% remote LOOOOONG before COVID happened.)

Sorry, I'm not sure what you mean by "job platforms". Do you mean which positions work remote (ie: do coders work remote and sound designers work in studio)? Are you asking what remote software people use on the job (ie: Slack, Zoom, Discord)? Or did you mean something else?