It's a box... you put stuff in it.
Sister gets married
Who's taking whose picture?
Saturday, May 30, 2009
Sunday, May 24, 2009
Friday, May 22, 2009
Monday, May 18, 2009
Star Trek, Logical Smogical
Why such a big red ball when a little one would do?
Why are Romulan mining ships so bad ass?
Why be so vengeful when you could go save your planet?
Why bother with ships if you can teleport across the galaxy?
Why a giant red crab monster on an ice planet? And why not very coordinated on ice, its only lived there its whole life.
Why drill a hole to the core when you don't need to?
What would happen if the whole ball went up? Oh... just that?
Who's going to save the whales now?
How did, a group of miners on a mining ship mind you, they know when Spock would arrive through his time travel trip through a black hole? Is there some standard function for determining when he would arrive?
Where do you hide a ship for 25 years so the federation can't find it?
BTW, I really enjoyed the movie. It was great, even with these nagging questions.
Why are Romulan mining ships so bad ass?
Why be so vengeful when you could go save your planet?
Why bother with ships if you can teleport across the galaxy?
Why a giant red crab monster on an ice planet? And why not very coordinated on ice, its only lived there its whole life.
Why drill a hole to the core when you don't need to?
What would happen if the whole ball went up? Oh... just that?
Who's going to save the whales now?
How did, a group of miners on a mining ship mind you, they know when Spock would arrive through his time travel trip through a black hole? Is there some standard function for determining when he would arrive?
Where do you hide a ship for 25 years so the federation can't find it?
BTW, I really enjoyed the movie. It was great, even with these nagging questions.
Sunday, May 17, 2009
Two Weeks of Class
The week before last, Week 2, in my GSP-380 class we had to get OpenGL to render a rotating diamond shape with a light source. The image shows the result with a function being called to draw the triangle normals.
This last week was about DirextX. I don't know if I like DirectX. I think I approached it wrong, since I have some experience with OpenGL it seems really foreign. Regardless, for the assignment I had to get three spheres rotating around each other, like the sun, earth moon.
This last week was about DirextX. I don't know if I like DirectX. I think I approached it wrong, since I have some experience with OpenGL it seems really foreign. Regardless, for the assignment I had to get three spheres rotating around each other, like the sun, earth moon.
Thursday, May 14, 2009
4 wheels
Grandpa and Grandma got the boys a four wheeler. Its a little too fast or underpowered though, depending on the speed controll, but Aidan still liked it.
Thursday, May 7, 2009
Sales Slump
The idea that you can just drop your game in the iTunes App Store and make millions is probably a fallacy. Perhaps with the right marketing, and a good circle of friends and family, and a little luck, it is possible. I think we may have lost our chance for momentum. To my credit, I haven't done this before.
Here's a little detail on how the game, Board@Work, is doing. Its not as hot as I had hoped it would be. I found this cool website called MobClix that does some tracking. Below is a picture of it, along with our sales figures.
Apple takes a day to let you know about sales, so I'm hoping this gives a little insight into the future. Essentially, after a big slump on the 5th, we've started to climb. According to the ranking, its higher than previous so hopefully that trend will continue.
I think its a fun game, but I can understand why people might not give it a chance. I think
I've sent some free codes to some of the podcasts I listen to and enjoy the most, hopefully that will pan out. I've sent codes to Chad and the gang at the Video Game Show and Lono at his new gig, Respawn Radio. If we get mentioned, we may be able to get some traction.
Here's a little detail on how the game, Board@Work, is doing. Its not as hot as I had hoped it would be. I found this cool website called MobClix that does some tracking. Below is a picture of it, along with our sales figures.
Apple takes a day to let you know about sales, so I'm hoping this gives a little insight into the future. Essentially, after a big slump on the 5th, we've started to climb. According to the ranking, its higher than previous so hopefully that trend will continue.
I think its a fun game, but I can understand why people might not give it a chance. I think
I've sent some free codes to some of the podcasts I listen to and enjoy the most, hopefully that will pan out. I've sent codes to Chad and the gang at the Video Game Show and Lono at his new gig, Respawn Radio. If we get mentioned, we may be able to get some traction.
Monday, May 4, 2009
LOD Calculations
The other day a coworker was asking me some modeling questions and I started spilling my philosophy like usual. He said he aims for 5 LODs (Levels of Detail) on his models. In my opinion, in the work we do, 5 is overkill. In fact, having too many LODs can hurt performance because that's 5 checks per model to determine which LOD to use (unless its a hierarchy driven LOD system, which maybe I'll get into in another post).
We eventually started talking about how to model smartly with appropriate LODs. I asked him what distances he was using in relation to his polygon counts.
The most basic concept for an LOD is that you switch a High Level Of Detail (HLOD) model with a simpler, lower detail model (fewer polygons generally speaking). The switch is usually instantaneous at a specified distance from the viewer. For instance, you may have a tree which is HLOD close to the camera. At 100 feet say, the models swaps out with a simpler model. And so on as you move further away. Eventually you can't see the model at all, so it can be completely hidden. The question you are probably asking is, how do you know when to switch those models?
The answer I've come up with requires some assumptions, some math and some basic information about your scene setup. I generally aim for 3 LODs at most, but this is arguable depending on model usage. Personally, I think less is better because it makes the modeler do more with less so to speak.
Here's what you need to determine:
- What is your desired Field of View (FOV)?
- What is your screen resolution?
- What is the size of your geometry?
- How big should the model be on screen when it switches LODs?
What is your desired Field of View (FOV)? I wont get into what FOV is here, but its basically the "zoom" of your camera. A narrow field of view, or smaller number, means the view is more telescopic, like binoculars. A large value, less than 180 degrees, is like a fish eye lens. To put it in perspective (no pun intended), in the first person shooter Call of Duty 4 the default FOV is 65 degrees. Call this value F.
What is your screen resolution? We could get fancy here, but I'm only interested in the horizontal number of pixels. A HD monitor would be 1920 pixels wide. Call this value R.
What is the important size of your geometry, S? Now models are not square, so what do I mean by size? Well, that's sorta up to you. Personally, I usually take into consideration how I expect to see the model. An airplane for instance might be long and wide, but not much height. Personally, I usually just take the largest value in relation to how I expect to see the model. For an airplane in a dogfight game I would use the wingspan, but for a game where you are on the ground, I would use the height since at larger distances that's how you'll most likely see them. Call this value S.
When should the LODs switch, or to put it another way, at what pixel width do you want the model to switch out? Call this value P.
Now here is the math part, I'll use a 25 foot tall tree with a diameter of around 8 feet as an example. The important size is its width because that is the bulk of the model, so S = 8. We'll start out by determining when can we hide the model completely? Let's assume we want to see that tree model until its screen presence is only, at most, 2 pixels wide. At that distance, we feel we can remove the model from the scene completely. At what distance would that tree model be represented by, at most, 2 pixels on the screen? Here's how you determine that distance:
Distance = S * R / ( P * 2 * tan( FOV / 2 ) )
For our 25 x 8 foot tree model:
Distance = 8ft * 1920pixels / ( 2pixels * 2 * ( 65deg / 2 ) )
Distance = 6028 feet
Wow! That's really far. So do you really want that tree to be visible up to that distance? If so, what does the model need to look like to represent that tree at that distance? Not much, its only 2 pixels big at this distance after all. You'd have a hard time distinguishing a 500 polygon model from a single triangle. Ultimately that's my point. In my experience, people model their low level of detail modes with too much detail. This method allows some insight into how to model as well as determining LOD ranges.
So now what? You need to determine the amount of detail you want on the screen and at what distance it is important to show it. If your LODs aren't constructed this way, you could be wasting a lot of performance.
For the tree, I assumed that when it reached 10% of the screen width (192 pixels), I want it to be its highest LOD. That corresponds with roughly 60 ft distance. From there to 2.5% screen width (50 pixels) is the medium LOD at 250 ft. The lowest LOD goes from there to 5 pixels, turning off at 2500 feet. Its debatable if you would want to divide this 3rd LOD further, vs trade polygons between the bottom two LODs. What I mean is that as the lowest LOD fades out to the distance, its polygons are less important. Depending on how you expect to see and use this tree model, you may want another LOD, or alternatively you can make the middle LOD last longer, essentailly allowing you to drastically reduce the lowest level of detail.
That brings me to my other point. This formula can also provide a modeler with a sense of what is important. Details that a modeler may include can be justifiably removed if their size in relation to their screen presence proves them useless, especially regarding reduction for LODs.
Of course, many engines today do more than just calculate specified distances. They can balance based on performance, allowing more detail if the frame rate doesn't suffer.
| The basic idea of LODs is that as a model moves further away from your observer, the model's complexity decreases so you can gain some performance. |  |
The most basic concept for an LOD is that you switch a High Level Of Detail (HLOD) model with a simpler, lower detail model (fewer polygons generally speaking). The switch is usually instantaneous at a specified distance from the viewer. For instance, you may have a tree which is HLOD close to the camera. At 100 feet say, the models swaps out with a simpler model. And so on as you move further away. Eventually you can't see the model at all, so it can be completely hidden. The question you are probably asking is, how do you know when to switch those models?
The answer I've come up with requires some assumptions, some math and some basic information about your scene setup. I generally aim for 3 LODs at most, but this is arguable depending on model usage. Personally, I think less is better because it makes the modeler do more with less so to speak.
Here's what you need to determine:
- What is your desired Field of View (FOV)?
- What is your screen resolution?
- What is the size of your geometry?
- How big should the model be on screen when it switches LODs?
What is your desired Field of View (FOV)? I wont get into what FOV is here, but its basically the "zoom" of your camera. A narrow field of view, or smaller number, means the view is more telescopic, like binoculars. A large value, less than 180 degrees, is like a fish eye lens. To put it in perspective (no pun intended), in the first person shooter Call of Duty 4 the default FOV is 65 degrees. Call this value F.
What is your screen resolution? We could get fancy here, but I'm only interested in the horizontal number of pixels. A HD monitor would be 1920 pixels wide. Call this value R.
What is the important size of your geometry, S? Now models are not square, so what do I mean by size? Well, that's sorta up to you. Personally, I usually take into consideration how I expect to see the model. An airplane for instance might be long and wide, but not much height. Personally, I usually just take the largest value in relation to how I expect to see the model. For an airplane in a dogfight game I would use the wingspan, but for a game where you are on the ground, I would use the height since at larger distances that's how you'll most likely see them. Call this value S.
When should the LODs switch, or to put it another way, at what pixel width do you want the model to switch out? Call this value P.
Now here is the math part, I'll use a 25 foot tall tree with a diameter of around 8 feet as an example. The important size is its width because that is the bulk of the model, so S = 8. We'll start out by determining when can we hide the model completely? Let's assume we want to see that tree model until its screen presence is only, at most, 2 pixels wide. At that distance, we feel we can remove the model from the scene completely. At what distance would that tree model be represented by, at most, 2 pixels on the screen? Here's how you determine that distance:
Distance = S * R / ( P * 2 * tan( FOV / 2 ) )
For our 25 x 8 foot tree model:
Distance = 8ft * 1920pixels / ( 2pixels * 2 * ( 65deg / 2 ) )
Distance = 6028 feet
Wow! That's really far. So do you really want that tree to be visible up to that distance? If so, what does the model need to look like to represent that tree at that distance? Not much, its only 2 pixels big at this distance after all. You'd have a hard time distinguishing a 500 polygon model from a single triangle. Ultimately that's my point. In my experience, people model their low level of detail modes with too much detail. This method allows some insight into how to model as well as determining LOD ranges.
So now what? You need to determine the amount of detail you want on the screen and at what distance it is important to show it. If your LODs aren't constructed this way, you could be wasting a lot of performance.
For the tree, I assumed that when it reached 10% of the screen width (192 pixels), I want it to be its highest LOD. That corresponds with roughly 60 ft distance. From there to 2.5% screen width (50 pixels) is the medium LOD at 250 ft. The lowest LOD goes from there to 5 pixels, turning off at 2500 feet. Its debatable if you would want to divide this 3rd LOD further, vs trade polygons between the bottom two LODs. What I mean is that as the lowest LOD fades out to the distance, its polygons are less important. Depending on how you expect to see and use this tree model, you may want another LOD, or alternatively you can make the middle LOD last longer, essentailly allowing you to drastically reduce the lowest level of detail.
That brings me to my other point. This formula can also provide a modeler with a sense of what is important. Details that a modeler may include can be justifiably removed if their size in relation to their screen presence proves them useless, especially regarding reduction for LODs.
Of course, many engines today do more than just calculate specified distances. They can balance based on performance, allowing more detail if the frame rate doesn't suffer.
Sunday, May 3, 2009
GSP 380 Week 1 Complete
I just finished my homework for week 1 of GSP 380, Multimedia Programming with Lab. This week it was pretty simple though I'm really looking forward to the weeks ahead.
This week I had to get VS 2008 Express and the DirectX SDK installed and then compile and run two programs, one using DirectX and one using OpenGL.
For the OpenGL assignment we had to modify the program, which is why you see a different color and an extra triangle.
This week I had to get VS 2008 Express and the DirectX SDK installed and then compile and run two programs, one using DirectX and one using OpenGL.
For the OpenGL assignment we had to modify the program, which is why you see a different color and an extra triangle.
More Board
Ben wrote on the Touch Arcade Forums something that I think is worth sharing, and getting it out so it doesn't get buried in a forum post.
Quote:
Just wanted to give a little background on the game... When we set out to make this game, we fully realized that there were a ton of match 3 style apps in the App Store. But, we didn't feel that any of them took it to the next level of fun... Some of the match 3s out there feel more like a chore than a game.
So, Ryan and I each came up with a ton of ideas on what could make such a classic game style (match 3) as fun as possible. We tested out a lot of different game play methods and different power-ups, and ended up getting rid of a lot of our ideas as they didn't add to the fun or strategy. What we ended up with was a bit of Tetris, in that the blocks keep coming at a set interval, mixed with name your favorite match 3 (Bejeweled, Trism, whatever), but with power-ups that actually are useful and make sense. We feel the useful/strategic power-ups (office supplies) are a very unique feature in the match 3 genre - not many have power-ups and those that do seem like they were an afterthought in the development of the game...
We also brainstormed on a lot of theme concepts - Ryan started off with a design concept of the game as if it were played on graphing paper, which got a lot of discussion started, but we went through a few different concepts that were more iPhone-standard design concepts, where the artwork would look great, but wouldn't have done anything to set it apart. Then we hit upon an epiphany based off of Ryan's initial idea and our thinking that there wasn't enough humor found in the App Store. So, we ended up with an "office" theme that we feel (obvious bias) fits well with both the game and the humor element. We took inspiration from some of our favorite movies/shows such as Office Space and The Office as far as the style of humor goes.
We had the game play code and 90% of the graphics finished almost two months ago, and could've submitted to the App Store then, but we just didn't think we had the game balance just right nor the game's polish completely right. Basically, the past couple of months has been spent getting the balance right and really make the theme fit and add the polish to the finished product we wanted. We could've released it a couple of months ago, but it wouldn't have met the goals that we had when we set out to make the game - taking a classic game play genre/style (match 3) to the next level while adding some serious strategy elements and having a solid theme...
We're quite proud of this game and so far the feedback we've gotten has been even more positive than we expected... The best compliment we've received so far is, "Wow! didn't think I could get addicted to a game like this but i keep saying "one more time" i'm having a hard time putting it down - thanks!" The negative comments have been almost exclusively about there not being tons of players in the multiplayer mode, but it did just come out today...
Anyway, sorry for the long post, but just wanted to let everyone know what went into the game and our thought processes and goals. Maybe it sells 10, maybe it sells 1,000,000, who knows?
If you have comments or constructive criticism, please email comments@spigotgames.com and let us know... We're always looking for constructive criticism to make our games even better - we may even make you a beta tester in the future...
Thanks again,
Ben
Quote:
Just wanted to give a little background on the game... When we set out to make this game, we fully realized that there were a ton of match 3 style apps in the App Store. But, we didn't feel that any of them took it to the next level of fun... Some of the match 3s out there feel more like a chore than a game.
So, Ryan and I each came up with a ton of ideas on what could make such a classic game style (match 3) as fun as possible. We tested out a lot of different game play methods and different power-ups, and ended up getting rid of a lot of our ideas as they didn't add to the fun or strategy. What we ended up with was a bit of Tetris, in that the blocks keep coming at a set interval, mixed with name your favorite match 3 (Bejeweled, Trism, whatever), but with power-ups that actually are useful and make sense. We feel the useful/strategic power-ups (office supplies) are a very unique feature in the match 3 genre - not many have power-ups and those that do seem like they were an afterthought in the development of the game...
We also brainstormed on a lot of theme concepts - Ryan started off with a design concept of the game as if it were played on graphing paper, which got a lot of discussion started, but we went through a few different concepts that were more iPhone-standard design concepts, where the artwork would look great, but wouldn't have done anything to set it apart. Then we hit upon an epiphany based off of Ryan's initial idea and our thinking that there wasn't enough humor found in the App Store. So, we ended up with an "office" theme that we feel (obvious bias) fits well with both the game and the humor element. We took inspiration from some of our favorite movies/shows such as Office Space and The Office as far as the style of humor goes.
We had the game play code and 90% of the graphics finished almost two months ago, and could've submitted to the App Store then, but we just didn't think we had the game balance just right nor the game's polish completely right. Basically, the past couple of months has been spent getting the balance right and really make the theme fit and add the polish to the finished product we wanted. We could've released it a couple of months ago, but it wouldn't have met the goals that we had when we set out to make the game - taking a classic game play genre/style (match 3) to the next level while adding some serious strategy elements and having a solid theme...
We're quite proud of this game and so far the feedback we've gotten has been even more positive than we expected... The best compliment we've received so far is, "Wow! didn't think I could get addicted to a game like this but i keep saying "one more time" i'm having a hard time putting it down - thanks!" The negative comments have been almost exclusively about there not being tons of players in the multiplayer mode, but it did just come out today...
Anyway, sorry for the long post, but just wanted to let everyone know what went into the game and our thought processes and goals. Maybe it sells 10, maybe it sells 1,000,000, who knows?
If you have comments or constructive criticism, please email comments@spigotgames.com and let us know... We're always looking for constructive criticism to make our games even better - we may even make you a beta tester in the future...
Thanks again,
Ben
Saturday, May 2, 2009
App StoreFriday, May 1, 2009
Subscribe to:
Posts (Atom)
Posts
