Hello! I'm Tom. I designed a game called Gunpoint, about rewiring things and punching people, and now I'm working on a new one called Heat Signature, about sneaking aboard randomly generated spaceships. Here's some more info on all the games I've worked on, here's the podcast I do, here are the videos I make on YouTube, here are some of the articles I wrote for PC Gamer, and here are two short stories I wrote for the Machine of Death collections.
Jepp: 1) Please keep critiquing games by building new ones :)...
Chris Kilgariff: Hey, This game needs to be a mobile phone...
Andrew: Just linked the book club to you, boosting your...
This is a brief look at the pathetic progress I made by the end of my first full day working on what might be my next game.
I have 5 different ideas I’d like to do, but one in particular has been really exciting me, so I’m prototyping that first. If the prototype is fun, it’ll turn into my next game. If it’s not, I’ll prototype something else. Part 2 below.
Most of what I’m doing right now is wrestling with learning C# and Unity, both of which are much harder than what I’m used to in Game Maker.
Here’s what I did on day 2:
I figured out how to get Unity to know where in a 3D space your 2D mouse cursor is pointing. It’s probably not the simplest or best way, but I’m terribly pleased with myself for getting it to work at all, so I made a video showing it off: raining blocks on the player and building little platforms for him.
Neither of these things will be in the game.
For anyone interested, I talk you through the code at the end, but you can skip that if you’re not interested in game programming. If you are, I will accept your scathing ridicule for everything I’ve done wrong in the comments below.
I don’t know how regular these will be, I won’t take you through every tiny chunk of code of course. It’s really just things I found interesting or am pleased with.
ghosttie: Yeah, anything new hurts :)
iwantyoutothinkiamapro: You may want to read the first few chapters of a C# book to learn about variable types. 'f' after numbers specify that the number is a single precision floating point number which is faster than the default double precision and thus always used in game engines ( 2.0 creates a variable of type 'double', 2.0f creates a variable of type 'float' ).
For the pointer position in world space you can use Camera.ScreenToWorldPoint with the pointer screen space position ( Input.mousePosition ) as a parameter. Note that the z position will be the z position of the camera so you will need to change it to the z position of the player ( or the z position you wants the cubes to spawn ).
If you search the script reference you can find unity functions with examples.
Unity script reference : http://docs.unity3d.... ...Reference/
If the game is only 2D you may change the camera projection to be orthographic.
Unity 4.3 ( currently in beta ) will bring a lot of 2D specific tools ( 2D physics engine, sprite support ... ).
And this books covers the basic math involved in computer graphics and is quite simple. http://www.amazon.co... ...1568817231
Diego: You were probably told to use C# because of reasons, but I use java script and find it much easier. I still haven't found anything you can only do in C#, neither a difference in performance.
Micael: Not sure what you have seen in what concerns tutorials, but unity has their own tutorials http://unity3d.com/l... ...ls/modules and while they don't cover everything, they do cover a good bit of ground (including scripting), those tutorials were created by the same guy that did this http://www.unity3dst... ...udent.com/ which is a very good source of tutorials (highly advice it to anyone starting unity), then you have others like unity cookie and 3dbuzz, which also provide several tutorials on different subjects.
Now for a few tips, that problem you encountered with the camera requiring a rigidbody can be solved by script with a single line of code, you put this in your control script [RequireComponent (typeof (Rigidbody))] wherever you add said script will automatically add a rigidbody, obviously you can replace Rigidbody for other types of components, and it will automatically add those.
Also you can disable gravity on the rigidbody component, in fact you can make it kinematic which means it won't respond to input from physics (which would make your script not work since it's adding force to move the object).
Instead of adding several point lights to every scene you can instead go to edit -> render settings -> and change the color of the ambient light to something more white, ambient light, this will increase the ambient light of the scene making objects more visible (or less visible), alternative you can also use a directional light which acts kind of like the sun, and illuminates everything.
Also use ctrl+p to play and stop the game, and check vertex snapping, unit snapping, and surface snapping it will probably help you build levels faster.
Now for programming tips:
Don't comment every single line of code, it's not a good programming practice, comments should only be used as a last resort, when one cannot find any other way to make the code clear just by reading said code if you have this line of code:
Vector3 positionAfterTeleport = player.transform.position + teleportDistance;
there is no need to comment it out, since the name of the variables already says what the code is doing. One exception to this rule is XML method (basically what c# calls functions) commenting.
some of the reasons why you don't want to comment every single line of code are:
If you change the code but you don't change the comment (which happens more than one might think) which may lead to mistakes.
Reduces your ability to easily read the scope of the code, since effectively each line of code ends up taking two lines, halving the amount of visible code space.
In the end increases the amount of work, decreasing your ability to quickly change code, or test new things out in said code.
The out thing, in the raycast method is a way for a method to return additional variables, in the case of the raycast, all raycasts return a bool to indicate if they hit something or not, sometimes this information is enough and as such you do not require any more info from said raycast, however when you require the information about the hit (like where did it hit, at what distance did it hit, what collider did it hit and so on).
You can OFC create your own methods with your own outs, and you can use how many per method as you want, you can check msdn http://msdn.microsof... ...32485.aspx in fact you should always check msdn for anything that is c# related.
In your ClickToCreate script you create a plane and raycast from said plane, an alternative to what you are doing could be to just simply put a plane in the scene background and raycast directly from the camera, you would get the raydistance from the difference between the camera and the plane z axis (you can also just give it a fixed distance, but less ideal in case you change stuff around), and you could spawn it using the returned x, y coordinates plus the z coordinate of the player (assuming you want to spawn stuff on the depth of the player).
Also a way to fix the all creating objects inside other obects is to see what the raycast hit, and then decide if it should create or not create said objects.
If for example you wanted to create objects in mid air (like those platforms) you would only create said objects if the raycast didn't hit anything besides the plane/camera.
If you only wanted to create those objects when it hit other things, like say if you wanted a swing mechanic like on bionic commando, you would only create the object when it hit other objects.
This doesn't fix things like creating an object that is half inside another object, but that can easily be fixed by just simply spawning a collider checking to see if there is any collision, and then proceed accordingly.
P.S. You wouldn't need to implement your own physics system, nor should you, you can use box2d for 2d physics, and bullet for 3d physics, they are both free and open source, that being said I doubt you would need to do either of these things, since unity already has 3d physics, and the next update that should be around the corner brings 2d physics (although you can do 2d physics using 3d physics)
Torsten: That method to find the point is pretty much the only reasonable way to do it. In this particular instance, where you only want to find the point where z=0 along the ray, you could in theory simplify it more:
ray start.z + distance * (ray end.z - ray start.z) = 0 so
distance = -ray start.z/(ray end.z-ray start.z
But that is just harder to read, not applicable to the general case and not actually faster in any measurable way. Mathematically speaking, it is exactly the same thing for the specific plane you're using.
Nick: I've been working on my own prototype for a game using GameMaker. Was surprised at how quickly I dumped drag & drop for code (within a couple of hours). Given it's still early stages I've been considering using Unity.
But that second video. Bloody hell. It's given me a much greater appreciation of the importance of how GM bakes in so much stuff. That you need a dozen lines of code for the GM equivalent of mouse_x, mouse_y kinda confirms that, yeah, GM is probably the place to start with making games...