iax

Oh that's definitely true, also they were quite open about the fact they're doing exactly that way before the release. But still, I'm not sure Sim City and the genre it started would look dramatically different if it had been created in Europe (not that anyone confidently said it on the podcast). Maybe drawing road grids wouldn't be the first thing you do in the game, but I think it would still start with an empty space with few constraints because that's what you do when you want to make a city-building sandbox. Of course you could also make a game about slowly fighting for space through politics and whatever but I don't think that's a game you would make after deciding that "hey, let's make a game where you build your own whole city and stuff!", American or not.

It's true Sim City cities are very American but I think the main reason is not that it was made by Americans, but rather that you probably want to be able to plan and build your city from scratch in a sandboxy game like that. Also grids and squares are the easiest to implement and use, especially when we're talking about the times the first Sim City was developed. Also also Cities: Skylines devs are from Finland, my impression is people assumed they're American on the podcast.

I have it, I got in during the closed beta and played it for a while but it was so intense I stopped for a bit and never really got back (which was silly, it's a fantastic game and it had an amazing community, it seems it should still be the case)... I'm open to playing it some time.

I think it's quite safe to assume they are working on it or at least were working on it and are rethinking their approach right now. Valve has a (maybe partially deserved?) reputation of being this weird company focusing on DOTA and hats, not making "their" games anymore etc. etc. now, but completely abandoning Half-Life wouldn't make any sense. It would go against every force that is present within a company making video games and having an extremely successful flagship franchise like that, "weird" or not. One day we'll learn about what has been going on with HL3 and it will be a completely insane story.

IGN did something similar a year ago when Doom turned 20 (JP & Romero even mention it in the DP videos). Some overlaps, but definitely worth checking out too

Sure, I know you're setting the cells in the Start function but the cells do have some values already before executing the function and you tested for these values before setting the new ones. Your posted code doesn't include the part where you create the cells array so I didn't know it's guaranteed to be zero (i.e. empty space). It seems some of the cells were in fact set to 1 before running Start() if the change you posted fixed the problem (or maybe you ran the Start function multiple times? In that case the previous results were present in the cells array and were influencing the algorithm).

Hm I don't see anything that is obviously the cause but I think it's strange the calculateChaserChance tests go down from i to 1 and j to 1. Are all cells guaranteed to be set to 0 before genereating the level? If not, you could prematurely break the testing loops by testing the cells[i,j] value which is the cell you're currently computing (and could be set to 1 for some reason). Also the test will ignore everything with i = 0 and j = 0 but maybe these tiles are guaranteed to be walls? Anyway I would change the loops to for (curr = i - 1; curr >= 0; curr--) (the same for j obviously). Also I would try to modify the code so calculateChaserChance outputs some huge chance instead of 0.2 so the enemies would always be placed as soon as possible. If that eliminates the problem it means something is wrong with the randomness/chance values.

I guess I'll paste my post from the recently finished games thread here: Also I have one 50% discount Steam voucher if anybody's interested.

Ok, so I've finished The Talos Principle. This game is getting a lot of extremely positive reviews and word of mouth right know and I think it absolutely deserves it. It's impossible to talk about this game without comparing it to Portal and Portal 2. Not only because Portal is to first person puzzlers what Doom was to FPS games ("Doom clones") in the mid-nineties, the basic structure of TTP is the same: puzzle "chambers", disembodied authority figure with questionable motives, traces of predecessor characters, robots, cubes which are not called cubes etc. I admit it's something that I found a little bit off-putting at first, "Portal wannabe" was definitely my first impression. I'm writing the post as someone who played both Portal games and was very sceptical about this weird Serious Sam puzzle game with janky robots. Some thoughts: The TTP puzzle-solving mechanics mechanics are not as "exotic" as portals but I think the way they force the player to think about the spatial relations and timing is the same as in Portal. There is a lot more of positioning of various devices. The puzzles are on par or maybe even better than in Portals in my opinion and there are A LOT of them. The world is not linear but hub-based. While the hubs themselves are gated, most of the time multiple puzzles are accessible and the game actively encourages the player to try something else when they are stuck. I think that might have freed the designers to include more difficult puzzles in the game. I think the game is more difficult than Portals, but not dramatically. While many good puzzle games try to make you realize something new in each puzzle, TTP is not afraid to play with already presented ideas in some of the arenas. There is still a lot of variety though, "the non-revelatory" puzzles are good and they don't feel like filler content. There is an extra layer to the game: there are many secret stars to collect. Most of them require the player to do something against the established rules (e.g. finding a way to bring something from another puzzle area even when all areas have entry gates preventing the player from doing that. It's funny that when I switched to this "all bets are off" mode I immediately jumped to trying some crazy overcomplicated approaches which didn't work at all, the solutions were much simpler) and I still have no idea where many of the stars are even when the game hints their location. The stars add an extra mystery layer to the game. The game is very long, probably 15 to 20 hours (17 for me and I've only got 7 stars, I can't imagine how long it takes to find all of them). I've never felt like the game is dragging. The tone and the writing itself are not "portalish" at all even if there are some surface similarities. TTP is generally much more serious and philosophical. To be honest, after watching some trailers and even playing the public beta I was expecting the writing to be a disaster. I expected seeing robots running through Serious Sam scenery with some grandiose quotes about religion and consciousness randomly printed on walls or something similar because that's what video games with similar aspirations are prone to do. I was pleasantly surprised this is not the case at all. Sure, it's not an academical deep dive into philosophy but it's smart, interesting, sometimes funny and it meshes with the structure of the game quite well. It's clear it has been written by people that know what they're doing (Tom Jubert (FTL, The Swapper) and Jonas Kyratzes (The Sea Will Claim Everything) to be specific). Mild spoiler about some of the writing in the game (no details, but I was surprised by it's existence in the game): Great puzzles, great writing, great game. My new favourite first person puzzler (well, on par with Portal 2 coop at least), GOTY 2014, would buy and play again.

