We did a gamejam last weekend, and this week we’re coming down from the post-jam high. We discuss what it means to be a “real programmer”, and Sam (THAT'S ME, YO) tells of experienced paranormal activities through his relationship with the Step Ghost.
Check it out! https://soundcloud.com/butterscotch-shenanigans/ep72
Ep 72 - Step Ghost
12 posts
• Page 1 of 2 • 1, 2
10 Nov 2016 19:30
1. Cool games. I tried out all three. I really like the art in all of them. Also, I played the other games on Carol's itchio page. Those were pretty cool too.i liked the teddy bear kissing one the best.
2. That ghost story really spooked me out. I was walking around outside at night so it was even better.
3. On learning game development in a class, I was kinda wondering about that. I kinda feel like I would like an actual programming class, or some way to see a wide variety of possible stuff I can use, as a way to expand my toolbox. I feel like my code is really inefficient because I don't know a lot of code secrets. (If there are any, but obviously I wouldn't know since they are secret) I can get most things to work, or I just design stuff I can do with what I have, but it's always nice to learn about your other options. I'm excited for this Bscotch School.
TLDR: 1. Nice games. 2. Nice ghost story. 3. Games. Learning.
2. That ghost story really spooked me out. I was walking around outside at night so it was even better.
3. On learning game development in a class, I was kinda wondering about that. I kinda feel like I would like an actual programming class, or some way to see a wide variety of possible stuff I can use, as a way to expand my toolbox. I feel like my code is really inefficient because I don't know a lot of code secrets. (If there are any, but obviously I wouldn't know since they are secret) I can get most things to work, or I just design stuff I can do with what I have, but it's always nice to learn about your other options. I'm excited for this Bscotch School.
TLDR: 1. Nice games. 2. Nice ghost story. 3. Games. Learning.
-
- Posts: 114
- Location: North
10 Nov 2016 22:08
Sounds like you guys had bad experiences with programming classes 
. I haven't had a class I haven't enjoyed. Data structures seems to be most peoples' favorite class.
Reminds me of that podcast question a while ago when I asked how you stored Crashlands's inventory, and you said you didn't know what most of the suggestions even were, and said the answer was a 'map,' which is just the abstract type of several of the options I suggested.
Choices of data structures can be pretty important, especially when you're aiming for efficiency (remember when you guys were trying to reduce memory usage in Crashlands?). I also remember when you guys were having trouble with pathfinding during the beta (A*, I think). A data structures class should go over things like Dijkstra's algorithm, sorting, linked lists, BSTs, hashtables, etc. but also when to use them. I imagine you could've worked something out so you didn't have to use a map at all for the inventory, and a simple array would have sufficed (and likely would have been more efficient).
An algorithms course is almost a continuation of that stuff, but of course with more emphasis on how and when to use things.
Your complaints about the structure and assignments are justified, though--a poorly laid-out class and useless assignments can drastically reduce the amount of fun. Especially when things are thrown at you in an 'arbitrary order' instead of in a way that makes sense. A general outline of the data structures course I TA for is that we briefly review the prior stuff, then go into sorting -> (dynamic) arrays -> linked lists & stacks/queues -> hashtables, trees, & tree traversals -> heaps & graphs -> graph traversals. It is a bit slow, at least in a large class, but it's a bit difficult to go much faster while still going in sufficient depth for most of the students to get an idea of what, how, and why you would choose to use them.
You're right that you don't need to know that stuff to use it, but I imagine being a game dev means you need efficiency. Imagine if every time you picked something up in a large game, it lagged while it figures out where to put the item in your inventory, because the dev didn't know there was any data structure besides an unsorted array!
Where did you guys take those courses?
(PS: I meant a real 'programming course' not a 'real programming' course)
. I haven't had a class I haven't enjoyed. Data structures seems to be most peoples' favorite class.Reminds me of that podcast question a while ago when I asked how you stored Crashlands's inventory, and you said you didn't know what most of the suggestions even were, and said the answer was a 'map,' which is just the abstract type of several of the options I suggested.
Choices of data structures can be pretty important, especially when you're aiming for efficiency (remember when you guys were trying to reduce memory usage in Crashlands?). I also remember when you guys were having trouble with pathfinding during the beta (A*, I think). A data structures class should go over things like Dijkstra's algorithm, sorting, linked lists, BSTs, hashtables, etc. but also when to use them. I imagine you could've worked something out so you didn't have to use a map at all for the inventory, and a simple array would have sufficed (and likely would have been more efficient).
An algorithms course is almost a continuation of that stuff, but of course with more emphasis on how and when to use things.
Your complaints about the structure and assignments are justified, though--a poorly laid-out class and useless assignments can drastically reduce the amount of fun. Especially when things are thrown at you in an 'arbitrary order' instead of in a way that makes sense. A general outline of the data structures course I TA for is that we briefly review the prior stuff, then go into sorting -> (dynamic) arrays -> linked lists & stacks/queues -> hashtables, trees, & tree traversals -> heaps & graphs -> graph traversals. It is a bit slow, at least in a large class, but it's a bit difficult to go much faster while still going in sufficient depth for most of the students to get an idea of what, how, and why you would choose to use them.
You're right that you don't need to know that stuff to use it, but I imagine being a game dev means you need efficiency. Imagine if every time you picked something up in a large game, it lagged while it figures out where to put the item in your inventory, because the dev didn't know there was any data structure besides an unsorted array!
Where did you guys take those courses?
(PS: I meant a real 'programming course' not a 'real programming' course)
-
- Posts: 55
10 Nov 2016 22:54
What about game design classes? I see the usefulness of a programming class, but game design seems really open to interpretation. Then again, I'm in a school of design right now, so maybe I'm doing totally useless stuff right now. I'm having fun though. It's very expensive fun.
-
- Posts: 114
- Location: North
10 Nov 2016 23:52
@MAP5597 Sound reasoning! We're basically dealing with the problem of premature optimization in this case: you're absolutely right that being unaware of efficient algorithms and a lack of understanding about data structures can both dramatically impact game performance, but when game performance is good enough we can scrape by.
This is also a premature learning optimization problem -- if you learn about something you don't have the context to understand, you don't learn about it effectively. Certainly a well-designed course can provide enough context to keep it understandable, but real-world learning can also get you there once you run into road blocks. Both work, but the advantage of real-world learnin' is that no one else can screw it up for you ;)
This is also a premature learning optimization problem -- if you learn about something you don't have the context to understand, you don't learn about it effectively. Certainly a well-designed course can provide enough context to keep it understandable, but real-world learning can also get you there once you run into road blocks. Both work, but the advantage of real-world learnin' is that no one else can screw it up for you ;)
-
- Posts: 1722
- Location: Dallas, TX USA
11 Nov 2016 00:45
True, but though no one else can screw it up for you, you can screw it up yourself. Your recursion example in the podcast sounds similar to something like that. I imagine that at least having someone around who knows what they're doing is an immense help, so you don't miss things.
I like to mix real-world things and class things as I take the class. If there's mention of something particularly interesting, I'll have a go and see if I can implement it. One example of this I encountered was when we we learning about how you can use stacks to evaluate an expression by turning it into postfix; I went home and did it.
The 'good enough' strategy for game-making sounds pretty solid. But as you guys were talking about in Carol's VR experience in a prior podcast, performance can be a big deal sometimes. Of course VR is kind of a bad example, since it seems to be mainly hardware & cost limitations at the moment, but if I recall you guys also mentioned how devs need to be careful developing for VR since they can make themselves sick while testing.
@kevin888 I've'nt taken any game design classes. It does sound much more subjective than computer science or software engineering (which, with names like those, kinda seem to be more of a 'hard science' subject, don't they?). It seems to me that creativity is a big part of game design, and perhaps learning 'the right way' doesn't necessarily work for something like that. Sam's 'what if you're the elevator?' moment for DYEL seems like a good example of this--if you're hung up on doing things 'the right way,' perhaps you won't get strokes of brilliance like that. Though of course, I'm not too familiar with game dev/design except what I've read from Butterscotch here, so feel free to enlighten me.
I like to mix real-world things and class things as I take the class. If there's mention of something particularly interesting, I'll have a go and see if I can implement it. One example of this I encountered was when we we learning about how you can use stacks to evaluate an expression by turning it into postfix; I went home and did it.
The 'good enough' strategy for game-making sounds pretty solid. But as you guys were talking about in Carol's VR experience in a prior podcast, performance can be a big deal sometimes. Of course VR is kind of a bad example, since it seems to be mainly hardware & cost limitations at the moment, but if I recall you guys also mentioned how devs need to be careful developing for VR since they can make themselves sick while testing.
@kevin888 I've'nt taken any game design classes. It does sound much more subjective than computer science or software engineering (which, with names like those, kinda seem to be more of a 'hard science' subject, don't they?). It seems to me that creativity is a big part of game design, and perhaps learning 'the right way' doesn't necessarily work for something like that. Sam's 'what if you're the elevator?' moment for DYEL seems like a good example of this--if you're hung up on doing things 'the right way,' perhaps you won't get strokes of brilliance like that. Though of course, I'm not too familiar with game dev/design except what I've read from Butterscotch here, so feel free to enlighten me.
-
- Posts: 55
11 Nov 2016 02:04
I'm not personally in Game Design, but it's pretty big at my college. I haven't really talked to any of those students, but my general feeling is that they are looking for more of a triple A game career. Its seems like they are trying to get into the big companies. A lot have dropped out, possibly because playing games in way easier than making them, which some people might not be really familiar with.
All this is probably wrong,and just my speculation based on really limited data.
I'm in Art and Design, hoping to get into Industrial Design. This year, we are just doing foundational art skills, drawing with charcoal, sculpting with clay, etc. It doesn't feel like real school at all, but I like it.
All this is probably wrong,and just my speculation based on really limited data.
I'm in Art and Design, hoping to get into Industrial Design. This year, we are just doing foundational art skills, drawing with charcoal, sculpting with clay, etc. It doesn't feel like real school at all, but I like it.
-
- Posts: 114
- Location: North
11 Nov 2016 02:17
I went to a talk last year about why you shouldn't get into gamedev, citing how the big companies tend to "burn & churn" (hire, make them work long hours, then fire when game is released)--and they can do that because they have so many applicants (and they're willing to work such long hours). Apparently you have to be rather talented and fortunate to get a position for much longer than that.
As for playing-is-easier-than-making, I've heard things like that a few times; what portion of people that go into game design do so just because they like playing games? Anyone here know?
As for playing-is-easier-than-making, I've heard things like that a few times; what portion of people that go into game design do so just because they like playing games? Anyone here know?
-
- Posts: 55
11 Nov 2016 15:17
No idea on the proportion, but without a doubt the vast majority of people who tell us they want to make games for a living aren't willing to put in the work to make it happen, and seem to mean, "I want to have ideas about games that other people then go make, but I don't want to study anything about game design or learn how to make games myself."
-
- Posts: 1722
- Location: Dallas, TX USA
11 Nov 2016 15:18
Jumping onto what Adam said...
We have a buddy who likens game dev to brewing beer. Lots of people like drinking beer, and some of them go, "I like beer! I should start brewing!" Then they learn that brewing takes math, and measurements, and science, and patience, and lots and lots of practice. Turns out drinking beer requires none of those things, so most people turn right back around and stop with the idea of brewing before they even start.
We have a buddy who likens game dev to brewing beer. Lots of people like drinking beer, and some of them go, "I like beer! I should start brewing!" Then they learn that brewing takes math, and measurements, and science, and patience, and lots and lots of practice. Turns out drinking beer requires none of those things, so most people turn right back around and stop with the idea of brewing before they even start.
-
- Posts: 1371
- Location: St. Louis, Missouri, USA
12 posts
• Page 1 of 2 • 1, 2
Return to Podcast and Blog Discussion
Who is online
Users browsing this forum: No registered users and 1 guest