itsamoose

To me this distinction is really how each game represented and interacted with the world. DA:O seemed like a game that was somewhat indifferent to the fact that it took place in a 3D world (magic goes through walls, characters must stand a specific distance apart before attacking, etc), while DA2 remedied these issues but had quite frustrating encounter design.

I picked up the whole series yesterday and ran through it in a couple sittings. I absolutely loved the atmosphere the game created, and the plot kept my attention but I felt like it never really pays off. Without going into spoilers, it seemed to suffer from the developers not really wanting to delve too deep on any particular issue or character. Also, and this is just something that annoys me in games, is that information traveled around the world at lightning speed. When something happens to Bigby, it seemed like the very next scene everyone you could talk to already knew exactly what happened without a clear reason how. I'm not sure as to whether or not this is a good or bad thing, since never really being able to have any privacy seemed like a reasonable motivator of Bigby's anger. I had more or less the same reaction to the game. I kept wanting it to allow me to go one step deeper, but it seems the developers chose to focus more on story variation than anything else.

I haven't worked much with the Windows store Unity development, but I would imagine their touch functions would work just like they do for Android/iOS. You can find more info in the Unity script reference which has been greatly improved in the last couple of months. Personally I still use Visual Studio 2010 for Unity projects, although I am still using Windows 7 so I can't comment on the compatibility with Windows 8. If you are looking for information on how to use Unity specifically related to Windows store development, I'd suggest checking out Microsoft's Channel 9. They have a number of general how to tutorials, some related to Unity, that go over what types of gestures exist and how to use them as well as general programming concepts.

I recently started playing Splinter Cell: Blacklist thanks to the latest steam sale, and that sentiment describes about half the cut scenes in the game. As much as I like stealth games, I don't think I'll be able to make it through the whole thing entirely due to the cut scenes. Usually Sam starts by hitting the guy, then he eventually gets around to asking for information, doesn't get it, rinse and repeat. In some scenes Sam gets the info he wants, but keeps on kicking the shit out of the guy or you can decide to kill him. The scenes aren't as graphic as Splinter Cell: Conviction, but are just as prevalent.

This is an interesting point. Perhaps this game has produced this kind of discussion because we are starting to see the military arms race making its way into the civilian world in a very real and troubling way. Recently police departments and SWAT teams started purchasing surplus military equipment. Think about how drones were once an incredibly uncomfortable topic, and now they are almost treated like they are a fact of life (At least in the US). In my opinion this is largely because they became so prevalent not just in games but all entertainment. This may be sacrilege of me to say but I feel like the "video games make you into a killer" people do have a point, even if it isn't the one they are making. When you become so used to seeing paramilitary law enforcement in entertainment does it bother you as much when you see the same thing in the real world? What is unnerving to me about this game is that it doesn't portray a future or even near future setting, this stuff has been happening for some time now and shows no signs of slowing. I really think we are getting to a point in the world of video games where saying "its just a game" simply won't cut it any more. After all if video games don't affect you in some way, then why do you play them?

I think the issue is more that the setting has been (seemingly) applied simply on top of mechanics that really make more sense in a ground war. For example a true cops and robbers game would probably involve some kind of sneaking/stealth while the criminals infiltrate, making arrests on the part of the police, etc. However the mechanics of a battlefield style game only really focus on the application of deadly force and ignore, or simply don't respond to, everything else. It essentially puts the police in the role of an occupying or conquering force rather than a peacekeeping one. It asks the player to participate in the abandonment of due process and rewards you for doing so. This isn't to say Military shooters don't do this kind of thing, but I believe in this instance it hits closer to home for people. The comparison I keep making in my head is between my desire to play a game like Papers, Please vs someone who actually grew up or lived in a place where that kind of situation was the reality. For me that game is fantasy, but for them it might be obscenity. On a side note, if anyone is really interested in this kind of a topic check out Continuum. A good portion of the show is about how the police force becomes more and more militaristic. Edit: I haven't played the game yet, I have only seen some gameplay footage, so it is entirely possible I am misreading the game's intentions.

There are actually a few tricks for getting objects to line up nicely. First is to turn on The Grid Snap Feature, but one I use a lot is the vertex snap feature. Just hold down the V key, Click on the vertex of an object, then drag it over to another object. You'll see it start popping around the scene trying to snap to various vertices. Once you have the position you want, just release the mouse button. There are a few more tricks you can check out here.

