Yesterday we presented the current state of our projects to our peers and parents. Seeing what everyone else got done in the time we've had to work on this, seeing a side by side comparison of our products, made me realize a couple things. Firstly, nobody besides me likes coding apparently, which makes me excited for my job prospects. If my future peers dislike coding, that means I get to be paid to make it so they don't have to. From what I've seen, everyone likes either 3D modeling or character design, areas that I'm capable of working in and understand, but am certainly not as adept in as my peers. I also learned quite a bit about how far my presentation skills have gone since freshmen year. If I make a complete fool of myself, I'm much more relaxed and capable of presenting in a fun and entertaining way. And, generally, if I treat a presentation as entertainment, rather than a serious production for serious people, I can actually get across more information in a much more comfortable fashion than if I stood up there awkward and stuttering. So, generally, a good learning experience.
0 Comments
This week has mostly been watching tutorials and trying to work out coding. Progress has been difficult and slow, and it's really hammering in the idea as to why projects don't typically only have one person on them, and usually have a team of coders, writers, artist, etc. I'm still not going to ask for help, this is my project, and I'm going to see it to the end, but I probably should've put more effort in last year to learn how to code so that this process would go by a lot faster. Next week:
- Keep on figuring out coding. So far, I've only really worked with modeling the characters for my game, and shaping the environment. But, I'm genuinely proud of what I've done, and it's starting to look like an actual game. I'm excited to no end about this, that I'm actually making a game. But, it's not all been pretty. I've learned a good lesson about importing and exporting assets. That lesson being, avoid it if you can. In this case I really couldn't avoid it, because Unity doesn't have the extensive object manipulating ability that 3DS Max does, but it's really frustrating when you do finally import an asset and it doesn't go through right, and you have to figure out what the issue was, and then remodel around that issue. Specifically, I figured out Unity really doesn't like the mirror function that 3DS Max has, so I had to remodel a large section of the truck. Though, in honesty, it was probably for the better, it helped me rediscover soft selection, and I got a much better product due to it. That's another thing that I've been running into, rediscovering a lot of old features that I'd forgotten about that really make modeling so much smoother. But, once I get the bridge done, which shouldn't take more then a day, I'll have all the models that I need for now, and then I can move into the coding and animation part of this project. And, oh boy, that's going to be interesting.
*Error in line 25, except the error is actually in line 12 but its still kinda right, but it only being kinda right screws this area up so I'm going to point you here
*You forgot a semicolon *You forgot a semicolon *Stop forgetting semicolons *You forgot to capitalize something *You forgot to put a space here *You screwed up *You screwed up *You screwed up You screwed up. That pretty much sums up coding in a nutshell. So many little things can go wrong, that just, absolutely tear hours of work down, and create even more work trying to undo the mess you made. And I can't even blame C#, its doing its job fine (though Unity crashing doesn't help), I'm the idiot telling it to look for "score" instead of "Score". It doesn't know what the hell "score" is, so because of that it doesn't destroy an asteroid flying at a spaceship. And everyone on that spaceship would be dead, if the asteroid didn't just pass through the spaceship, causing an explosion, but not actually damaging the spaceship in of itself. Its frustrating. Very, very frustrating. But, little by little, I'm getting a better understanding of what I'm actually doing. And the more I understand, well firstly the more I don't understand because everything works and meshes together and if you understand one thing you have to understand the 20 other things it works together with, but the more power I gain over the medium I'm trying to manipulate. The more I can actually do in virtually constructed world of error messages and semicolons. And that's encouraging, and very invigorating. If I develop the skills necessary, I'm sure I'd enjoy doing this for a living. My introduction to the Unity interface has reasonably well, though there are some issues. Though its quite similar to 3DS Max, which is what I'm used to using, its slightly different. Getting used to the new camera controls is slightly annoying when every thing else looks and works the same. As for scripting, I'm fairly used to seeing it. The only real difficulty should be memorizing C Sharp's language. From there, it should just get easier and easier. The Roll-A-Ball tutorial was a really good introduction to the software. If you actually pay attention and follow what hes saying, its also a fairly decent introduction into scripting. Overall, this has been a much more intuitive and interesting experience then Game Maker, and more useful in the foreseeable future.
Coding is, naturally, an important part of creating a game. It is the flesh of a game, what makes it run, what makes it do exactly what you want. As said in Keith Burgun's article about programming, you don't necessarily know how to code to make a game. You can have other people do that for you. But, as again said in the article but more importantly what I observed during the Hour Of Code, you need to be able to code if you want immediate and responsive change. I saw that the most effective way of creating a piece of code was making something that you think should work, seeing where it messes up, and fixing it so that it doesn't do that. You can't get that immediate response if you aren't coding. Say your play testing a game, and notice that a certain object doesn't have physics. If you don't know how to code, you have to tell the programmers, have it put on their schedule, and it may be days before its fixed. On the other hand, if you can go into the code and fix it, its done. No one else needed. The Hour of Code also got me into the mind set that coding is trial and error. I'm going to make mistakes. A lot of mistakes. And I can't let that stop me from learning how to program because its an extremely important skill I need to know if I am to go into this field. It also really helped me understand that, once you know the language, its just making the thing do what you want it to do. Difficulties arise from interactions between coding, and human error when creating said coding. But other then that, its just logic, its just telling the computer what it needs to do and when to do it. Its just learning how to tell it that is difficult.
|
AuthorI am 17 years old, and currently enrolled in Durham School of the Arts. Within the Game Design field, I'm looking to become a game writer or a programmer, preferably a combination of the two.
The views and opinions expressed in this blog are solely those of the author and do not represent those of Durham School of the Arts or Durham Public School Archives
June 2018
Categories
All
|