Hello everybody, I’m EntranceJew. Today, through the power of the internet, we’re going to make games together. For reference, I make games like these:
about:jew
When I’m not working my day or side jobs to provide funding and equipment for members of my studio, I’m probably making games. When I’m not making games, I’m probably thinking about making games. I’ve been doing this for 4 or so years, but I’ve been trying to make games my entire life. I learned to program because I wanted to make games and websites, but I ended up doing web development professionally. Overall, I’m pretty frustrated with the lack of games being made in the world. Even more so, I’m frustrated by the number of people that want to make games but aren’t. That’s why I’m here to fix that.
about:thread
I’m going to be going through the steps necessary to become good at making games, not just starting them. I want people to be able to go through this thread and develop the skills that I obtained. I am still not a one-man studio, I still rely on friends in order to complete certain aspects of my games, or even to consult because I do actually run out of ideas. Everybody that posts is welcome to make suggestions and/or contributions. If you are not interested in making games, then this thread might serve at least some entertainment value in seeing how everyone’s suggestions and contributions get used. Those could be yours! The thread will have many text posts but will also have videos or scheduled interactive streams.
I will be using Unity to make games, maybe at some point in this thread we will explore other technologies but I am going to start with Unity because I am still supporting some things in it. Unity uses C# as its primary language, and with the magic of compilers, it means you can make games for nearly any platform that’s still supported for free. If you are interested in the toolchain I use, you can read some outdated posts on my blog that I will eventually cover again here as things come up. I will admit that Unity has its fair share of pain points that I will belabor to you all. There will be blood.
If every tutorial out there is like giving you the spoils of a hunt that is shaped most like the game you want to make and then six months later not having any idea what that meat even tasted like, then this thread should be thought of as teaching you to hunt by learning what the game you want to make tastes like, smells like, how to find where it lives, how to track it, and how to deliver the killing blow.
Shut Up And Jam
If you are wondering “what would be be best for making my dream game?” then the only answer I have for you is: “it doesn’t matter, you need to fuck up making a game like 8 times before you have enough bruises, scrapes, and cuts to teach you not to chase your every whim”. That sounds a little mean, but I mean it. If you don’t know how to finish a game then you will never be able to make a game with everything you want inside it. Your first crayon drawing is going to be shit. Your first game will be shit. Your second game might be shit too. There is no guarantee that your games will ever not be shit. But you’ll be making them. Plural. More than one. Hopefully, if you make enough of them, at least one of them might not be shit before you die.
Starting Off
After spending a lot of years of watching myself and others be too timid to take risks, too shy to put themselves out there, and not putting themselves in the spotlight to fail. We’re going to start this thread with a simple lesson on making a small game, quickly. For reference, here are several games that I made in one night with a self-imposed time limit on each of them:
A couple of key points that I have observed myself:
I learned that I make games more efficiently when I can write the code before I have any graphics accompanying it, this goes in hand with:
I was able to complete games the quickest the longer I had thought about what each game would be composed of. The clearer an image I had of what the game would look and play like, the more finishing the game became just following instructions in my head until I was done.
I learned that the task I do the worst at is implementing 2D art.
The games that were least complete suffered from fixation on a particular aspect about them, even giving up and changing that design often cost me too much time to finish in time.
After making a couple microgames, I was able to assess which microgames had technology that would be valuable to implementing a new game’s design.
Even though I was familiar with the technology I often had to google terms that I was less familiar with in order to find out more about them. This is common.
Sometimes, even though I believe my best skill is programming, I fail to stop and consider what is happening and end up wasting more time by not fully assessing the situation. I waste time with desperation and blind stabs in the dark when I could have taken a more measured approach.
Sometimes, I learned something making a completely different game in a smaller, safer environment, that gave me the skills that I needed to go back and actually complete a game in a new 30 minute window.
But how do you convert ideas to games? Prototyping.
Each of these games has only two factors in common:
You can manipulate the game via some form of input.
The games have a victory condition.
If these games were microgames in a WarioWare style game, their third point would be:
Each game has a lose condition: time (implicit)
First you need something that you can control. Is it a platforming character? Is it a car? Do you not directly control something, and instead exert influence on something? How?
That how is exactly what we need before we start. We need a means of controlling the game before we can create a condition for victory. You can’t sink a hoop without a ball and coordination, your player generally won’t find a game fun if it didn’t require skills and the mechanisms provided to beat it.
Prototyping is making an ugly but functional example of your concept. Your prototype is complete when you have a shape representing one thing interacting and changing the visual state of another thing. How that is accomplished is defined strictly by your game.
For some games this means your: platformer character needs rules for moving around and an area to move within; your car needs handling and acceleration; the things that you interact with need to be find-able and provide feedback to being interacted with.
Your game should feel fun before you can lose it. You shouldn’t ever think of how to punish the player before you have figured out how to reward them, and more importantly, make the game itself rewarding. If you’re familiar with Pavlov or Skinner, then you might know that while they have their merits, punishment is generally less well received than traditional reinforcement.
Study The Masters
A lot of the time when you are making games you will need to look to others for inspiration or guidance, it is a skill to be able to meaningfully disassemble other games into concepts and traits that you can understand and utilize. Weigh their value, determine the purpose, and make a judgement as to whether or not it fits in with your design goals, and not whether it can be made to fit in your game without these considerations.
In the game Super Mario Brothers, they made coins pretty and make a nice noise and give you points so that you would collect them. When you collect the coin, you are going closer to the goal post. When the player is learning to collect coins, they are learning how to move their character in a way that is rewarding. They are being Positively Reinforced to pick up coins. On a greater scale, they are learning that wherever coins are, there is a way for them to get to. The gameplay is reinforcing mastery of the controls by providing rewards for simply platforming to places. I am leaving out some aspects of Super Mario Brothers, clearly, to highlight a point, but we can come back to that. The same point goes for Super Mario 64, where stars are your ultimate reward for exerting mastery of the platforming, which you are usually lead to by coins. A level is a means of exerting mastery by creating different conditions to operate in.
Halo 2 is defined by moving and shooting, and to make this feel good you see and hear your weapons when they’re in use. You observe the decals left on terrain when you miss. You listen to moans of pain when you hit your enemy, and you watch them flinch and soon tumble lifelessly to the ground. Shooting is fun because you have things to shoot. Moving is fun because you are made to move in order to shoot enemies that take cover. Grunts exist to have something to shoot at while moving closer to your goal.
Buttons feel good because they do something when you touch them. Pianos are fun because they make noises when you touch them. So too, must your games be rewarding while playing them and not just when they are done. Actions, reactions, the whole nine yards.
When do we make games, then?
RIGHT NOW! I gave you everything you need to start thinking about games in ways you may not have been thinking about them before, and hopefully your mind is stewing on some of that information. Now, in order to elaborate on some of that information, I’ll need your input: Think of a small game, one that is as simple as one in the video above, then post a breakdown in this format:
* **WHO**: what you control
* **WHAT**: what the controls are
* **HOW**: what the controls allow you to achieve
* **WHY**: why doing the thing is rewarding
I will be picking a few of these breakdowns and then creating microgames out of them to illustrate how any idea can be made into a game. If anyone is inclined, posting things like transparent graphics, backgrounds, short song snippets, sound effects are all encouraged. Even partial breakdowns can be accepted, as long as you highlight what part of a breakdown it is, e.g.: just the WHAT or just the WHO. It invites more input.
I also would like to see people making their own microgames! If you follow along in the thread, then simply completing a few of thesefourunitytutorials will give you enough skills to implement any games you come up with, even if you don’t quite get how they all fit together. If you do decide to follow along, post your progress in screenshots or short videos! Tell other people what you like about what they’ve done.
at county college back in 2016 my team made a Windows Console Hangman game for Intro to C++
By my team, I mean we did alot of planning work and then one of my team members said “Yeah I was bored this weekend so I did the whole thing”
I did some unity tuts back in the day before I got my current developer job. i’d like to get back into learning C# at least - database development, as it turns out, lets you forget alot of object-oriented concepts.
I support this, making games is tons of fun. I’ve not had a huge amount of success finishing projects, but that’s the thing I’m trying to improve most at the moment.
https://itch.io/jam/gbjam-5/rate/90028 is my only finished solo game so far - it was built using LUA and Love2D, which is a great simple game framework to pick up if you’re familiar with code to an extent and want to rapidly build something.
EDIT: An idea
WHO: A cat
WHAT: Knocking stuff off a shelf
HOW: Using your mouse to swing your paw
I don’t really have a why - do you mean why in a game sense (why your character is doing things) or why in a player sense (why your player is encouraged to do those things in-game)?
When I first learned to program, I was using basic Python 2.3 tutorials. I had a lot of fun but I did not ever get what I want to have happen. I had tried making games in Flash before but I could not grasp ActionScript 2.0 very well. Shortly thereafter I took an interest in showing people my progress and what I’m up to. It was actually the process of getting feedback and doing more interesting and complex things that hooked me on what I was doing. This will come back up later, but the short version is that I found new and creative ways to fail to make a game every year for seven years after that.
I personally wish that games and databases actually got along a lot better than they do now. As it stands, most game frameworks do not consider it a priority to provide a means of talking to a DB, which means people do not get to consider how their data relates or the similarities between normalized tables and their classes, and how relationships form from that. The concept of database normalization and the consideration of types and their usages / pain points in transforming them will actually help you to learn.
C# does have a feature called LINQ where you can use to perform SQL style queries on regular data structures, but much like real databases, you have to use them in small doses and appropriate contexts for games.
De Video Games, Son
I had to fill in the blanks here with some of my outside knowledge, but you’re pretty on the mark. What I meant for WHY was: Why is the player encouraged to do these things outside of the aspect of them being a requirement? In other words, the WHY is the equal and opposite measure to the WHAT in terms of fun.
For example, you may not find mowing the lawn fun. Your parents, on the other hand, insist that you do it or else you’ll get grounded. Depending on the person, this is not a great motivator. However, even the idea of being paid an allowance in exchange for mowing the lawn, is not very motivating either. Having a dollar is not fun.
But if we take the sage advice from Homer Simpson’s inner voice:
“Money can be exchanged for goods and services.”
So to reformat your suggestion:
WHO: A cat
WHAT: Knocking stuff off a shelf
HOW: Using your mouse to swing your paw
WHY: Breaking stuff into little pieces is fun.
OH YEAH, WARIO TIME
The killing blow! We did it!
We knock stuff off the shelves, because the payoff of breaking them or otherwise disfiguring them is fun! We feel empowered when the environment responds to our actions! The reason we enjoy Asshole Physics is that we can:
See the spectacle of the ordinary behaving in ways that are somewhat exaggerated or otherwise extraordinary.
Hear the object clanking and making noises as it hits other things or breaks.
Simulate the sensation of weight, breaking, or other tactile responses.
We just broke into the motherlode of fun! There are many other similar concepts we can extract from this principal vein when it comes to juice and polish, or otherwise enhancing the gameplay we designed.
By this point, we have gone beyond simply having an idea. Having a good idea is not enough to start. Not eating fast food for every meal of your day is a good idea, but somehow difficult for some. Because you cannot overcome an impulse without a strategy. You cannot counter the inevitability of giving up at your first roadblock without a means of forcing it to not happen. Ideas cannot be realized without a means of actualizing them. As Datarock once said: If you want to whip me into shape \ I need a plan or a mission.
VISUALIZE IT
Okay, we already did the hard work of nailing down the most important parts of the game. We have not yet considered how this will look. There are multiple ways that you can make these things happen. Depending on your skill level, you might go for more or less complicated means of satisfying our requirements. The easiest way to get past this block is to just keep sketching things until you can visualize every aspect of your requirements. DO NOT TRY TO MAKE GAME-READY ASSETS OUT THE GATE! If your silent sense of perfectionism is the primary saboteur to your success, then trick them by telling them it’s just temporary. The only thing you need to do is jot down enough to communicate what we need done. In our case, we’re communicating to ourselves. Giving us a vital concrete point of reference for when we get lost.
By: EntranceJew, Age: 24
Well, we certainly won’t be pitching this to any studios (other than my own) so no worries here. The most important part is that we’ve isolated the gameplay elements:
Moving the cursor moves a cat’s paw.
The cat’s paw moves things when they are touched.
When things move off shelves, they fall.
When things hit the ground, they break.
Woo! That was exciting. But where does that leave us? Oh, right.
Remember when I said we were going to learn how to hunt? Well, we just made our grocery list. A thing that hunters use. The true survivalists out there know what I’m talking about. War is hell.
I want it I need it (need it)
By this point I’m going to pretend like the only thing I know about Unity is how to open it and that I have Visual Studio installed. It is to our advantage to have done the tutorials I mentioned earlier, but I am going to feign ignorance to illustrate a valuable skill.
Like everything we’ve ever done on a computer, we’re going to perform a series of gestures and incantations in a special order so that we can open up new doorways for ourselves.
TIP 1: every image of a search query will be clickable, and have alt text, for the actual thing being searched for. TIP 2: search engines have bubbling, which will insulate you from getting the same results I might, but, with broad enough terms, you will train it to mean exactly what I mean
Well, this actually doesn’t help us very much.
All hope is lost.
But this is a great opportunity to learn to utilize placeholders, since we need a cat’s paw anyways.
Well, first off, I’ll be taking this Picture of a Cat’s Paw.
micro tutorial: GIMP 2.10
We can make this useful if we just modify some junk.
Give it an alpha layer so we can make the image transparent.
Fuzzy select tool is good for finding large contiguous image regions.
With these settings, we can click any part of the white zone and remove the white background from the image by hitting delete.
Wowie zowie, now no stock images are safe from being used as placeholders!
Image -> Crop to Content or any other crop option will help to shrink down the image to just the data we care about, in different ways. In this case, Zealous Crop will also work.
Export the image: remember to change the file to extension to .png because that’s the point.
You can try to drag the picture into the game as much as you want, but it’s not gonna do anything. But if we look in the Hierarchy Window, we can see a main camera and a light, which are things that correspond to things in the Scene View. So this Hierarchy Window must have something to do with putting things in games, if I can see them.
We have an image, and we know that sometimes 2D images are called sprites. But how do we make one?
If we visit Create -> 2D Object -> Sprite then we can do exactly that.
Whoa, if we do that we get a message! Must be important!
Here is a chance to learn a valuable skill!
While it’s easy to disregard most errors and hope for the best, as the general computer user may, we are not able to do so because we are creating software for the general user. We are making stuff. Whether we like it or not, we’re now a Power User. We have to read error messages and care about what they say and why they happened.
Some things come to mind:
What is a SpriteRenderer?
Why is it talking about Textures?
Why does an image need configuration to make sprites?
Okay, so, a little known fact is that if you hit Ctrl+C whenever a dialog box shows up, you can usually copy the message contents. Then you can paste it into a text editor with Ctrl+V.
On my machine, this does not work. However, we can transcribe portions of the error dialog into a text editor. Even if we do not understand a single thing being said to us by this error, we can at least make note of it so that we can put the pieces of the puzzle together later.
Oh no! Now there’s two error messages! Hah, pranked 'ya! One of those is a fake one!
It’s important to jot down everything about the error we can see in the event we can’t get it to happen again. There might come a time where this error is a big problem later and we don’t know what happened.
Now that we wrote it down, we should also think of some other things, like:
What was the last thing we did before this error happened?
What other things did we do prior to that?
What state did we put the Unity Editor into to cause this?
We can write those down real quick, too!
things we did:
1) dragged the cat paw into the scene (didn't do anything)
2) dragged the cat paw into the heirarchy (didn't do anything)
3) clicked "create -> 2d object -> sprite" (caused error)
Okay. Now we have this incident tucked away. We can save the text file and hope that when we hit OK Unity doesn’t come crumbling down in flames.
Interesting, Unity didn’t crash, and now there’s a thing called New Sprite. This Inspector thing over on the right seems to have that SpriteRenderer the error was talking about. According to the error, there’s something it wasn’t able to do. We made an object, but we can’t see it in the scene.
Well, a sprite renderer can’t render sprites without a sprite. So having a Sprite of None simply won’t cut it.
We need to take matters into our own hands. Clicking on the word “Sprite” doesn’t seem to do anything. Clicking on the box for “None (Sprite)” does not seem to do anything either. Clicking the circle next to it, does appear to work!
Well, none of these seem to be what I’m looking for. I can see the cat paw right there! Why isn’t it here?
I clicked on the Knob graphic. Now I can see a tiny little glint of something on the scene view.
Is that the Knob?
Well, that’s not a cat’s paw, so let’s try something else. That message we got earlier said something about textures and for some reason the picker implied that our cat paw wasn’t a sprite. Let’s take a look at the Inspector after we click our cat paw in the Project folder.
Wow, there are a lot of options. I thought it was just a picture!
Up there at the top, we can see the option that says Texture Type! Is that what the warning was talking about? Did it try to make a sprite out of this cat paw because we still had it selected when we made our Sprite object? Let’s try and change the Texture Type and see what our options are.
HEY! Sprite! THAT’S THE THING WE WANT!
Whoa, now new options appeared!
Let’s take mental note of these options for now, then let’s see if this change worked and if we can use this on our sprite instead of the Knob. Let’s hit Apply to save our changes to the cat’s paw import settings.
First, let’s try to drag the sprite into where it says Knob.
We could modify existing associations by dragging new things into them! We could also drag things directly into the sceneor even directly into the hierarchy!
Wow. But we still don’t know how to make it move. Let’s recap what we know now about Unity:
Files exist in the Project tab.
The Inspector is context sensitive to whatever we have selected in the Project, Scene, or Hierarchy tabs.
The Hierarchy window lists the contents of the Scene view tab, even things we can’t see.
The thing that lets us show sprites is called a Sprite Render, we can find this on a GameObject’s Inspector.
Sometimes our assets will need some configuration in their Import Settings in order to work before we can use them in certain contexts.
Cool. Now we have a sprite. But even if we hit Play and simulate our game, nothing happens.
We can hit Play again to exit Play Mode, since nothing special happens if we don’t have it set up to do so.
So we still need to figure out how to make the cat’s paw move. Let’s recap some facts:
Our current objective is: Moving the cursor moving a cat’s paw.
We are trying to make a game using Unity.
The programming language for Unity is C#.
We know that the thing that represents our computer mouse’s position is called a cursor.
Sprites are visualized using SpriteRenderer in Unity.
The thing that our SpriteRenderer lives on is called a GameObject.
There was another thing on GameObject next to the SpriteRenderer called the Transform that had information about x/y/z on it.
Now how can we utilize these facts to our advantage? When we first searched for something we were not able to get any useful results. We can decrease the scope of our query by increasing the use of domain specific terminology. Likewise, sometimes our query might be too specific, and we will need to do the inverse: we can broaden the scope of a query by using more general terms. We only need to maintain the domain of our question by having something like “unity” in it somewhere. Let’s try this:
It goes on like this. Well, first off, what’s this about code? How do we get code attached to an object? What is the point of all this? Well, this first bit of code looks good. Let’s try it. We know that things like the Transform and SpriteRenderer exist on the GameObject. Let’s go back and look at our New Sprite.
What’s that button at the bottom?
Wow, there’s a bunch of things! Rendering is an option, let’s look at those.
Hey, SpriteRenderer is here!
Okay, with all this information, it stands to reason that those things on the GameObject are called Components. If we look back to that first piece of code, one of the first lines says public class MouseMove2D, let’s try adding that.
Hey, an option for a New Script! Code can live on GameObjects in the form of a Component that is some type of Script!
C sharp? Is that supposed to be C#? Let’s take a chance and hit Create and Add.
Now we have a new component named Mouse Move 2D, and some file in our Projects View appeared. Let’s click on that new thing to see what it is.
Hey, this looks like that code stuff that other people were posting! Ours looks different than what they posted. Let’s click on the Open button and see what we can do about that.
It opened up my editor! For you, Unity will probably open with Visual Studio 2017, and hopefully not MonoDevelop.
Let’s type what they typed on the forum post to make our code look like theirs and see if we can get it to do what they said it does.
Okay, well, for some reason the most popular piece of code on the internet for whatever we just searched for does not even remotely do what we wanted it to do, or what the original poster asked for it to do, it seems. Let us ignore all that and try and make it work ourselves, as we will often experience this sort of thing.
It appears that as soon as we right-click the paw slowly starts moving upwards. Let’s look at this code and see what we’re doing in it.
// Update is called once per frame
void Update () {
if (Input.GetMouseButton(1)) {
mousePosition = Input.mousePosition;
mousePosition = Camera.main.ScreenToWorldPoint(mousePosition);
transform.position = Vector2.Lerp(transform.position, mousePosition, moveSpeed);
}
}
Let’s break this down and see if we can figure it out.
// Update is called once per frame
void Update() {
So this is telling us that this code is getting run every frame, it seems. That stuff with a // in front of it doesn’t look funny so it might not be code, it might just be a comment that someone left for us.
if (Input.GetMouseButton(1)) {
mousePosition = Input.mousePosition;
From here, it looks like something called mousePosition is equal to Input.mousePosition. I’m guessing that Input.mousePosition is reading from our Input device in some way, and we need to do this every frame.
Now it looks like we are changing the value of mousePosition to be the value of this new thing. Camera, main, ScreenToWorldPoint … Is this taking a Point from the screen and turning it into a point in our World/Scene using the main camera in some way?
Transform is a component that we see on the GameObject! We recognize that. If we go back and look at that gif again, we can see that the value of the Transform changes when we right-click. Here it is assigning it to some sort of Vector Lerp function. This must be what is moving the object gradually when we right-click.
}
}
I don’t know what these are here for. But it looks like for every time we see a { there’s a } on the other side of it, and text moves over some. This must be some sort of pattern or symmetry that we should take note of.
Let’s think:
Based on skimming some of the other code posted, we will probably need Input.mousePosition and ScreenToWorldPoint because other people’s code seems to reference it for a similar purpose.
We don’t need the object to move around smoothly, we need it to be where the mouse is, so that last bit of code might be excessive.
mousePosition seems to just be a means of moving some sort of value around and changing it, some sort of variable that doesn’t necessarily do anything on its own.
Let’s try to change this code some, using what we know now.
I get this weird message when I try to enter Play mode, what’s it saying? All compiler errors have to be fixed before you can enter playmode!
Well I don’t know what a compiler is or how it errors, but it also looks like our files are gone!
I have been hoodwinked! There’s this console thing in my way saying something about Assets/MouseMove2D.cs(20,3): error CS1002: ; expected.
OH GOODNESS, I clicked on it and it appeared again at the bottom! The problem has gotten twice as bad. Well, better go for broke and keep clicking on it.
When I clicked on that, it opened my code back up, and it moved my text cursor.
I just noticed these numbers at the bottom of my editor, they look similar to the numbers we saw earlier: (20,3). Not sure what that is about. The line my cursor is on is line 20 according to the numbers on the left, but the only thing here is a }.
At the end of this line there’s a red squiggle, but I don’t know what it means. I’m going to point at it with my cursor to see if I can get some insight.
Once again, it is this ; expected thing. But this is line 19, not line 20, I thought the problem was line 20!
Okay, now when we click, it disappears. Somehow we have made things worse. Something is different, though, I just realized that the Z has changed to -10, and before, it used to just say 0 when the paw moved slowly. The Y changes in both cases, however. What happens if we change the -10 to a different number?
When we change it back to 0, it moves back. When we click on the label of the value and drag it, we can slide it around. When the number gets smaller, it gets closer. When the number gets bigger, it gets further away. It seems to disappear completely near -10 Z. What is in our scene that is at -10 Z?
It’s not the light.
It’s the camera! It makes sense, when the number gets smaller, it is moving closer to the camera! The camera is how we are seeing into the scene!
Does it have something to do with the fact that we’re clicking? Let’s try and eliminate as many factors as we can and take that code we have that changes the transform position and move it from out of the { and } that mention the GetMouseButton.
Something about what we are doing is setting the Z, let’s try to prevent that from happening. Something about the value of mousePosition is setting the Z right before we assign it to the transform.position.
If you notice, other pieces of code have a . between some words we recognize.
What would happen if we put a dot after our mousePosition?
Hey, it’s that z fella! When we put a . at the end of something, we got to see more things about it! Let’s assign that z to be 0 so he doesn’t cause any more problems!
Well, let’s just mess with everything on the camera and see what happens. It can’t get more broken, can it?Hey, wait, it looks like one of these things did something!.
When we exit Play Mode, the setting looks like it changed back. I guess we need to change it back outside of Play Mode in order to have the settings stick. That also happened to the transform of the camera and our sprite. Let’s reset it and try playing with that last setting again.
It looks like we figured it out! This is what was wrong.
Let’s see if we can understand why:
I just realized that before, the Y of the paw was also changing to 1 when the paw moved inside the camera.
The point that the object follows our cursor was also exactly the point where the camera was.
When we are in Perspective mode, the camera has a box shaped like a trapezoid coming out of it, and messing with the FOV has a dolly zoom effect like that scene from jaws.
When we are in Orthographic mode, the camera is shaped like a rectangle and messing with the size only makes it closer or further away, and doesn’t warp the view.
When we are in Orthographic mode, the white box coming out of the camera is the exact same shape as our Game window. It even changed when we made it wider.
Camera.main.ScreenToWorldPoint only worked when the main camera was set in a mode that mirrored our game screen.
We … did it? We finished the first half of what we need to do, and we sort of have an idea about what we’re doing and why things are happening. We didn’t know how to code, or how to use Unity, but we still managed to use enough of our problem solving skills to figure out things because we absolutely refused to read or participate in the tutorials I linked in the first post that I said everyone should do. Huh. Weird.
Next time, we can focus on adding things to the game and figuring out how to move them around. So here’s my question for the thread:
1. What are things you want to see in the game being broken by the cat?
2. What are some things you want to hear get broken?
3. What are some things that might behave in interesting ways if they fell off of something?
Feel free to post pictures, sounds, or other things in order to establish a reference.
EntranceJew, you malignant asshole, you said we were going to learn to make games with code and the only thing you’ve done is given motivational talks to psyche yourself up for boring shit, repeated basic facts to yourself, and trial and errored your way through every single obstacle you encountered.
