Mesh Batching in Unity

After a couple of very personal posts about non-technical stuff, I've decided to write about something strictly technical: Mesh Batching. So, first thing is defining what I mean by mesh batching. I've found a definition I like from some game development forums (link here):

"Batching is a way of grouping geometry together (they should be compatible, e.g. the same material, context states, etc.) to use as few draw calls as possible. In this way, you could fully exploit GPU throughput, so as to improve performance."

Unity offers dynamic and static batching and they work generally pretty well, but they are automatic systems that need to work in every case scenario, which means they need to cover many possibilities. Normally it's easier to implement better optimizations for a particular case than doing it for more generic case scenarios. That's why I'm gonna be explaining here a way of implementing custom mesh batching in Unity that can improve its default system.

Beautiful screenshot of our work in progress title: Super Toy Cars

Crunch! (part 2)

This the second part of an article talking about crunch, where I give my opinions and share my experiences with regards to that subject, and try to explain the origins of my very cynical point of view. It was all sparked with a very unfortunate twit from the Ryse guys and in the first part I share some of my early experiences which hopefully explain my currently cynical way of looking at this subject. During this second part, in order to avoid problems with NDAs and so on, I'll try to stick to talking about generic stuff rather than focusing on a concrete experience. I'll try to compile a set of things I'd like to see and I think should be avoided by managers and game directors when dealing with this sort of issues. All of this is based on my personal experience throughout my whole career, not on a single project.

There was some controversy with Rayman Legends' team working overtime only to get the game delayed

Crunch! (part 1)

It's been quite a while since my last post. The title of this post explains why. I had to crunch for most of the first 7 months of the year. And then I took some holidays a little and intense work-for-hire time, and finally went back to work on my own project, on Super Toy Cars. I suppose I could've come back earlier, but I was too tired and probably didn't have something I itched to talk about. I'll try to come back to the habit of writing an article every 1-2 weeks. I'll try to discuss some of the design decissions on Super Toy Cars, some technical challenges and solutions, maybe sometimes just post images of the game for the sake of it and, of course, will visit topics I believe are controversial and I have a strong opinion of.

Ryse: Son of Rome

Always Online DRM and Xbox

Don't know if you heard, but SimCity launch, the latest title from Maxis and EA, was a bit of a flop. Well, yeah, that may be a bit of an understatement: it was the worst title launch ever. Probably. Most probably. I definitely can't recall any other example that had gone so terribly wrong. And least of all, to repeat their mistakes for over a week. And you know the source of all the fuzz? Always online DRM.

SimCity should have been one of the biggest games of 2013

Fake Shadows in Racing Games

I've decided it was about time start writing something about Super Toy Cars. Something that could also be useful to other developers or students visiting this blog. I thought I'd rather start with something simple. I didn't want to embarrass myself on the first technical post :o). So I decided to write about something I had to implement recently for Super Toy Cars: fake car shadows.

This image from RACE shows clearly the outlines of the fake shadows combined with dynamic shadows

PS4

So, I'm a little late here almost 2 weeks after the console was announced in New York. Everyone in the industry has already gone through what they think about it, how they feel, how important/irrelevant PS4/the next generation of consoles is going to be, etc. So I'm gonna write something quickly explaining my point of view about the whole thing.

PS4 was announced in New York a couple of weeks ago

Racing games are dying? (Part 2)

In this second post we will go on analyzing the current situation of the racing genre and what possibilities there are. In the first part we did an overview of the genre and talked mostly on simulators. You can find it here.

Arcade Racing Games

As Wikipedia describes it here, "Arcade style racing games put fun and fast-paced experience above all else, as cars usually compete in unique ways. A key feature of arcade racers that specifically distiguishes them from simulation racers is their far more liberal physics. [...] For the most part, arcade racers simply remove the precision and rigor required from the simulation experience and focus strictly on the racing element itself".

OutRun. I wasted so much money on this game...

Racing games are dying? (part 1)

For my first 'proper' entry I decided to select a subject that's a bit open to debate and in which I'm particularly interested in. I like playing racing games and love working on them. They have a mix of technical and design challenges I find particularly interesting. Well, that and I love cars, particularly fast sport supercars, not that I've ever even driven one of those. That's one of the reasons why our first game as Eclipse Games was a racing game (Toy Cars) and why we're currently working on a sequel (Super Toy Cars).

Split/Second, the last game from Black Rock Studios

Introduction

Hi, 

It's Eduardo Jimenez here or Barkley, as lots of people like to call me and how I'll be signing this blog. 

I've been a professional games programmer for over 8 years now. I've had the honour and the pleasure - well, it's not always been a pleasure - of taking part in the development of many AAA games. I'm particularly proud of my work in Pure and Split/Second, which I worked on while at the, now disappeared, Black Rock Studio.