MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
YOU'RE WELCOME
In other news, my phone interview with Blizzard went well! They had me send them some Python samples a few days later. I feel real bad about my Python style
In other news, my phone interview with Blizzard went well! They had me send them some Python samples a few days later. I feel real bad about my Python style
I don't think it's possible to write good-style Python.
for the fuck of it i set the orthographic size to 113
which in theory should make the problem worse, because now the camera is no longer a perfect 16:9 aspect ratio
but
that appears to have solved the problem
whatever i guess
Unity's units are set in the middle of a pixel instead of the topleft, so it's probably something to do with that. I thought the UI and canvas stuff added in 4.6 made it easier to do perfect 2D sprites but I haven't messed with it.
In other news, my phone interview with Blizzard went well! They had me send them some Python samples a few days later. I feel real bad about my Python style
I don't think it's possible to write good-style Python.
Alternately, I think it's impossible to really write bad-style Python.
In other news, my phone interview with Blizzard went well! They had me send them some Python samples a few days later. I feel real bad about my Python style
I don't think it's possible to write good-style Python.
Alternately, I think it's impossible to really write bad-style Python.
Prior to learning Python, I tabbed a line of code depending on how important I thought it was. This line's crucial to the function? Tab that sucker 5 or 6 times
Python killed that habit (duh) but now I use sorta use blank lines to do the same thing
Prior to learning Python, I tabbed a line of code depending on how important I thought it was. This line's crucial to the function? Tab that sucker 5 or 6 times
Python killed that habit (duh) but now I use sorta use blank lines to do the same thing
If you really gotta highlight an important bit, use a comment.
It has the added bonus of explaining what the important bit does.
broken image link
+1
Options
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
edited May 2015
well, duh
I comment the crap out of my code. I'm looking at a 600-line file right now and the first 30 lines are dedicated to describing the file (summary of function, TODO, known issues) and within the body of the file I summarize each class/function with a few lines at the very least, and at most roughly "half" of a function is comments.
In other news, my phone interview with Blizzard went well! They had me send them some Python samples a few days later. I feel real bad about my Python style
I don't think it's possible to write good-style Python.
Alternately, I think it's impossible to really write bad-style Python.
Prior to learning Python, I tabbed a line of code depending on how important I thought it was. This line's crucial to the function? Tab that sucker 5 or 6 times
Python killed that habit (duh) but now I use sorta use blank lines to do the same thing
Wow, that would confuse the crap out of me. Indentation for me (and I think most people) is all about how deeply it's nested in another block, so the flow of execution is clear.
I do use blank lines to kind of separate out different chunks of code - sometimes I'll find myself putting blank lines between everything though, I'm not sure if that means I'm writing good code (performing a lot of encapsulated functions) or not.
I comment the crap out of my code. I'm looking at a 600-line file right now and the first 30 lines are dedicated to describing the file (summary of function, TODO, known issues) and within the body of the file I summarize each class/function with a few lines at the very least, and at most roughly "half" of a function is comments.
Be careful not to over-comment. Unless you use an external tool to gather documentation (like doxygen as an example) or to help with IDE pop-ups, the code itself should tell you what it is doing.
I comment my code so that if I have to pass it to someone, it's obvious about what it's doing (I had a prof that baked that into my head)
I took an intro python course as a GPA booster this year and probably agree with the sentiment that it's hard to write good OR bad python code, it just sort of exists
I think I maybe feel my game development mojo coming back, though my parents are visiting in a week so it's probably the wrong time. Hopefully I can talk with Dad about it and get some ideas so I can start back once they leave. I need to figure out the best way to do my inventory/crafting/item placement system - my instinct is to try to come up with some elegant solution where it all works nicely together, but really I should probably just hack something together that works and fix it later once I understand the problem a bit better.
I also want to work out a better solution for lighting, particularly with directional sunlight so I can do a day/night cycle. I have a couple of ideas but I'm really not comfortable with the math, etc in that area so the ideas are probably terrible and inefficient. I guess we'll see!
I spent the entire day today adding functionality to my movement system so that when your character approaches a sloped surface, their movement is adjusted to move parallel to the surface
After a LOT of wrangling I finally have it... Mostly working. 99% of the time everything works exactly like it should, but every now and then the player character goes in on too steep of an angle on one frame and gets slightly lodged into the slope and I got no clue why
Right now the collides in the sloped surfaces ar just straight lines that touch the convex vertices of the shape (the sprite is pixel art so it has jagged edges). I'm wondering if it would be better, worse, or no different to go in and manually make the collider perfectly fit to the sprite's stair-step edges
Python is fine if you're writing small stuff that only you have to look at. Some things it actually does really well.
But if you're making something moderately large that you have to share with other people it is a nightmare.
Dynamic typing sounds neat at first but it really hurts readability, since static typing basically self-documents your code, telling what types you can shove into what methods.
I spent the entire day today adding functionality to my movement system so that when your character approaches a sloped surface, their movement is adjusted to move parallel to the surface
After a LOT of wrangling I finally have it... Mostly working. 99% of the time everything works exactly like it should, but every now and then the player character goes in on too steep of an angle on one frame and gets slightly lodged into the slope and I got no clue why
Right now the collides in the sloped surfaces ar just straight lines that touch the convex vertices of the shape (the sprite is pixel art so it has jagged edges). I'm wondering if it would be better, worse, or no different to go in and manually make the collider perfectly fit to the sprite's stair-step edges
okay thinking about it
stair-stepping the edges would make the script work perfectly
but i do have a question because like
if i have a lot of slanted surfaces that will make the number of collider vertices in the scene go up fast
like i'm testing this with a large square tilted at a 45 degree angle, which is 48x48 pixels in size
and because each pixel has both a convex and concave vertex that needs to be accounted for, that means that the collider on it has to have 96 x 4 or... 384 vertices
thinking about it that represents 384 2D vectors, which is 768 floats, and if a float is 4 bytes, then that means 3072 bytes
which
i lack a strong enough understanding of how memory works to tell whether that's too much
I can imagine that both being exhorbitant and being a drop in the bucket
someone who's better with the technical end of things have some advice?
right now I just have a 4-vertex collider on it, and like I said, that works like... the majority of the time. So adding so many more vertices to move from "mostly works" to "definitely always works perfectly" seems... dumb
I spent the entire day today adding functionality to my movement system so that when your character approaches a sloped surface, their movement is adjusted to move parallel to the surface
After a LOT of wrangling I finally have it... Mostly working. 99% of the time everything works exactly like it should, but every now and then the player character goes in on too steep of an angle on one frame and gets slightly lodged into the slope and I got no clue why
Right now the collides in the sloped surfaces ar just straight lines that touch the convex vertices of the shape (the sprite is pixel art so it has jagged edges). I'm wondering if it would be better, worse, or no different to go in and manually make the collider perfectly fit to the sprite's stair-step edges
it would be worse. not sure how much of your movement is steeped in 3D unity but ordinarily you would want to be bounds checking all the time on what you're sliding against and make it functionally impossible for your character to ever be "in" the slope
Python is fine if you're writing small stuff that only you have to look at. Some things it actually does really well.
But if you're making something moderately large that you have to share with other people it is a nightmare.
Dynamic typing sounds neat at first but it really hurts readability, since static typing basically self-documents your code, telling what types you can shove into what methods.
This is solved by even a little bit of decent commenting. We use Python for large portions of our tool chain, and as long as everyone's writing code from the perspective that other people will have to consult and modify it, things work out okay. Python is the best.
Also there's no such thing as over-commenting. Give me PARAGRAPHS about what you're doing and why.
I've been sketching out board/card game ideas more than like, actual video games. Although I mostly come up with an idea, come up with one good core mechanic, and promptly fail to really build anything around it.
I am finding that, in looking at other games, the games that try to build complexity by having a whole bunch of components and stats and things don't really work for me as well, mostly because, anymore I'm the one that ends up explaining things. And I also don't really like games with win conditions that feel...arbitrary.
Like, I have Middle Earth Quest, and explaining the win condition in that game is an exercise in madness. The gameplay mostly works, but it's hard to really tell what you're working towards. And maybe that works for some people, but it's hard to get anyone interested in playing it in our group.
Hello. I design card and board games, and dabble in video pixel amusement programs.
Do any of you prototype your games on paper first?
You should! It's a bunch of fun and saves a metric ton of programming!
my small team have been playtesting a card game with proxies for a while now. good way to learn what decisions/cards were awful before committing to moving forward
I haven't gotten very far with any of the various board game ideas I've brainstormed, but...
The majority of the board game ideas I've toyed with have kind of jumped off of me looking at something I already enjoyed, and then taking that and figuring out how to make a game out of it. So, for example, I looked at Lost, which already has a very bad board game, and took a shot at figuring out how to adapt it into some sort of game.
So the first step would be to break it down into some core ideas that I associate with Lost. Things like: survival, fate, choices, light/dark, exploration, mystery, a focus on individual characters. The next step would be to run through some other games I've played, to see if any of them have any mechanics that would fit in with those themes. The official Lost board game was bad, but it had a pretty decent idea, that you would set up a map of hex tiles, face down, and then as you explored, you'd flip them over. Other games have set locations, and you'd draw cards that would give you specific events. As far as survival goes, there are a ton of games where you are, essentially, playing against the game as well as the other players, trying to keep your character alive. The choices/fate dichotomy, though...that was harder to find examples of in board games. Video games have morality systems in place; could something like that be transferred into a board game? How would that affect gameplay? And how would you work something like "fate," or at least Lost's version of fate, into the game?
I never really solved how to represent exploration in the game, but the core of the game would eventually start to emerge as I poked at it, a bit. The main idea would be that as you explored, you would be faced with choices. Some you would have to deal with immediately, others you could sit on for a while. In the process, you would earn white stones, or black stones, to represent the choices you had made. The game could force you into choices you didn't want to make, if you were unlucky; you might need to do terrible things to survive. You'd find other castaways as you'd explore, some would refuse to follow you if you were too light or too dark. At a halfway point, you would draw from a fate deck, giving you a personal goal to complete to end the game. Once you'd received your fifteenth stone, you'd look at the stones you'd drawn: if you had more white, you'd draw a white fate card, and you'd do the reverse if you'd grabbed more black stones than white. I didn't come up with many ideas here; the one idea I had would be that you would either seek redemption if you'd drawn a black card and have to finish at 23 stones with the majority being white, and one for the other way around.
Eventually I liked the light/dark stone idea more than I liked trying to build a Lost game, and I've been working on finding a home for it in its own thing. Ultimately, to me, mechanics should be there to support the story you're trying to tell or the theme you're trying to stick to. Video games are a little harder to build new mechanics and gameplay out of whole cloth, but there are ways to twist more classic game mechanics in a way that serves what you're trying to do.
0
Options
UnbrokenEvaHIGH ON THE WIREBUT I WON'T TRIP ITRegistered Userregular
I haven't gotten very far with any of the various board game ideas I've brainstormed, but...
The majority of the board game ideas I've toyed with have kind of jumped off of me looking at something I already enjoyed, and then taking that and figuring out how to make a game out of it. So, for example, I looked at Lost, which already has a very bad board game, and took a shot at figuring out how to adapt it into some sort of game.
So the first step would be to break it down into some core ideas that I associate with Lost. Things like: survival, fate, choices, light/dark, exploration, mystery, a focus on individual characters. The next step would be to run through some other games I've played, to see if any of them have any mechanics that would fit in with those themes. The official Lost board game was bad, but it had a pretty decent idea, that you would set up a map of hex tiles, face down, and then as you explored, you'd flip them over. Other games have set locations, and you'd draw cards that would give you specific events. As far as survival goes, there are a ton of games where you are, essentially, playing against the game as well as the other players, trying to keep your character alive. The choices/fate dichotomy, though...that was harder to find examples of in board games. Video games have morality systems in place; could something like that be transferred into a board game? How would that affect gameplay? And how would you work something like "fate," or at least Lost's version of fate, into the game?
I never really solved how to represent exploration in the game, but the core of the game would eventually start to emerge as I poked at it, a bit. The main idea would be that as you explored, you would be faced with choices. Some you would have to deal with immediately, others you could sit on for a while. In the process, you would earn white stones, or black stones, to represent the choices you had made. The game could force you into choices you didn't want to make, if you were unlucky; you might need to do terrible things to survive. You'd find other castaways as you'd explore, some would refuse to follow you if you were too light or too dark. At a halfway point, you would draw from a fate deck, giving you a personal goal to complete to end the game. Once you'd received your fifteenth stone, you'd look at the stones you'd drawn: if you had more white, you'd draw a white fate card, and you'd do the reverse if you'd grabbed more black stones than white. I didn't come up with many ideas here; the one idea I had would be that you would either seek redemption if you'd drawn a black card and have to finish at 23 stones with the majority being white, and one for the other way around.
Eventually I liked the light/dark stone idea more than I liked trying to build a Lost game, and I've been working on finding a home for it in its own thing. Ultimately, to me, mechanics should be there to support the story you're trying to tell or the theme you're trying to stick to. Video games are a little harder to build new mechanics and gameplay out of whole cloth, but there are ways to twist more classic game mechanics in a way that serves what you're trying to do.
It's textbook-expensive (but not university-textbook-expensive thankfully) but The Art of Game Design: A Book of Lenses by Jesse Schell talks a lot about the sort of questions you are talking about here. It's the game design book I recommend most, because every time I read through it with a different game idea or game ideas in mind it really gets me thinking about stuff I would have missed otherwise. http://www.amazon.ca/The-Art-Game-Design-Edition/dp/1466598646
Question for anybody: what's your thought process when designing game mechanics (videogame, board game whatever)?
I model everything on past games that I have liked. I pick a favorite game, I study its mechanics in detail, I pick out the ones I think make the game exceptional, I analyze what they did right, where they missed an opportunity, and I try to create a "v2.0" version of the mechanic
i try not to do a direct copy, I always try to add or subtract from the original to make it new
but in terms of mechanics, I also get into technical details.
Something I am big on is character control, and studying character movement and how computer inputs translate into character motion. I think it's an under-appreciated aspect of games and something I take note of in everything I play
You can have huge spectrums of philosophy that are all equally valid... on one end you have something like Warcraft which is virtually total real time character movement with mouselook and keyboard... meaning everything your avatar can physically do is under your direct control, to something like Assassins Creed where you're just mashing and the computer is more or less moving for you
It's fun to try and hybridize these philosophies and see if you can come up with something original
Question for anybody: what's your thought process when designing game mechanics (videogame, board game whatever)?
Given a game mechanic, in what ways can I tweak it? Does tweaking a certain property of the mechanic bring the experience closer to what I want, or away?
For example, take a look at the catching and throwing mechanic in Windjammers, compared to the Xbox Indie game Powerspinners:
The throwing animation in Powerspinners is lengthy, sluggish, and drawn out. Despite rallying the disc as soon as they caught it, the player on the left takes about double the time to throw as the player in Windjammers. In addition, quick responses in Windjammers results in increased disc speed; in Powerspinners, the disc travels at a fixed speed. This negates a large part of the tension you want in a multiplayer, competitive game.
Then look at Lethal League:
The "throw" animation is long, and gets longer as the speed of the projectile increases. In contrast to Powerspinners though, the lengthy animation works in the game's favor; a brief relief from the increasing tension, which serves to further heighten the tension once the projectile is launched.
So, for the catch / throw mechanic, I can tweak a number of properties. I can change how quickly the different animations complete. I can change the speed of the projectile when launched, and what impact speed has on the game environment (in Lethal League, speeds above a certain threshold change the color palate of the stage). I can also modify how easy it is to catch and throw, whether a player needs to hit a button to catch, meaning higher launch speeds create a more difficult game for your opponent, and how much control a player has over the launch speed and movement pattern of the disc.
EDIT: After watching the Lethal League gif some more, it's really well designed. Once the projectile passes the speed threshold, the background changes to a much faster scrolling parallax background, and the speakers start pulsing at a faster rate. Super slick.
I recently went back and revised my collision detection script to make it work better and more efficiently
Most things that move in my game will need to use the collision detection function
And I'm thinking about the best way to do that
One option would be to stick the collision script on every moving object
The other would be to tweak the collision detection a bit, turn it into a function, and add it to the singleton object I have that manages "global" variables, and each object can call that function as necessary
Thing is, I don't know enough about how unity works at a low level to make an informed decision about which is better
Will having lots of objects calling a function in a single script simultaneously slow things down? Will repeating te same script a whole bunch inflate the space the game takes up? I have no idea! I can reasonably imagine either a yes or no answer to both of those questions
Repeating the code does take up more space but the bigger issue is when you want to change things you have to change it everywhere.
Unity doesn't do things simultaneously, it runs one object at time, there is no issue of congestion if everything calls the same function.
Are you sure about the having to change everything everywhere though? Wouldn't you just have to edit the contents of the script? I suppose if you change what Midna of variables you need you'd have to go through and edit those variables in each object, but that's also true if you're just using one function that gets called by different objects
I recently went back and revised my collision detection script to make it work better and more efficiently
Most things that move in my game will need to use the collision detection function
And I'm thinking about the best way to do that
One option would be to stick the collision script on every moving object
The other would be to tweak the collision detection a bit, turn it into a function, and add it to the singleton object I have that manages "global" variables, and each object can call that function as necessary
Thing is, I don't know enough about how unity works at a low level to make an informed decision about which is better
Will having lots of objects calling a function in a single script simultaneously slow things down? Will repeating te same script a whole bunch inflate the space the game takes up? I have no idea! I can reasonably imagine either a yes or no answer to both of those questions
My approach would be to have the collision detection stuff on a base type and have all my other classes inherit it.
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
Putting a function in a singleton and having everything call it isn't terribly object-oriented, since it seems to be a functionality that should exist for those objects regardless of whether the singleton exists or not. The "proper" approach would be to add the collision detection function to whatever base class all the objects are inheriting from, but you probably don't want to add it to gameObject. You could make a movableObject class that inherits from gameObject and implements your collision detection, but unnecessarily long inheritance trees can be as stupid to work with as overly tasked singletons.
Posts
http://www.audioentropy.com/
for the fuck of it i set the orthographic size to 113
which in theory should make the problem worse, because now the camera is no longer a perfect 16:9 aspect ratio
but
that appears to have solved the problem
whatever i guess
http://www.audioentropy.com/
In other news, my phone interview with Blizzard went well! They had me send them some Python samples a few days later. I feel real bad about my Python style
I guess they are really into rapid prototyping before cranking out crazy polished assets
Tools development, actually! I'd be making stuff whenever their VFX artists are like "I wish we could do this thing we can't do
I don't think it's possible to write good-style Python.
Unity's units are set in the middle of a pixel instead of the topleft, so it's probably something to do with that. I thought the UI and canvas stuff added in 4.6 made it easier to do perfect 2D sprites but I haven't messed with it.
Alternately, I think it's impossible to really write bad-style Python.
Tools programmers are my favourite, favourite people.
The first thing I'm going to say to blizzard people when I deliver a tool is "I hope you like my invention"
followed by "I feel icky" and then I'll take the rest of the day off
Prior to learning Python, I tabbed a line of code depending on how important I thought it was. This line's crucial to the function? Tab that sucker 5 or 6 times
Python killed that habit (duh) but now I use sorta use blank lines to do the same thing
If you really gotta highlight an important bit, use a comment.
It has the added bonus of explaining what the important bit does.
I comment the crap out of my code. I'm looking at a 600-line file right now and the first 30 lines are dedicated to describing the file (summary of function, TODO, known issues) and within the body of the file I summarize each class/function with a few lines at the very least, and at most roughly "half" of a function is comments.
Wow, that would confuse the crap out of me. Indentation for me (and I think most people) is all about how deeply it's nested in another block, so the flow of execution is clear.
I do use blank lines to kind of separate out different chunks of code - sometimes I'll find myself putting blank lines between everything though, I'm not sure if that means I'm writing good code (performing a lot of encapsulated functions) or not.
Be careful not to over-comment. Unless you use an external tool to gather documentation (like doxygen as an example) or to help with IDE pop-ups, the code itself should tell you what it is doing.
Comments should be then left for the why.
I took an intro python course as a GPA booster this year and probably agree with the sentiment that it's hard to write good OR bad python code, it just sort of exists
I also want to work out a better solution for lighting, particularly with directional sunlight so I can do a day/night cycle. I have a couple of ideas but I'm really not comfortable with the math, etc in that area so the ideas are probably terrible and inefficient. I guess we'll see!
After a LOT of wrangling I finally have it... Mostly working. 99% of the time everything works exactly like it should, but every now and then the player character goes in on too steep of an angle on one frame and gets slightly lodged into the slope and I got no clue why
Right now the collides in the sloped surfaces ar just straight lines that touch the convex vertices of the shape (the sprite is pixel art so it has jagged edges). I'm wondering if it would be better, worse, or no different to go in and manually make the collider perfectly fit to the sprite's stair-step edges
http://www.audioentropy.com/
But if you're making something moderately large that you have to share with other people it is a nightmare.
Dynamic typing sounds neat at first but it really hurts readability, since static typing basically self-documents your code, telling what types you can shove into what methods.
okay thinking about it
stair-stepping the edges would make the script work perfectly
but i do have a question because like
if i have a lot of slanted surfaces that will make the number of collider vertices in the scene go up fast
like i'm testing this with a large square tilted at a 45 degree angle, which is 48x48 pixels in size
and because each pixel has both a convex and concave vertex that needs to be accounted for, that means that the collider on it has to have 96 x 4 or... 384 vertices
thinking about it that represents 384 2D vectors, which is 768 floats, and if a float is 4 bytes, then that means 3072 bytes
which
i lack a strong enough understanding of how memory works to tell whether that's too much
I can imagine that both being exhorbitant and being a drop in the bucket
someone who's better with the technical end of things have some advice?
right now I just have a 4-vertex collider on it, and like I said, that works like... the majority of the time. So adding so many more vertices to move from "mostly works" to "definitely always works perfectly" seems... dumb
http://www.audioentropy.com/
but at the same time it's not like the game is the only application running
http://www.audioentropy.com/
http://www.audioentropy.com/
it would be worse. not sure how much of your movement is steeped in 3D unity but ordinarily you would want to be bounds checking all the time on what you're sliding against and make it functionally impossible for your character to ever be "in" the slope
Do any of you prototype your games on paper first?
You should! It's a bunch of fun and saves a metric ton of programming!
It turns out that when you're doing nested if statements it's important to nest them, you know
Correctly
http://www.audioentropy.com/
This is solved by even a little bit of decent commenting. We use Python for large portions of our tool chain, and as long as everyone's writing code from the perspective that other people will have to consult and modify it, things work out okay. Python is the best.
Also there's no such thing as over-commenting. Give me PARAGRAPHS about what you're doing and why.
I am finding that, in looking at other games, the games that try to build complexity by having a whole bunch of components and stats and things don't really work for me as well, mostly because, anymore I'm the one that ends up explaining things. And I also don't really like games with win conditions that feel...arbitrary.
Like, I have Middle Earth Quest, and explaining the win condition in that game is an exercise in madness. The gameplay mostly works, but it's hard to really tell what you're working towards. And maybe that works for some people, but it's hard to get anyone interested in playing it in our group.
my small team have been playtesting a card game with proxies for a while now. good way to learn what decisions/cards were awful before committing to moving forward
The majority of the board game ideas I've toyed with have kind of jumped off of me looking at something I already enjoyed, and then taking that and figuring out how to make a game out of it. So, for example, I looked at Lost, which already has a very bad board game, and took a shot at figuring out how to adapt it into some sort of game.
So the first step would be to break it down into some core ideas that I associate with Lost. Things like: survival, fate, choices, light/dark, exploration, mystery, a focus on individual characters. The next step would be to run through some other games I've played, to see if any of them have any mechanics that would fit in with those themes. The official Lost board game was bad, but it had a pretty decent idea, that you would set up a map of hex tiles, face down, and then as you explored, you'd flip them over. Other games have set locations, and you'd draw cards that would give you specific events. As far as survival goes, there are a ton of games where you are, essentially, playing against the game as well as the other players, trying to keep your character alive. The choices/fate dichotomy, though...that was harder to find examples of in board games. Video games have morality systems in place; could something like that be transferred into a board game? How would that affect gameplay? And how would you work something like "fate," or at least Lost's version of fate, into the game?
I never really solved how to represent exploration in the game, but the core of the game would eventually start to emerge as I poked at it, a bit. The main idea would be that as you explored, you would be faced with choices. Some you would have to deal with immediately, others you could sit on for a while. In the process, you would earn white stones, or black stones, to represent the choices you had made. The game could force you into choices you didn't want to make, if you were unlucky; you might need to do terrible things to survive. You'd find other castaways as you'd explore, some would refuse to follow you if you were too light or too dark. At a halfway point, you would draw from a fate deck, giving you a personal goal to complete to end the game. Once you'd received your fifteenth stone, you'd look at the stones you'd drawn: if you had more white, you'd draw a white fate card, and you'd do the reverse if you'd grabbed more black stones than white. I didn't come up with many ideas here; the one idea I had would be that you would either seek redemption if you'd drawn a black card and have to finish at 23 stones with the majority being white, and one for the other way around.
Eventually I liked the light/dark stone idea more than I liked trying to build a Lost game, and I've been working on finding a home for it in its own thing. Ultimately, to me, mechanics should be there to support the story you're trying to tell or the theme you're trying to stick to. Video games are a little harder to build new mechanics and gameplay out of whole cloth, but there are ways to twist more classic game mechanics in a way that serves what you're trying to do.
It's textbook-expensive (but not university-textbook-expensive thankfully) but The Art of Game Design: A Book of Lenses by Jesse Schell talks a lot about the sort of questions you are talking about here. It's the game design book I recommend most, because every time I read through it with a different game idea or game ideas in mind it really gets me thinking about stuff I would have missed otherwise. http://www.amazon.ca/The-Art-Game-Design-Edition/dp/1466598646
I model everything on past games that I have liked. I pick a favorite game, I study its mechanics in detail, I pick out the ones I think make the game exceptional, I analyze what they did right, where they missed an opportunity, and I try to create a "v2.0" version of the mechanic
i try not to do a direct copy, I always try to add or subtract from the original to make it new
but in terms of mechanics, I also get into technical details.
Something I am big on is character control, and studying character movement and how computer inputs translate into character motion. I think it's an under-appreciated aspect of games and something I take note of in everything I play
You can have huge spectrums of philosophy that are all equally valid... on one end you have something like Warcraft which is virtually total real time character movement with mouselook and keyboard... meaning everything your avatar can physically do is under your direct control, to something like Assassins Creed where you're just mashing and the computer is more or less moving for you
It's fun to try and hybridize these philosophies and see if you can come up with something original
Given a game mechanic, in what ways can I tweak it? Does tweaking a certain property of the mechanic bring the experience closer to what I want, or away?
For example, take a look at the catching and throwing mechanic in Windjammers, compared to the Xbox Indie game Powerspinners:
The throwing animation in Powerspinners is lengthy, sluggish, and drawn out. Despite rallying the disc as soon as they caught it, the player on the left takes about double the time to throw as the player in Windjammers. In addition, quick responses in Windjammers results in increased disc speed; in Powerspinners, the disc travels at a fixed speed. This negates a large part of the tension you want in a multiplayer, competitive game.
Then look at Lethal League:
The "throw" animation is long, and gets longer as the speed of the projectile increases. In contrast to Powerspinners though, the lengthy animation works in the game's favor; a brief relief from the increasing tension, which serves to further heighten the tension once the projectile is launched.
So, for the catch / throw mechanic, I can tweak a number of properties. I can change how quickly the different animations complete. I can change the speed of the projectile when launched, and what impact speed has on the game environment (in Lethal League, speeds above a certain threshold change the color palate of the stage). I can also modify how easy it is to catch and throw, whether a player needs to hit a button to catch, meaning higher launch speeds create a more difficult game for your opponent, and how much control a player has over the launch speed and movement pattern of the disc.
EDIT: After watching the Lethal League gif some more, it's really well designed. Once the projectile passes the speed threshold, the background changes to a much faster scrolling parallax background, and the speakers start pulsing at a faster rate. Super slick.
My Steam
I recently went back and revised my collision detection script to make it work better and more efficiently
Most things that move in my game will need to use the collision detection function
And I'm thinking about the best way to do that
One option would be to stick the collision script on every moving object
The other would be to tweak the collision detection a bit, turn it into a function, and add it to the singleton object I have that manages "global" variables, and each object can call that function as necessary
Thing is, I don't know enough about how unity works at a low level to make an informed decision about which is better
Will having lots of objects calling a function in a single script simultaneously slow things down? Will repeating te same script a whole bunch inflate the space the game takes up? I have no idea! I can reasonably imagine either a yes or no answer to both of those questions
http://www.audioentropy.com/
Unity doesn't do things simultaneously, it runs one object at time, there is no issue of congestion if everything calls the same function.
http://www.audioentropy.com/
http://www.audioentropy.com/
Having the one instance still seems a bit more convenient so I'll go with that
http://www.audioentropy.com/
My approach would be to have the collision detection stuff on a base type and have all my other classes inherit it.