You're right, that was a bit of a mis-characterization on my part. Certainly people can be forced into military service, I was more speaking from my experience. Most likely someone with enough money to buy video games isn't going to be in that group. I suppose if you play games primarily for the mechanics or multiplayer interaction, the aesthetic probably doesn't make that much of a difference within reason. However if those two groups were Nazis and Jewish resistance fighters battling it out in a concentration camp, then the question of a game's ethics becomes more important. Sure, Hardline isn't to that extreme, but it is a game that completely does away with even the semblance of the things traditional shooters tend to set up as the player's motivation for wanting to play. Mechanically shooters may just be reskins, but the context of your actions can help to define the character of the game. Ultimately the setting is still important.

Granted the game mode shown in the video is really just a capture the flag variant, but I still agree with the sentiment that this is problematic when combined with the aesthetic. I think the difference between the Cops and Robbers vs Military aesthetic is largely that it explicitly glorifies the deviant elements of society. Two soldiers on opposing sides are ostensibly both there voluntarily, or due to patriotism/nationalism/etc and the civilian world is almost presented as if it were excluded from the scenario. A criminal on the other hand may be in their position because of having no other option, or for the thrill of it, or for greed. A soldier dedicates themselves to something more, while a criminal need not. I think the thing you hit on in this thread is that in Hardline all the veneer of self sacrifice and dedication to a cause larger than yourself is completely stripped away. The superego is ignored, and the Id takes over completely. I suppose the question then becomes is a somewhat phony representation of selflessness any less bothersome than one completely embracing selfishness. I think ultimately both aesthetics are problematic, but Hardline seems to require and revel in the obscene motivations of its players.

3D Buzz just released another free suite of Unity tutorials, this time focusing on the 2D elements of Unity. http://www.3dbuzz.com/training/view/creating-2d-games-in-unity-45

In that particular case, and in general concerning methods that return collections, the length of the collection will be determined by the operation. This allows you to pass in a string of arbitrary length with an arbitrary number of parameters and always get the correct result. The difference between that and creating an array manually is that the string.Split() method will handle the array's creation and return the result, but within the method the length of the array will be determined by the split algorithm. Also a neat trick with the params keyword in C# is that you don't actually have to create an array to pass in as the argument. Instead you can just list all the chars you want to be used to split the string separated by commas. This will be incredibly useful once you get around to writing editor scripts in Unity. string[] exampleArray = sampleSentence.Split(',', '/t', 'c');

I've recently been having a discussion with a friend regarding pausable real time games, and the impact that choice has on the game's design. He is of the opinion that this system is a kind of weird half measure, where the developers want to make a real time game but don't want to have to account for the time in takes to observe and react to the game. Ultimately I don't have a question here. I'm just looking to get some more opinions on how people feel about games that allow them to pause at will vs games that are strictly real time. Also if you have any suggestions for games that implement this idea in an interesting way, please mention them.

Just a follow up, is the pausing, for those that like it, more useful for information gathering, or accommodating for mechanical competency of playing the game, or for more aesthetic reasons? To the point about games allowing multiple modes of play, I just can't see this being a good idea if those two modes are mutually exclusive. A turn based system and a real time system have very different considerations, and trying to do both seems like a recipe for leaving something to be desired in either state. I'll have to try out transistor since turning the turn based mode into essentially a mechanic seems like it could be an interesting version of this idea.

What is this for? If you are interested in scene serialization as a way of creating save games, there is actually a package on the asset store that will serialize the entire scene in a line or two of code. So long as your saving mechanism writes all the properties you want for the Difingo class, those properties can be recalled.

Given the amount of interest I've seen in State Machines and AI here, would anyone be interested if I made a small example of these at the intermediate level? It seems like there are a number of examples to go over the basics but from what I can find little beyond that. Basically I'd go through the planning and implementation of a particular element of AI design such as sensing the world or take a bit more of an in depth look at state machines.

I had a similar problem working with NGUI's earlier anchor system, but with little luck. How are you changing the aspect ratio? If you are just toggling the in-editor drop down? I don't believe that alone will trigger the UI rescale/reposition. Try making a button that calls Screen.SetResolution() in a standalone build with various aspect ratios and see if everything works properly. One of the issues I've found with Unity is that you can't necessarily rely on the game running in the editor to function the same as the standalone build. This is particularly true when you are changing non Unity specific elements such as the window size. For example calling Application.Quit() doesn't do anything in the editor, but works just fine otherwise.

What in particular are you looking to do? If you are interested in scripting I can't recommend XNA or Mono enough. XNA isn't supported any more, but it is a great place to figure out how games work under the hood without the need for a lot of programming/computer science knowledge. Any sufficiently advanced engine won't really expose you to the more basic concepts like rendering, World vs Screen vs local space, physics processing, etc since they are all handled internally by the engine. If you are interested in design-type things I would recommend picking up Shadowrun Returns and playing around with it's scenario editor, or any other game with mod tools for that matter. Mostly because those kinds of tools start out where you have a bunch of things to play around with, as opposed to say an empty scene in Unity. As far as for what to do goes, just pick a mechanic or simple game you like and make a clone of it. That kind of exercise really helps you understand just how complex seemingly simple elements of games can be. Also the suggestions so far are all fantastic.