If you're interested in agent-based graphical simulation of complex systems, download NetLogo and check the included models and their descriptions https://ccl.northwestern.edu/netlogo/models/index.cgi e.g. you can find the model discussed here under social science / segregation. NetLogo itself is an integrated modeling environment with it's own simple programming language so you can easily modify the models or create your own.

The Thumbs are not up to date on hair distribution within the video game industry at all.

22 - David Hellman, Braid artist, definitely check out his other stuff too, it's great! http://www.davidhellman.net/

From what I've seen in the proper streams I think some basic understanding of C is definitely necessary. The Intro to C on Windows pre-streams cover at least some of the basics (including a good explanation and a demonstration of what's actually happening when you compile and run your code) but I can't really evaluate how begginner-friendly it is for the same reason as Erkki. One thing to remember: Casey often goes against what's seen as "the best programming practices" today. He has very good reasons for that and he always explains why he's doing it, but of course one has to be familiar with these practices to fully grasp the nuances of the situation. I don't think it's that important for learning itself but I think it may lead to some misunderstandings when communicating with other programmers (especially the overzealous ones). Also, as I've mentioned in the programming thread, it's important to know that the course is a long term commitment focused on the programming aspect of game development. Casey already stated that the game design itself won't really be the focus and it will be heavily driven by what's interesting to program. Other than that, I've seen some of the pre-streams and some of the regular streams and they are absolutely great. I'm bummed that it didn't exist when I had been learning this stuff (not that there's nothing new to me there!) and I had the time to follow a course like that.

I've started here http://unity3d.com/learn/tutorials/modules/beginner/editor these are short video tutorials explaining the basics of the editor and Unity's philosophy itself. Unfortunately it seems the Unity community (well, UE4 folks too from what I've seen) is in love with long video tutorials which are too painful for me to use so I just started to use reference and forum searches after watching the intro stuff, I think you'll get into it pretty quickly if you have previous C++ game programming experience (I have a similar background).

Also you can check out Visual Studio Tools for Unity http://unityvs.com/ I haven't tried it yet as it doesn't work with the VS Express edition I've been using, however I think it should work with the new Community edition (which is basically the full VS and it's free for small teams up to 5 people I think).

Yes, it is a good idea to treat Update() as the default place to update the state of your game unless you have a good reason to use FixedUpdate(). Physics are a good example and they are probably the reason FixedUpdate() exists in the first place. Physics systems try to simulate non-trivial continuous real-life phenomena in discrete steps and there are good reasons to have these time steps fixed. If we used variable time steps with fps compensation (i.e. multiplying the values we add to something using Time.deltaTime) we would tie the behavior of our game to the framerate. We could miss some physics interactions on lower framerates and also things that are not linear (i.e. things whose effects won't be twice as large when doubling the cause variables, e.g. applying acceleration to a body) would behave differently for different framerates unless we really took great care to compensate for that. Also because computer-represented floating point values have variable precision, various physics systems are often tuned for a range of distance, mass and time values the user can use without risking losing stability and having fixed time step helps to ensure these conditions (see e.g. falling through an elevator floor when running Dark Souls on 60 fps). On the other hand, FixedUpdate() is not really tied to the frames being drawn so apart from possibly missing some important events everything we update in FixedUpdate() will look janky. In fact Unity physics can look pretty janky unless the bodies have interpolation or extrapolation enabled (or have a look at the first Bioshock as a non-Unity example, the physics have a low framerate even when the game itself runs smoothly which looks pretty weird). It's generally better to use Update() for non-physics movement (as in performed in a script and not using Physics or Physics2D) and compensate for variable time steps using Time.deltaTime. Hopefully that shed some light on why both Update() and FixedUpdate() exist and what are their pros and cons.

For anybody interested in game programming, have a look at http://handmadehero.org/ Handmade Hero is a project to develop a real professional-quality game from scratch and stream and comment on the whole programming part of it. It's meant as a teaching material for aspiring game programmers. I'm pretty confident it will be great because of the guy behind the project: Casey Muratori. Not only he's an experienced programmer who worked on some of the best-quality libraries in the game industry, he also likes and knows how to talk about programming in an insightful no-BS way. Just a small dsiclaimer: The course looks like a long-time commitment and it's intended for people really interested in how games work underneath and how to program them including very low-level stuff so I'm not sure it's a good time investment for people interested in scripting in Unity or other tools.

One of Double Fine's Amnesia Fortnight entries was named Derelict and it had superficially similar premise (I don't think it was meant to be a horror game). It wasn't chosen for AF and I doubt they're working on it though.

The issues you have sound like they could have something to do with mixing up axes maybe? 2D stuff including 2D physics is happening on the XY plane but the default 3D ground plane is XZ in Unity (in the sense the default 3D view and various 3D shapes are oriented this way by default). Maybe it's a completely silly suggestion. I think some screenshots and/or code fragments would help here. It's difficult to guess what's the problem without seeing some in-depth details about what you are doing and what's happening exactly.

What do you mean exactly? Arrays work like they should in C# (http://msdn.microsoft.com/en-us/library/aa288453(v=vs.71).aspx), it has nothing to do with Unity really. Or maybe you mean something else, e.g. some Unity editor integration issue?

I realized that during this particular steam sale weekend few months ago:

Let's be friends and stuff. http://steamcommunity.com/id/_iax/

Ok so it seems the Box Collider (and various other colliders) won't work correctly in your scenario, see http://docs.unity3d.com/430/Documentation/Manual/Transforms.html the "Performance Issues and Limitations with Non-Uniform Scaling" section. Non-uniform scaling is quite ugly in general and it seems Unity chose to not handle tricky situations it causes. I think that in your case even your beam mesh has to deform at least a little during doing the swiping motion (well provided you use a mesh for it). I believe this can be solved by detaching the beam from its parent object. Create the beam as a top-level game object and set its transform in a script (you can use some dummy attachment object as a child of the original parent and read its world position and rotation, of course you'll have to modify the rotation for the beam to do the sweeping motion).

Hm, does it work when the parent is scaled uniformly? If so, maybe you have some rotation in your hierarchy so the parent's xyz axes used during the non-uniform scaling are different than the final beam axes? Maybe try to use Transform.lossyScale http://docs.unity3d.com/ScriptReference/Transform-lossyScale.html as scale in the line you pasted if you don't do it already.