Clicking on the link listed on the jam page takes you to a missing "404" page (https://amaze2021.netlify.app/pdf/Call_Game_Jam_Regulations_fin.pdf%E2%80%8B)
This is the correct link:
https://amaze2021.netlify.app/pdf/Call_Game_Jam_Regulations_fin.pdf
Game Professor
82
Posts
5
Topics
10
Followers
1
Following
A member registered Oct 07, 2020
Recent community posts
The later is closer to how most professional game dev competitions I've judged for are run (PAX10, IndieCade, Game Dev Choice Awards, etc...). The judges all split up the games and then come back to discuss what they liked and to recommend games for various awards. The judges will often then play the suggested games in a second round, but at least every game is guaranteed a fair shot.
Not having any judges play some of the games perpetuates unfair disadvantages that already exist in the ratings. For example, one of the games in this jam is made to be played by people who are blind and intentionally features a blank screen in hard mode. That will likely hurt their rating for "visuals" and could place it further down in the overall ratings. That should not disqualify it from recognition in other areas.
(The best audio in the world could be featured in a crap game, their audio person should still get an award for best audio.)
Additionally, for games with fewer ratings, 1 or 2 people can tank the ratings for what should be a 5-star game. If someone made a game featuring a transgendered character, a couple of transphobic people could intentionally tank the game's ratings out of spite. The number of ratings a game receives is already influenced by things like popularity on YT/Twitch, whether you worked on a team, and whether there is a cute/attractive face on your title card art.
I think if you reach out to your judges about this now, you'll find some of them are likely to agree to split up and play the games that weren't already "selected".
BTW, if you want to learn more about interesting legal stuff from an actual lawyer, here's a channel I respect. He has worked in copyright law (although, increasingly, his channel has been focusing on the insane legal nonsense going on at the federal level). Here is his take on an actual lawsuit about alleged copyright infringement in the video game Fortnite.
Actually, there are many game mechanics which are patented, not just the nemesis system. (NOTE: I've taught classes on game business & law, but nothing in this post constitutes legal advice and I am NOT a lawyer.)
For example, scrolling notes in rhythm games (both horizontally and vertically) was patented. It's why Guitar Hero choose to use the 3D "into the screen" view - to avoid infringement.
The truth is that some companies are simply more likely to enforce their patents than others - and it is unlikely (though not impossible) they will bother to go after a free game in a free game jam. #NotLegalAdvice #NotALawyer
(NOTE: There are "patent troll" firms that chase after everyone they can with over-broad patents and attempt to squeeze money out of companies. They *can* go after individuals, but most will prefer to target businesses instead. That doesn't mean you are in the clear, it just means you could get lucky.)
Now, this is VERY different from violating someone's Copyrighted IP (characters, art, names, logos, sounds, etc). Some companies (*cough*Nintendo*cough*) are VERY litigious when it comes to protecting copyrights.
So, what does this mean for your game? Let's look at an example (Again, #NotLegalAdvice #NotALawyer):
Let's say you wanted to remake the original FF7 for the Atari2600. You CAN take "inspiration" from the concepts and game mechanics.
Random encounters? Yes.
Similar enemies and power arrangements? Yup.
Exploring themes from the overall plot? You bet!
A hot-tub scene with "jokes" about sexual assault? Um, please don't, but...technically, yes.
BUT - name your main character "Cloud", use their music, or have your character look like him? Now one of my industry friends has to send you a very, VERY unhappy letter. =(
As a professional game dev who has judged many of these types of events over the past decade, I would like to advocate for following the growing trend of allowing continuous updating after the deadline.
The incentive to "get it right the first time" still exists as entrants are likely to get more ratings early on and they will be higher if the game they submitted is of high-quality from the start. Plus, this approach also has some important upsides:
1) It encourages post-jam interaction and feedback since commenters can see their suggestions implemented in real-time (which fosters a sense of community).
2) It rewards developers who stay engaged with their audience and do the hard work to incorporate feedback and create updates. (This is a CRUTIAL skill in the commercial world of game development. When's the last time you saw a game without a patch release?)
3) It results in better games which, in my experience, makes it easier for us professionals to judge these kinds of games and makes our feedback more useful. (It doesn't help when all we do is point out something the dev already knows is a problem but simply wasn't allowed to fix.)
4) There will always be bugs you aren't aware of until a game is released into the wild. Different people have access to different devices and use them differently. Giving devs a chance to fix these bugs is more "fair" because they had no way of knowing about these bugs unless they had access to these devices. (Thus disadvantaging devs from less affluent backgrounds and solo devs.)
5) Having hard deadlines propagates the "crunch" work ethic that continues to plague our industry. (It's better when you can submit as is, get some sleep, and come back to fix the bug post-release.)
Giving a game jam a "hard deadline" was a practice born out of necessity. We didn't have the tools to do otherwise. Now that we have the tools to move to "soft deadlines" - absent a material prize - I think that is generally the best system for everyone.
Thank you.
Climate Jam 2021 - Hosted by IndieCade and Lab-X by the NAS community · Created a new topic Additional Free Resources
I was looking at the IndieCade resource page (https://www.indiecade.com/climate-jam/resources/) and noticed a few key resources that were missing.
2D Tools:
Inkscape - vector art software (free open source alternative to illustrator) https://inkscape.org
GIMP - photo manipulation (free open source alternative to photoshop) https://www.gimp.org
Paint.Net - Like MS Paint, but all grown-up (free) https://www.getpaint.net
Audio Tools:
BeepBox - Digital Audio Workstation/DAW (free open source online) https://www.beepbox.co
LMMS - Digital Audio Workstation/DAW (free open source) https://lmms.io
CakeWalk - Digital Audio Workstation/DAW (free professional) https://www.bandlab.com/products/cakewalk
First, I don't know anything about the Indian game job market, so everything I'm going to talk about relates to the US game job market.
Second, there is a HUGE difference between working for a large AAA company and a small indie studio. Indies do whatever suits them and the hiring process is often based on friendships more than credentials. So I'm going to focus on the topic of getting your first game dev job at a large company.
===========
It is important to realize that any industry changes over time and either a job's status (pay, clout) diminishes or the barrier to entry requirements will escalate. This is because careers perceived to be "good jobs" are the ones people flock to. More applicants means hiring managers can be more picky and demand increasing levels of qualifications. With that in mind, I'll go over what I've seen from various generations of first time devs and where I see requirements going now. (Here I'm using the term "generation" very loosely as some of these changes occurred over a few years rather than decades.)
The first gen of game devs often didn't need either professional experience or academic credentials to get hired - just an ability to do the job. I've met plenty of veterans from this era who had no formal training and were completely self-taught.
The next gen was required to show at least some form of either professional experience or academic credentials, but it didn't necessarily have to be game-specific. I've known devs with degrees in fields as diverse as child psychology, Russian lit, and sports medicine. As long as they could code and had a degree, they were good. This is also when professional coders from non-game fields had an easy time shifting into game dev without any game dev experience.
The next gen was generally expected to have a degree in a related field (physics would be considered "related" because it is STEM and they often write code to run experiments, but you would mostly likely be funneled into a job as the "physics engine programmer"). At this point, professional coders had to start showing that they had worked on something game-related, even if just on their own time.
The next gen was where things started to get heated. You were expected to have a degree in a related STEM field AND show some experience working on a game. This was the era of pushing everyone into making "mods" and building portfolios - even if you were a professional coder from a non-game industry.
The next gen was where hiring requirements got TOUGH. As an entry-level dev, you were often expected to get a degree in either comp sci or a game dev specific degree, AND you had to go to the "right" school. Some companies would throw away any entry-level resumes of graduates from colleges they had "blacklisted". (Colleges I frequently saw blacklisted included Full Sail, the various "Art Institutes", DeVry, ITT Tech, and some state colleges. BUT that doesn't mean you couldn't get a job at other studios with these degrees and typically no one cares about your degree once you have professional experience.) Meanwhile, some companies would ONLY hire entry-level devs from specific colleges or had arrangements with certain colleges to funnel the "best" students from those institutions into their entry level positions. (Colleges I've seen attain this status include MIT, Digipen, Stanford, University of Washington [UW], and UC Irvine.) Additionally, you were expected to have a "portfolio" of game projects to show (which was usually your class work). A workaround at the time was to make your own game and release it as an app so you could claim to have "professional" experience - even if it didn't make any money. Professionals from outside the game industry had a very hard time crossing over and, when they did mange to break in, they were often expected to take a serious reduction in both seniority and pay. (I've heard hiring managers claim they preferred to hire new grads over outside professionals with more than 3 yrs experience because it supposedly required "extra work" to un-train "bad habits" they may have picked up from working outside of games. This made it especially hard for veterans to break in, even with stellar credentials.)
Right now, there is this on-going debate as to whether or not it has become necessary to have a degree specifically in "game dev" or "game design" rather than just a general degree in comp sci or a STEM field. Increasingly, colleges and universities are offering game-specific degrees and the game industry increasingly needs entry-level devs to have more specific knowledge than general degrees offer. (Many University comp sci programs rely heavily on scripting languages and don't teach C++ or core concepts like writing memory managers.) Even for companies that don't intentionally give preferential treatment to certain colleges, I've seen many of them joke that they are beginning to fill their ranks with graduates from places like Digipen simply because those "game degree" graduates are more likely to have the skills the studio is looking for.
Either way, having a portfolio of games you made is necessary to get a dev job in the industry. But it is no longer sufficient to simply release a game into the world and call it "professional experience". Now you generally can't get away with that unless you can show decent download/play stats, you got some media buzz, or you actually started a company and can show you turned at least a small profit.
Parting Notes:
1) Realize that "breaking in" doesn't guarantee you a good career. This is a volitile industry and many devs leave in the first 1-5 years. Most devs will find themselves out of work at some points in their early career, sometimes for 1-2 years. You have to prepare yourself for that.
2) These are just generalities. Everyone is unique and has their own path in this industry. I've known devs who were out of work for years and now are senior devs at top-tier studios working on award-winning projects. Being dedicated, deliberate in your actions, and smart about your career can get you almost anywhere (issues of social bias and discrimination are still a major factor that can limit someone's ability to rise up in this industry).
Brackeys Game Jam 2021.1 community · Posted in I started learning Godot this year as my first engine! Any other first timers !
Tip 1: For whatever engine you are using, look up tutorials on YouTube. That's a great place to start!
Tip 2: As a beginner, I suggest working on a game that is VERY simple (something you *think* you can complete in 1-2 days) and make it in the same genre as the tutorials you are following. For beginners, it is easier to innovate on the micro-level (eg: tweaking how the gameplay feels) then to innovate on the macro (eg: creating new mechanics or genres). Once you are more experienced, you can challenge yourself to implement new and more unique ideas!
Tip 3: In English, you would be properly refer to yourself as a "programmer" or "coder", not a "programmist". (I know English can be arbitrary and confusing at times.)
Good luck!
This would depend on a lot of factors - what engine you are using, how you set up the controls, etc. Regardless, you'll need to have some kind of "switching" mechanism - an action the player can take to perform the switch (examples: press the space bar, click a button on the HUD, maneuver the character to perform an in game action, etc). Whatever this "switch" is should kick off an event that perform the control switch. One easy way to do this would involve swapping a Boolean flag (eg: isPlayerOneMoving = not isPlayerOneMoving), then use that Boolean to control what each controller inputs does.
Example:
OnSpaceBar_Pressed():
if (isPlayerOneMoving):
PlayerOne.jump()
else:
PlayerTwo.jump()
GODOT is my favorite engine. It's great for 2D and has a lot of great free extensions and templates you can use!
Languages: C# or GDscript (basically python-lite)
==========
GDEVELOP is useful if you are a complete beginner or don't know how to code. (It's like Construct, but free and open source).
Languages: Event-based, no real coding
==========
UNREAL is best for 3D. But exporting an asset-heavy build can take hours to a whole day. (Keep that in mind when scheduling your time.)
Languages: C++ or "Blueprints"
==========
UNITY...is like the in-between. It's less powerful than Unreal, but doesn't force you to either recompile the engine or use visual scripting. It's more complicated than Godot, but has better 3D capabilites. Unity has a lot of tutorials and *can* be good for collaboration (sometimes...when it feels like it). If you go with Unity, just make sure everyone is using the same version and tell everyone NOT to upgrade during the jam. (Sorry, I'm not a fan of Unity.)
Languages: C#
==========
And if you can't code or make art, you can use:
TWINE is an open source engine to make interactive stories. No code or art required! (Though you *can* do both as it loads straight to HTML.)
Languages: None required, HTML or CSS optional
There are different terms, but sometimes it is called a "cutout animation".
Here is a video tutorial: (www.youtube.com/watch?v=lMFuEc1XsOQ)
Haha! Yeah, this is a bit like doing IT or teaching, but everyone is a whole lot nicer. ;)
On animating:
If you are using the "split" art method (which is just a version of the "paper doll" method), you wouldn't generally change the art color during animations. Like, when you walk across the room, your clothes don't change color. And since setting modulate/self-modulate sets it for the node, if you are using an "animated sprite" node, all images in that animation would be colored the same.
Like, if you had a fully-colored animated baby character, you might have separate art for the face, hair, mouth eye whites, irises, pupils, arms, legs, shirt, and diaper. Each of these would be their own sprite node with their own color and you then can use an "animation player" to move each piece separately.
Does that all make sense? If not, I can try to make some images to show what I mean.
Heartbeast also has a video on the program "Tilesetter" (which has a free "lite" version). This can help you generate tile sets like he uses.
Here's that video: (www.youtube.com/watch?v=SI3mZ3ynrTw)
A few quick notes about tiles in Godot:
1) This configuration is only ONE way to do tiles. There are other formats Godot supports which can accomplish different effects (eg: animated tiles, randomized tiles [think of having 4 different "grass" tiles with slightly different images randomly placed to break up the repetition], etc.) You decide which tile configuration is best for your project (or your project's current layer).
2) Sadly, Godot doesn't have the most user friendly (or most powerful) tile mapping system. Thankfully, you can create tile map layers in other programs and import them into Godot. Good example: (www.youtube.com/watch?v=jFq4Eve_Db8)
3) Be aware that there is an issue in Godot's tilemaps where tiles may "flicker" on systems with Nvidia cards. You can fix this by sticking with GLES2, under Project > Project Settings > Rendering > Quality > 2D > enable both "Use Pixel Snap" and "use Nvidia Rect Flicker Workaround" by making sure the little check boxes are checked.
There are two ways you can handle this:
With Shaders: If you follow the shader tutorial I posted, you can simply create a new set of gradients using your new color palette (or change the gradient you were already using). If using the gradient doesn't work for you, there is a LOT of "shader magic" you can do in Godot, and one option is to simply preset colors right in your shader code (or as an exported parameter) and just change your colors there.
With Modulate: You can do the "split" art method and just set up a Singleton of color references (either as individual variables or in a dictionary), and adjust your color references as need be. I've never personally changed colors quite so drastically as shifting from a green to bubblegum palette, but I am likely to decide that I don't like the shade of green I'm using and change it accordingly.
If you are being very limited with your palette (like only using 4 colors), then you could name your color variables by function (eg: shadow, highlight, midtone, background, etc.) I normally label mine as the colors they are (MyGreen, MyRed, MyBlue, etc.)
Does this help?
Apparently, Unreal is planning to release a GDScript-like scripting language. (I'm really looking forward to that because recompiling the entire engine just to avoid Blueprints is an absolute pain and I REEEEEEALLY don't care for visual scripting. Personal Preference.)
C++ is a bit of a pain (I hate writing memory managers), I like C# much better! And using it is definitely one of the reasons Unity took off in the early days. (And GDScript is really just a stripped down version of Python, so I've taught it to people as a gentle step into scripting languages.)
That said, I would encourage anyone who wants to go into AAA development to learn C++ simply because there are a lot of jobs out there looking for that skillset - and it is getting harder to find, which makes it more valuable. It is the backbone of both Unreal and many major titles (World of Warcraft, for example). I tell my students that I recommend any game programmer (again, who wants to work for a major studio) should learn at least 1 scripting language, C#, and C++. Knowing all of those means you can pretty much learn any coding language thrown at you.
But in the end, I feel like picking a language (or even an engine) is a lot like picking a fashion style. There may be some job requirements you have to deal with, but on your own time you should go with what feels comfortable for YOU.
Happy to help!
On Art:
For 2D games, load a sprite node and click on it in your "Scene" tab. Look at your "Inspector" tab under "CanvasItem". You'll see an item labeled "Visibility". Click on the arrow to expand it and you'll see 2 color bars named "Modulate" and "Self-Modulate". Changing the colors of these changes the color of the entire sprite. (If you have a complex bit of sprite art, you can split this into different pieces and make each one a different color.) I find this works really well for simple sprites. Also, if you change the "modulate" color of a node, it will change the color of all its child nodes!
You can set this at runtime with
"$MyNode.self_modulate = WhateverColorYouAssign"
For more complex sprites, you can use a gradient shader. Here's a full tutorial on how to do just that:
(www.youtube.com/watch?v=i7VljTl4I3w)
There are times you may wish to use both a shader AND self-modulate/modulate. Try playing with it!
Also, I like to tween the alpha channel of self-modulate/modulate in order to make things vanish!
I'm SO glad you have biz-dev experience! Most of the time, that is not something indies know much about and it is what ends up hurting them the most.
There are a couple of GDC talks about indie game marketing that you can search for online (www.youtube.com/watch?v=uy0Dfr-mnUY)
That said, one of the problems with any marketing info is that it often feels like "survivorship bias" (it worked for me, but ignore the 600 people who tried it and failed). If you have the funds and lack the interest, I'd recommend just hiring someone.
Maybe once the pandemic is over, I'll see you at industry events talking about your success! =)
As soon as you said "global Singleton" and "signal" I went, "Oh, a fellow Godot user!"
While these concepts exist elsewhere, they are not as commonly referenced in game dev - but they are staples in Godot.
Here is a random collection of tips and thoughts on how I organize things in Godot (my fav engine):
SINGLETONS:
Personally, I've been increasing my use of global singletons for optimization purposes. (For example, I use them for my audio library so I don't have to search everywhere to find a sound effect.) This also helps me front load some parts of my games at more appropriate times (like during menus) so my framerates don't drop.
I always have a "GLOBAL" script that holds certain library functions I want everything to have access to (like playing audio). My global singleton holds references to key nodes that I set upon loading. For example, I use "var CAMERA" in the global singleton and then the ready function in my Camera's script starts with "GLOBAL.CAMERA = self". This way, anything can easily reference the camera with "GLOBAL.CAMERA" without having to waste time referencing the tree root or figuring out how far down the tree I set my camera. I can move my camera up or down my tree during dev time and it will always be findable at runtime.
Other items I have done this with include: HUD, PLAYER, CURRENT_LEVEL, and DATABASE...
SIGNALS:
I like using the built-in signals, but for a lot of things, custom signals can make things harder to manage. I know it isn't the "preferred" way to do things in Godot, but I don't mind tightly coupling some things even though it reduces reusability. There are a lot of tradeoffs in coding: readability, speed, efficiency, reusability... We all have to choose what we want to prioritize with each script we write. For game mechanics, reusability isn't my highest priority. (That said, I have a growing folder called "Utilities" that I generally just copy-paste from one project to the next. So for *some* things I care about reusability.)
SUBNODE REFERENCES:
Anytime I want to reference a sub node in a script (eg: a sprite); I will create an onready variable at the top of the script.
"onready var MySprite = $sprEnemy"
Then I use the variable (eg: MySprite) in place of referencing with the "$". This way, if I later move or rename the subnode (which I do a LOT), I only need to change its reference once. Also, I use a consistent naming convention for both subnodes and subnode references (eg: the sprite for something is ALWAYS labeled as "MySprite"). This way, there is never any question what is being referenced and it makes script reuse easier.
LABELING:
I also recommend being mindful about folder use and naming conventions. In my current project, I have a folder called "Enemies" and everything in there has a name that starts with "Enemy_". I also have a folder named "Levels" and every item starts with "Level_" or in some projects "lvl". Personally, I prefer to keep my scripts in the same folder as my scenes rather than make one HUGE folder labeled "Scripts".
Use subfolders! Under my Assets folder I have sub-folders labeled "UI", "Audio", "Fonts", "Shaders", and "Art". Under "Art" I usually have subfolders like Enemies, NPCs, Player, Background, etc. Under "Audio" I have "SFX" and "Music" separated. I prefer to name my assets with what they are "red_spaceship_coneshape.png" rather than how they are intended to be used "level1_bkg_music.ogg" because I might change my mind about how it is to be used later.
ART:
As often as possible, I like to use black & white art assets and color them in using either shaders or the self-modulate function. this allows me to shift color pallets on the fly. I'll even have colors named in my GLOBAL script "MyBlue = Color(#41d7d7)" and then reference them "set_blink(GLOBAL.MyRed, GLOBAL.MyBlue)" for things like hit effects.
ANIMATIONS:
Tweens are your friend. Not really an organizational tip, just a fact.
First: Good for you! Learning code is ALWAYS a good thing. (I'm really curious what your "small period course" is.)
Second: When it comes to game dev, "hard coding" isn't always a bad thing. (I do it sometimes.) This industry...has a history of "hacking" together code. With the exception of massively multiplayer games, we generally aren't making games that are intended to withstand the test of time. Most games only have a shelf-life of a few months before it ends up in the "budget" bin and everyone has moved on to the next thing. Financially, we are perversely incentivized to NOT have our games last because we can sell "upgraded" or "remastered" versions later.
That said, if you want to be a AAA coder, I recommend getting into a good college. Digipen, MIT, Stanford, USC - that sort of thing. But even a decent state college can teach you what you need to be a better coder. But look for a school that includes both C++ and at least one "scripting" language in their curriculum (python, lua, etc).
As to how to code better, I'd need a bit more detail about where you are in your coding journey. What languages are you using? Do you know the main principles of coding (Variables, loops, conditionals, functions, etc...)? Or are you struggling with things like inheritance and using lists vs queues?
One rule of thumb I will give: generally the only "hard coded" numbers you should ever use are 0,1, & 2.
For any other number, 99.9% of the time you will want to set it as a variable at the top of your class/function.
Example of a bad use of "hard coding" a number:
for (x=0; x < 150; x++)
Here the number 150 is a "magic number" because it isn't obvious why you wrote it. Maybe that is how many enemies you plan to have on screen. But what if you decide that is too many, or too few? You'll have to search through all your code to find and change the number.
Here's what it should look like:
max_enemies = 150
for (x=0; x < max_enemies; x++)
Here you are still using 0 as a starter number for your counter. This is generally fine. But 150 is no longer a "magic number".
Does this mean I NEVER hard code numbers other than 0, 1, or 2? No, I do it sometimes. But 9 out of 10 times, I end up regretting it.
Freesound.org
OpenGameArt.org
Or - make your own!
Audacity (https://www.audacityteam.org)
LMMS (https://lmms.io)
BeepBox (just Google it, Itch won't let me post the link for some reason)
First: Thank you! I'm glad my advice is helping! =)
Second: the issue you described impacts EVERYBODY. (I'm doing this right now instead of working on my game...*whistles*)
There is a saying in game dev: "When you are 90% done, you only have the last 90% to go!" Making a game functional (you can play it under OPTIMAL circumstances) is very different from making a game usable (your entire audience can play it under most circumstances). I think the shift from functional to usable is where a lot of motivation for game dev goes in the trash. For many, they feel the "fun" parts are now done. Few people are as motivated to do bug fixes and menus as they are making cool game mechanics.
Also, while hindsight is 20/20 and it is always easier to do something a second time, there is a time and place to redo/rewrite/restructure code. (I've worked as a code optimizer, so I really get this impulse.) The important thing is to determine if the effort to "redo" something is going to make the rest of your project go smoother (or make important improvements to your project's file size/frame rate) or is it just an impulse based on a lack of confidence in your dev ability. If the former, it may be worth the effort to rework as much as is necessary. If the later, well...
The best thing you can do is create a milestone schedule for yourself and try to stick to that. This will keep you focused on what you NEED to get done. If you determine that redoing your code *is* necessary, then you can budget this in to your schedule. Sometimes seeing how much time you have to add to your schedule is enough to discourage yourself from doing it unnecessarily.
I've heard some indies talk about different ways to motivate themselves through the "slog" of completing a big game project. Some rely on encouragement from friends or other devs. Some use a personal reward/punishment system. (I once heard of a dev writing a substantial donation check to a group he loathed - I think the KKK - and giving it to his friend with instructions to mail the check if he hadn't completed his game by a certain deadline.) Less drastically, I've heard of indies setting up press-related events as motivation to meet a deadline. Others simply challenge themselves to meet arbitrary milestone deadlines. I've also heard of devs rewarding themselves with purchases they want. What motivates you, personally, is a very individual thing.
Please let me know if you want more info or were looking for something different.
Ah, the engine question. First off, I think different engines are better suited for different needs and you should work with whatever you feel works best for you, your team, and your project. I'll go over my personal opinions of my top 4.
GODOT:
Godot is actually my personal favorite engine and the one I generally prefer to work in. I like that I am not beholden to corporate restrictions; it has a wide range of platform portability; and because it is 100% open source, I can easily modify it to suit the needs of whatever project I'm working on. I also think Godot is the best engine for professional 2D game dev. I think all of these advantages (plus it being 100% free) will help it take off in the 2D indie community.
UNREAL:
If you want to make a AAA (or AA) 3D game, it will probably be done in Unreal. (In fact, demand for Unreal skills are projected to go up by around 140% in the next year or so.) Recently, Unreal appears to be putting a LOT of effort into attracting indies and mid-sized studios (probably in a move to push the Epic store). In addition to increasingly great free asset giveaways, they have increased the amount you can earn before having to pay ANY engine royalties to $1million!
GDEVELOP:
For someone doesn’t know how to code and wants to learn game dev, this is a GREAT option! In fact, I’ve used this engine to teach game development to kids. It’s also great for throwing together quick prototypes and game jams. It’s similar to Construct (or to a lesser extent, GameMaker) but 100% free and open source.
UNITY:
I’ll talk about Unity’s pros in a moment, but you should know that while I think Unity’s ubiquity makes it necessary to know if you are a pro, I strongly dislike it.
I think (for now) Unity is a bit better for 3D game dev than Godot, and (for now) a bit easier to use than Unreal. BUT…I think Unreal is coming for them in the 3D space and Godot is coming for them in the 2D space. That combined with some infuriating recent decisions they’ve made solely to drive increased revenue for their IPO move…and, well…
For right now, Unity is solidly embedded in our industry due to years of great PR/marketing (and some hefty government grants). Many colleges teach Unity and many studios use it because it is what the incoming talent knows…which leads to college teaching it because it is an “in demand” skill.
BUT - I think that could change quickly as more studio heads become aware of Godot as a viable “free” alternative for smaller indie projects (studio heads and publishers are notoriously cheap). The AAA world already pushes Unreal, so medium-sized studios that want to appear AAA will likely jump on that train.
***************TL;DR: I won’t be buying any Unity stocks.
First, learning ANY skill is valuable - PERIOD. This is especially true as a designer. We need to have a broad range of experiences and knowledge to draw on in order to create "new" ideas.
Second, game designers who can code is a HIGHLY sought after dev type. They are usually called "scripters", but some studios consider them a type of "level designer". And even if you don't decide to take a position where you code professionally, being able to throw together a playable demo/prototype of an idea/mechanic will make it easier to convince others that your idea is viable (or prove to you that it is not and drop/change it).
My degree is in coding and I started as a professional designer, so don't think it hurts you to have this skill set! These days, I've also learned to make art, music, and sound effects. I'm currently working on improving my animation skills. I've also learned management and bis-dev skills. No learning ever goes to waste.
That said, it does help to *market* yourself as a narrow expert and always tailor your resumes/applications to show yourself off as the "expert" in whatever position you are applying for!
Sure! I've actually created and sold a tech startup and helped tons of indie devs.
Can someone theoretically make it as a solo dev? Sure. Whether or not being an indie dev is viable for YOU is the real question.
1) Indie Dev == Running a Business
So, the first thing to keep in mind is that being a dev involves a completely different skillset from running a business. Some people are happy doing both, some hate it.
A game studio - whether a whole team or just 1 person - still has certain requirements. Marketing, Accounting/Taxes, and Handling Legal Contracts are all a part of any business. When it comes to making a game, you have game programming, game design, art & animation, UI/UX design, sound effects, music... There are those rare people out there who have all these skills, but most people will have to hire, subcontract, or pay for pre-existing items. That requires recruitment, knowing local/state/federal laws, and managing payments. (For example, California's new "AB5" law turned a lot of freelancers into employees who are entitled to full benefits.) At the VERY least, you should work with a lawyer to ensure you aren't breaking any laws. I also recommend using an outside accountant.
2) Know Your Audience
Old business adage: If you are making a product "for everyone", you are making a product for NO ONE.
Even professional studios sometimes drop the ball on this. You have to know who your target audience is, how to reach them, and what will attract them to your game. If you wouldn't play your own game, you probably won't know enough about target audience to reach them. (This is why diversity is so important.)
Also, understand the state of the market you are targeting. If it is too saturated, you'll need to work harder to stand out from the crowd. This is why a lot of people get discouraged and think they "can't" succeed. You aren't going to succeed as a solo indie if you are directly competing with Disney/Activision/EA/Tencent. This is why I highly recommend you stay on top of industry business news (not just gamer news). Most of us rely on www.gamasutra.com to see what business deals and trends are happening. The key to any business's success is identifying a significant and underserved market.
3) Manage Your Schedule
It is easy to fall behind and get discouraged while working solo. Create a schedule and milestone list. This will help you to stay focused when you REALLY don't want to work on your project anymore.
4) Test, Test, TEST!
Get as many people as possible to try your game on as many of your target systems as possible. I had a colleague joke once that when we launched we'd discover that our game didn't work on computers that were grey. It was a joke on the fact that post-launch you will find your game breaks in the most bizarre ways and times.
Also remember that you are the expert of your own game, others aren't. They will play in ways you have never considered. Games are a form of communication, so you won't know if you are communicating correctly until people with 0 knowledge of your game try it for the first time. (As soon as they have tried it or had it explained to them in any way, they are "tainted" as a "fresh" playtester. So don't tell them anything on their first playthrough and get as many people as possible to be "fresh" playtesters.
Final Note:
Not knowing your personal background, this is just a collection of some of the most common points people need to learn. I'm happy to answer more specific questions if you have any.
I use Inkscape. 100% free vector art program makes things SUPER easy!
https://inkscape.org
Let's start by identifying a few specifics:
1) In what way do you think your coding is "rubbish"? Is your code non-functional? Is it messy/spaghetti code? Are you having a hard time figuring out how to organize your code?
2) What are your goals in terms of coding? Are you trying to implement complex mechanics? Make your code more readable/manageable? Understand certain concepts? Make it less error prone? Debug faster? Crash less?
Git Gud.
Ok, that's not terribly helpful, so here's a more nuanced version:
1) Have an online portfolio and make it as AMAZING as possible! Don't put up everything you've done, only the BEST of what you've done. Good isn't good enough, great isn't good enough - only AMAZING gets to stay. People will remember you by the WORST thing you presented.
2) Have a LinkedIn profile and keep it updated. Recruiters are increasingly relying solely on this to find prospective employees. (Not entry levels yet, but that could change in the future.)
3) About 85% of all game dev jobs are staffed by internal references. So join professional networking events. Look for meetings with your local IGDA (International Game Developers Association). Many of these meetings are online during the pandemic, so you have a chance to start networking from home! Also, join game dev forums, chat groups, Discords, etc. Remember that networking isn't about begging people to give you a job. Rule of Thumb: You aren't networking today for a job tomorrow, you are networking today for a job 3 years from now.
4) Also, "git gud" - continue to improve your skills in whatever area of game dev you want to work in. If you have no portfolio, work with other indies on side projects. If you are a coder, contribute to open source projects. If you are an artist, volunteer to make art for local non-profits, community groups, or school/community/religious events (you can also do icons for open source projects). If you are a producer type, volunteer to do the grunt work for an open source project or volunteer to run something for a local/community/non-profit group. If you are a sound/music person, contribute to OpenGameArt or work with a voice actor to take a public domain book and make an AMAZING audio recording of it with sound effects and music then put it up on LibriVox. THESE ARE RESUME AND PORTFOLIO PIECES!
Professional studio announcement timeline:
@E3: We're releasing in time for Christmas. @Christmas: We're releasing this Spring. @Spring: We're releasing this Summer.
@E3: We're releasing in time for Christmas...
-----------------------------------
How to schedule a game:
Also, before the jam starts, make a schedule listing EVERYTHING you need for a game:
Gameplay, Art, Sound Effects, Music, UI, Tutorials, Menus, Level Design, etc.
Now figure out how many hours you have to make your game. (In this jam, 168hrs.)
From that number, subtract all the hours you need to live (sleeping/work/eating/bathroom/etc...) [See next tip for help here.]
Take that remaining number and cut it in half.
Divide the time you have left among the items I listed above. (Give more time to unfamiliar tasks and remember that "searching for pre-existing art/sounds/music" can take as long as making it yourself.)
------------------------------------
Here's a trick I've had my students try: Tonight, make a list of EVERYTHING you will spend time on the next day (including sleeping, checking email, work/homework, social media/internet browsing, eating, bathroom breaks, gaming, chatting with friends, chores, showering, brushing your teeth, etc.) For each of these activities, write down a guess of how much time you will spend doing it.
The next day, as you are about to do something (like go to the bathroom) write down the time you are starting. When you are finished (or switch tasks) write down the time you stop. (For items that you do multiple times, list each start-stop pairing.) When the day is over, add up all the time you spent on each item and compare it to how long it ACTUALLY took to how long you THOUGHT it would take. This gives you a basis for estimating how far off your time management guesses are. Chances are, you'll be close on some routine items (like brushing your teeth) and WAY off for items that are unusual, highly variable, or new to you.
Now judge your personal experience making games. Is this closer to being "routine" or is it a "new" skill for you? That should help you figure out how far off your time judgements are for making games.
If game dev is a newer thing for you, I recommend (for this jam) aiming to make a game you can COMPLETE in 1 day-2 days. That gives you more room for error.
This ^ is a great description!
I will add that "object.instantiate" has several options that you can specify: position, rotation, parent. If you only set a parent parameter - without setting position/rotation - you can also set "instantiateInWorldSpace" to "true" to set the object relative to "world space" or set "false" to set the object relative to the parent's position.
Also, know that when setting Quaternion.Euler you can either pass a Vector3 object or the individual coordinates (x, y, z).
[Unless, of course, Unity decides to randomly change their fundamental features in a future update for absolutely no reason...again.]
If you are using Unity for this jam, my #1 advice is to pick a version and stick with it. Don't update even if they release a new version during the jam. (Updating an out-of-house engine mid-project has cost many studios a lot of lost time - sometimes days, sometimes a week or two; but I have known projects that lost months to this!)
Hello all!
I saw there are a lot of beginners here and, before the jam starts, I just wanted to offer to share my experience and knowledge to answer any questions you might have about game design/development in general. (I'm not affiliated with the hosts, so I can't answer questions specific to this game jam in particular.) I'm a professional game developer/designer (I have worked for top-tier studios on AAA titles and major franchises). I have also taught game design and development for various respected institutions.
I'll answer what I can before the game jam begins (I also have a job to do making games ^_-).
Cheers!