Borderlands 2 on the PC had a pretty great implementation of this, essentially they allowed you to adjust the size of elements as well as dictate their relative positions. Depending on what type of game your making you might also need to consider various aspect ratios (depending on which ones you want to support). This isn't a big deal with floating elements usually, but can be with games like Starcraft or DOTA that section off a portion of the game window for UI. Personally with this kind of stuff I think the more options the better.

I had a bit of trouble when I first encountered events and delegates as well, just keep at it and it will make sense once you've had some time. If you are interested in learning C# I can't recommend the XNA 101 series at 3D Buzz enough. They go over everything you need to know about C#, down to how mono framework actually works, and even start off by writing a text adventure that plays in command line. What helped me when learning about delegates and events was to think of them like to-do lists. So instead of making a call to a function, you run through all the items in a to-do list. They become particularly useful when you need to start having things respond to other things that are not currently on the same gameobject, such as a door opening or a unit dies. Personally I use events extensively in my code over SendMessage. The reason for this is that SendMessage won't work on disabled components or objects, and you can run into some weird situations because of it. I'm not sure if this will make sense to you, but I think the best thing is to just see an example of them in action which I've attached to this post. In that particular class you'll see examples of Attributes, events, delegates, and generics. This is a monobehaviour and helper class I'm using for the game I'm currently working on that controls when actors take damage and raises the necessary events. There will be errors since we're using a few plugins, but the basic functionality is all there. Hope that helps. Health Component Example.txt

I absolutely love the in game UI, how so much of it is dedicated to showing you what your team mates are up to. It seems to lend itself to serendipitous team centered play without cluttering the screen too much based on my experience.

The OnMouseDown() issue might also be related to Cursor Lock. https://docs.unity3d.com/Documentation/ScriptReference/Screen-lockCursor.html

Caching component references is actually a good idea in most cases, as mentioned above the Unity supplied properties are just GetComponent calls, which essentially work the same way every time but require a few extra instructions to be fired. In terms of the color swapping, the method you have will work just fine. One thing to note is that any time you reference a renderer's material's property (for any reason) it creates a new instance of the material on the stack. I'm not sure how familiar you are with instancing, but here goes with a quick explanation. Instancing is a process that allows for multiple objects to reference the same model, material, etc. This way you only have to store the model/material/whatever in memory once then copy its values as necessary. By referencing any property on a material, this instancing is broken and a new version of that material is created in the program's memory. What that means is that if you don't reference the material's properties for any reason there will only ever be 1 version of that material in memory throughout the entire program, however if you do reference one of those properties a new version of that material will be created for each object that process is called on. So if the script you posted is added to 5 gameobjects, it will create 5 new instances of that material. This probably isn't a big deal at the moment, but its something I've had to be aware of recently since the game I'm working on has over 10,000 frames of hand drawn sprites (tons of texture memory). If you want the most memory efficient way of doing this, just store a reference to both a red material and a blue material, and swap them as necessary. In the end either way works just fine, but one has some memory considerations to go along with it. Again, this probably isn't something you need to be concerned with at the moment. With static variables you shouldn't need to cache references, just reference the class, then the variable. In most cases just storing a reference to the component containing the variable is enough for member variables.

This could be for a number of reasons, and believe it or not it actually works in your favor in some cases. For example, if you are looking for a random element in a list or array, you can call Random.Range(0, List.count) to get the index, since the highest available index in a list or array is actually one less than its count/length properties respectively. It doesn't make sense at first, but remember collections are zero based in C#. This means the first element in an array/list is at index 0, as opposed to index 1.

This is mostly a guess, as I haven't worked with Mecanim all that much, but from what I understand this problem is a result of the way Legacy and Mecanim animation works. With legacy animation you play the animations directly, where as with mecanim you transition between states that then control the playing of the animation. I would imagine the reason you're only seeing the event fire once is because control of the animation is handled by mecanim, which likely only "plays" the animation once and then manipulates it as necessary. If this is in fact correct, you should be able to get around it by listening for changes in the mecanim animation's state as opposed to inserting events directly into the animation. A simple test could be to take the animation you are playing, then manually play it forward and reverse (not using ping-pong or looping, just manipulate the animation state's speed variable) and see if the event fires each time.

Is it difficult to debug playmaker scripts? I've never used it, mostly because I'm much more comfortable writing code, but I've had some issues trying to debug complex scripts with other systems.