I built some custom editor extensions in Unity to help me make geometry for use in level creation.
I’ve had an awesome project at work developing a simulation in Unity3D that builds a test track, a road essentially, right before your eyes. Technically, we’re using some pretty hefty data, including OpenCRG and Power Spectral Density data as inputs, but I also added a lower weight random algorithm that can make for some roads more appropriate for game play.
In the image above you can see a long length of track that I generated with a few inputs. Additionally, it creates road rails to help keep the vehicle on the road. It also creates a simple ditch on each side of the road from a simple profile. Additional options include material selection, which changes the road appearance.
It’s not often that I get to share stuff from work, but this is only a taste of what it can do. The project will eventually be released to the public. Hopefully some day I can share a video of everything it does.
The vehicles are from the Car Tutorial project provided by Unity.
You guys, Anthony Carboni over at AppJudgement recently reviewed Battery Powered Games’ Deadly Chambers for Android devices.
WAIT, don’t click play yet!
The review isn’t favorable even though Anthony is giving it the 5 finger solute there. In fact, considering all the positive reviews and comments we’ve gotten its surprising the level of which Anthony dislikes Deadly Chambers. If only he knew how much time I spent watching Bytejacker and playing Free Indie Rapid Fire games instead of working on level designs, improving textures and character animations… All the time I spent watching him with enjoyment and laughter, now replaced with a sour taste and sadness… He really didn’t seem to like the game. Oh Anthony!!! NOOOOOO!
We are really honored to be reviewed by AppJudgement, don’t get me wrong. I’ve been watching them for over a year now and I’ve come to enjoy their productions and trust their reviewers (was hoping for Jackie to review to be honest, no offense Anthony). I don’t know if Anthony, or the AppJudgement team got my requests for review, or if he found it as he stated (which would be awesome), but being noticed is a plus in and of itself. Even after the review I still love you Anthony, and we are taking many of your thoughts to heart. (WTF, ByteJacker biweekly, you suck! I mean that in the most positive way! I miss you.)
With that said, I have a few major contentions with his review. First off, he sets the stage by saying “a little gaming action for my hardcore friends.” Deadly Chambers was never intended as a “hardcore game”. It was designed to be a casual shooter, to give you a few minutes of shoot-the-bad-guys fun, and was designed accordingly. It is made for a phone device after all. We did decide to support the more hardcore gamer types by adding a lot of unlockable guns, achievements and a tough “Deadly” difficulty of course, but the designed and intended average time to play a level is pretty quick once you get used to it. Anthony reviewed Deadly Chambers as if it were intended for hardcore gamers so its no wonder he wasn’t satisfied. Additionally, he was comparing it to iPhone games. That isn’t a problem mind you, because its at least a more fair comparison than comparing it to Xbox360 or PS3 shooters and is appropriate, but it doesn’t really matter if you only have an Android Phone. What he also failed to mention was the total lack of any quality 3D shooters available in the Android Market because he was comparing it to iPhone games. If games like Deadly Chambers were easy to make, the market would be flooded with them. Deadly Chambers is one of a kind, for better or worse. It is not NOVA (ported to Android, and whose heard of it other than the hardcore), it is not Quake (this is an OLD PC game remember), and its not supposed to be!
Secondly, he never mentions the bosses. The majority of the game design came in the form of boss fights. From an angry Ogre who can repel your attacks with a giant smiley face shield, a giant spider knight, a mechanized robot with Gatling gun arms whose pilot is its only week point, and a giant dragon that flies around shooting fire at you in a huge castle. The game’s boss fights add much to the game as a whole and he never mentioned them. In the game there are 5 enemy models and 6 boss models. Sure, the room to room design isn’t the best and the AI of those monsters isn’t top notch, but he didn’t even mention the level bosses. You shouldn’t say something like “enemy AI is simplistic and slow” and ignore the bosses, which he does. (See how mad the Ogre is there, waving his wooden hammer!)
Other little things…
The levels are “bland and boxy” and the characters are “simple”. This is so very true, and Anthony goes on later in his video to express the potential fragmentation problem related to this which is also exactly true. To support the myriad of Android devices and OS versions, we were forced to aim lower than I, as the artist and partial designer, would like. However, given that the game has 5 levels, 11 character models, 18 guns and a shit-ton of other images (that is artist talk for amazing Photoshop skillz), all jammed into a 7MB file, its f’ing impressive and I’m super studly for making that possible! Add to that the fact that it runs on so many devices is a testament to the design. We could have made a killer shooter if we target a few phones, Anthony is dead to rights about that, but we would have been ignoring a large portion of the Android audience. Ultimately though, shouldn’t this sort of approach be praised instead of condoned. Robert (Battery Powered Games owner, president, etc., etc.) was adamant about supporting older phones (older OSs, back to 1.6) and I eventually came around to his way of thinking (because he’s right). Its too big a market to over look, especially at the date of our release. I’m still sporting my G1 for crying out loud! This also correlates tremendously to sales as well as recognition.
One of the major issues with the game is its controls. I for one, have tested on a number of devices, and perhaps I’ve grown accustomed to its quirks, but it works well for me. However, supporting so many devices causes a whole bunch of unfortunate problems too. Problems that I wish were not there and cause us headaches and stars in the ratings (X10 and Moment for instance). I wont really get into this because its a loosing battle and I’m half drunk, but part of the blame falls on the player, but most of the blame falls onto the Android hardware. Don’t believe me? Go to the Application Market and download the some of the Multitouch test apps (Multitouch Visibility Test and Multitouch Paint are a both good ones) and use them in a way you think controls should/could work and see what happens. Here’s a video on the Nexus 1 and Droid just for reference. The ultimate problem is that since the Nexus 1 and the Droid both support the same OS, but the touch interface behaves differently and you can’t really target a phone directly, you’re stuck deciding how to deal with the fallout (bad reviews because phone don’t work vs. trying to make it right for one device.)
What saddens me most is that I seriously doubt Anthony played much of the game and this is evident in the video. There are hardly any achievement unlocks and no video past the third level. Some of the complaints about simple models and levels are true, but once you get to the Castle or the Tower levels (levels 4 and 5) I think the levels are outstanding in comparison. The models also get better. I admit, this shooter isn’t the 3D Jesus we’re all hoping for, but its a step in the right direction. With some actual, honest, unbiased and unrushed gameplay, I think its a solid game worth a look. One worthy of more than the 10 minutes it takes to get to level 3.
Anthony also mentions the characters sliding and twisting awkwardly around the screen, which admittedly is very noticeable. It’s also one of those things that I notice and you know where else this is noticable? Fallout 3 and Fable 2, both of which have characters that when running around the environment don’t seem to be quite right. I will admit I giggled a little at his reference to Dr. Chambers’ running animation looking like something like a puppet from Team America. This was one of those things that I wanted to fix, but ultimately was good enough for what it was. Not too bad for 8 keyframes really. (Still bugs me deep in my core, but not enough to do something about apparently…)
In the end, we are being compared to NOVA and even Rage by AppJudgement, a reputable and respectable organization and I appreciate their time and effort in their review. I respect Anthony and we are taking his, and every other reviewer, blog, fan or mutant out there who took the time to give us a chance, comments to heart. In the end, you should watch Anthony’s review because he is good at what he does and I’m all sorts of jealous. Sometimes I wish A-Train wasn’t dead… (Insert inside joke here… wait, I already did.)
Oh, and BTW, we’ve started working on our next game and its going to be awesome!
This is my newest creation. If all goes well, it will be added to Deadly Chambers. It is a shotgun that shoots lasers!
It was made using Blender and Photoshop. I rendered an AO layer and saved it, then a light layer, the blue glow, by rendering only the light on a dark material to the same UV map. I combined them in photoshop with some metal textures, photos, hand painting and some layer effects. I really like how it turned out.
This is the lightmap layer of the tower level for the game I’m working on with Rob of Battery Powered Games. This is the final level, the Tower, where the big show down with a magical wizard takes place. The game should be out in a month (estimated release second week of May, 2010). It’s called [NAME TBD].
I’ve been using blender solidly for about half a year now and I have developed a number of tricks. My favorite trick thus far is baking textures with shared texture space. Essentially I design a symmetric scene, set up the lights and UV only part the model. I then use this part of the model to create the rest of the scene, but I push their UV’s out of the main UV space. This is a trick, since Blender won’t bake the textures for these faces (when they would normally cause problems), and they are technically in the same place if texture mode set to repeat.
Here you can see the UV texture space. The faces pushed to the top are part of the stairs design, while the parts pushed to the right are levels.
In this image you’ll see that the stairs have essentially the same texture mapping from one level to the next. What is really nice is that since they are the same, they share the same UV texture space, I reap the benefits of the resolution only doing it once. It might seem really weird but its backfaces only. This means you see through geometry from one side, but not the other. So you can see the stairs through the walls so to speak. It’s so natural to me, but I expect some won’t know what they are looking at.
I’ve started working with Battery Powered Games, a local android developer I met through IGDA. We’re making a FPS sort of game. The images above is a WIP of level two, a castle level.
I’m limited to around 1000 triangles and two textures. One texture, a 1024×1024 image is the diffuse and the other is a light map, only 512×512 at maximum quality.
I’m having a lot of fun working on this stuff.
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).
|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.|
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.
I’ve been learning Blender 3D at work. I’m contrasting my current understanding of skinning (UVing) geometry vs. the way its applied in Blender. I understand UVing and skinning just fine, but how do materials and UVs work in Blender and how are they saved and used in other formats. From the first apply though, I’m very impressed with Blenders UV capability. The fact that I can drag verticies around on the UV map is a huge win for me.
I wrote a crazy complicated pitch for my class, something ambitious requiring a lot of determination, sweet and coding. Problem right there, I don’t have all the time I need. So I switched gears entirely and spent much of the night getting my world ready.
This is based off the starter.fps project. The character is default, but the terrain and skybox (the planet and space background) are custom. Check out the crater in the lower right, I’m able to paint those around. Looks pretty cool I think.
In my Modification and Level Design class (GSP 340 at Devry) we’re using the Torque Game Engine to “modify” a game. I’m behind in the class because I don’t put my nose to the grind stone until 11:00 pm, and then I get distracted.
Were using the book 3D Game Programming All in One by Ken Finney, and I’m through chapter 5. Chapter 4 and 5 have the template started with running game levels. I couldn’t resist and took their default player and put my face on him.
Got to play with some XNA today at work. I whipped this quick generic gun model up to prove out the content pipeline (Blender and textures). This is a modification to the BasicModel project, but with my parts and textures.
It was a lot of fun, and whoa a lot of learning. I see I have my work cut out for me, bot as a programmer, but as an artist.
I think the iPhone is a really neat device, regardless of my distaste for Apple marketing and consumer milking (which I won’t go into). I see the potential for independent developers and wish I had the skills (and the time and money) to develop games for the device. I’m getting close though. I’ve managed to wrangle a freelance gig doing some 3D level model design and graphics work for a iPhone app. I’m signing an NDA so I can’t talk about it and I don’t know much yet, but hopefully it will be cool.
If you’re an iPhone developer looking for someone to do art, graphics, 2D or 3D models, level design, textures, icons, etc., please give me a buzz and I’ll see what I can do.
For my class GSP 260 the assignment was to make some models. I went a little overboard here, and put a lot of time into making a minivan. It’s game ready: low polygon count with one composite texture.
Every once in a while I’ll take a job on the side. I prefer paying gigs, but sometimes I pro-bono if I’m interested or the cause is good. I currently have three “gigs”.
The first is a special FX shot for a MN independent filmmaker. I took this job back in July of 07, didn’t get the footage until January, and I’m about to finish (April). It’s been a slow process, which is my fault to some (probably great) extent of course, but with family, school and other jobs, hobbies (the pumpkin movie) and interests (video games, beer, etc.), I’ve been less than available and less than motivated. Good news is its done. It was a special effects shot with fire as you can probably see from the image. I lit fire to my driveway three times and my garage five times to get the shot right. And that was after my attempts at “faking it” failed to yield results I was happy with. Hopefully the film turns out well for the director/writer barring my delays.
The second gig is a good one. It’s a Guru job. Guru.com is a website for freelancers. I get e-mails about freelance jobs and I look but usually don’t apply. This one however was right up my alley. Some guy out there is modifying a Head On arcade cabinet with a SEGA baseball game and needs a custom control panel. I submitted a bid and he took it because I mentioned my current interests and motivations with classic arcade cabinets. Its going well I think, though I way underbid compared to the time it will take me. Course, I will take the money earned and apply it toward my own arcade.
The third gig is a free one. I’ve been unmotivated to produce any TurboSquid assets lately and needed some inspiration. It came in the form of an e-mail from someone who downloaded one of my free models, a pickle to be exact. This person had obviously read my e-mail asking for response if they use it, so I rewarded them with a reply and an offer for more free models. Turns out he’s working on a mod to Fable. To date, I’ve made him (I’m assuming a him) a low polygon hamburger with texture. Soon I’ll be completing a hot dog and additional food items. Should prove interesting in the least.
I spent the last four days in DC at the Navy League something or other trade show standing on the trade show floor, demonstrating our modeling and simulation to VIPs and other not-so-VIPs. Turns out the schedule I conned my co-worker/friend Brent into coincided with an interview. Brent got a stunning write up on the Popular Mechanics technology blog and all I got was an extra hour of sleep.