10/10.
Masterpiece.
Citizen Kane of videogames.
Best survival game ever made.
Those are some of the statements and opinions you can find around the newly released Naughty Dog game; The Last Of Us.
This, as a gamer, stresses me. The reason why is simple, it lowers the
bar for what makes games games in the first place and in some instances
makes them completely disappear.
Lowers the bar for games?
This is not a game. Now that might sound like an extreme statement but
only one thing is keeping that from being true. And that's the open
battles.
Outside the open battles the player has zero input into this game. No
world navigation, no character interaction, no dialogues, no morality
choices, no ally control, no side missions to pick from, no nothing.
Everything in this game is in there and you can't do anything about any
of it. That is not interactive.
You clear an area, and the game presses 'play' and you watch.
There are further things in this piece that demonstrate the compromise of game design.
Survival?....Where?
This is where it gets really bad. For a survival game, you have to make
big cuts to player luxury so they can get that sense of desperation.
This is something unfortunately Naughty Dog, and AAA games in general do
not do. They hand you all the tips, tricks, checkpoint systems, HUD
prompts, whatever you need and then some to get through this "cruel"
world.
Not good enough. If you want to make a game in this setting, do not
water it down so much where your game design is in direct contradiction
with the setting.
When I die in a survival game, the biggest consequences should not be
me losing 40 seconds of progress. This defeats the whole desperation
aspect the very core of the genre relies upon.
This is a shooter with limited ammo at best.
Ellie...The companion that never was.
This is a companion we are supposed to care for. But again, in no way
interact with so how exactly are we supposed to care for her. This is a
game, if you want us to invest in something, build a game play mechanic
around it.
There are dialogues littered through the game once or twice (where you
press Triangle and listen) but that's about it. We don't look after her
in the game, how about sharing food and what-not with her (if there were
such mechanics anyway). No 'stop' and 'follow' commands, which would
have made us care for her as we looked after her in battle (even if only
early on). And to make matters worse, she is not believable in the game
world...
...She is invisible to the enemy, sometimes walks right into the
enemy....And I can't remember how many times I walked into a bathroom
for scavenging and when I turned around to exit, Ellie was right up my
ass blocking the way.
Again, another example where something in the game adds nothing of value to game play and even detracts from it.
Why are you picking on this game!
I am not. I am giving examples on how AAA games devolved into
mainstream mess where a game can't do what it wants to do because all
the players are treated like 12 year old retards. That's what truly gets
to me and I can't stand it.
I don't want my hand held in every game. I don't want to be "along for
the ride". These are things that go completely against why this medium
is great and for game developers to sacrifice interactivity for the sake
of ease of use or automation is just mind bogglingly anti-games and
even a word I hate to use; lazy.
I have used The Last Of Us as it has been praised as the king of games
and I really really really don't want AAA games to continue on this
path.
Wednesday, 19 June 2013
Sunday, 2 December 2012
Why I think Rockstar is avoiding RPG elements in GTA
What is being addressed here
Ever since San Andreas teased us with a little bit of RPG, fans of the franchise had a taste for it, and asked for Rockstar to make it a more permanent and a bigger part of the franchise.Rockstar only emphasised with the fans recently on the appearance part. Commenting that the current resolution of the characters makes appearance changes (fat / slim) a difficult task and it was more easy to get away with it on PS2.
What about levelling up your weapons as you use them, XP and even sex appeal that SA had.
OK, so what is your take on it
I feel RPG elements puts a very strict creative shackle on Rockstar's story and character creation. If we look at where Rockstar is taking GTA this gen, they are going for a very precise and tailored experience. The characters are laser focused and so much detail is put into each one that putting in RPG elements would throw all that work out the window. As putting in RPG elements is to hand the DNA of the character to the player, effectively throwing out the work Rockstar has done.GTAV's three characters is a clever way to give key characteristics of the franchise to three different characters so the immersion never breaks.
They are giving you the variety you crave, without giving you control.
But we are the players, we want control of our characters!
This is where it gets tricky. To give control is to take away immersion. Imagine if Niko did most of the stuff in GTAIV as some fat guy. Or even when he was talking about morality in one cutscene, and then soon as gameplay starts, the player rockets someone in the face. That doesn't work for Rockstar's current vision.They want us to respect their characters on the level of "well, Trevor would never do that". This creates a stronger character through believability and thus we are drawn into the world much more like any well written TV show.
Rockstar, WHY SO SERIOUS?!
Even though many like to see GTA as some silly game where you go around blowing up cops, Rockstar as the creator, I suspect has much more respect for it. Rockstar has a reputation of raising the bar and pushing boundaries. And they can't do that when they give you the PS2-era GTA over and over again for 10 years.They clearly felt the next level of GTA lies in more immersion, more believable characters that sell you emotion.
It's simply Rockstar going from being top of the class in Adult Swim to trying to go to the top of the class in HBO.
And knowing Rockstar, they won't rest until they get there. And once they do, who knows what challenge they will take on next. Maybe it will be to create a GTA-RPG. That is what is so exciting about Rockstar.
For now though, you are going to have to trust them to give you characters that best fit the world.
Monday, 27 August 2012
Variety may be the spice of life
But it sure as hell doesn't get you anywhere when it comes to a project.
What am I talking about? Well, since that last post I have 'put on hold' the POTUS game, started a top-down-zombie-shooter-tower-defense game on XNA and now, I have gone a little Hollywood.
That's right, 3D. I have also gone into Unity, which has made quite the impression on me in these super early stages.
In two hours, with great help from this dude, I have made a 3D 'cube floor' with a 3D 'evil cube' chasing me on it:
I wanted to go 3D and I wanted to work on writing AI, as I had little to
no idea on how to do it. And voilĂ , two birds with one stone. Of course
this is all basic stuff but any step is a good step.
The great thing about Unity is, all that took literally about five lines of code. The controls, graphics, even the targeting was all handled by Unity. All I had to say was in basic code "move evil cube to where player is" and done. As Mr Burns would say, that is simply, eeexceeleeent.
I could write more about how great Unity is but is there any need. And anyway this is not a Unity advertisement but it just goes to show as someone who is new to all this, how a widely accepted game engine like Unity, even to a newbie, immediately shows why it is widely accepted.
So, the big question - What is next? Well, I would like to actually finish one project but I can't seem to help venturing off to new exciting places. After all, this is a hobby but there is no harm in a hobby turning into a portfolio of sort I guess. Which means the plan is to finish the top-down-zombie-shooter-tower-defense game on XNA.
Speaking of which, here it is in all it's early-stage glory (programmers never were good at art):
It is worth noting the back end of the top-down-zombie-shooter-tower-defense game is super tidy. It is definitely the tidiest project I have made and I am very proud of it in that aspect.
The game side of it, I will try a couple of small detail things that won't blow anyone away but hopefully will make for somewhat an intriguing experience. They might not even work well, I just want to experiment with some game design.
Anyway, I'll make a separate post for that in a while when it advances a bit more. Today's post was all about variety (or ADHD), Unity, 3D and...EVIL CUBES!
What am I talking about? Well, since that last post I have 'put on hold' the POTUS game, started a top-down-zombie-shooter-tower-defense game on XNA and now, I have gone a little Hollywood.
That's right, 3D. I have also gone into Unity, which has made quite the impression on me in these super early stages.
In two hours, with great help from this dude, I have made a 3D 'cube floor' with a 3D 'evil cube' chasing me on it:
![]() |
The red line is a debug line showing what the evil cube is targeting (which is poor old me!). |
The great thing about Unity is, all that took literally about five lines of code. The controls, graphics, even the targeting was all handled by Unity. All I had to say was in basic code "move evil cube to where player is" and done. As Mr Burns would say, that is simply, eeexceeleeent.
I could write more about how great Unity is but is there any need. And anyway this is not a Unity advertisement but it just goes to show as someone who is new to all this, how a widely accepted game engine like Unity, even to a newbie, immediately shows why it is widely accepted.
So, the big question - What is next? Well, I would like to actually finish one project but I can't seem to help venturing off to new exciting places. After all, this is a hobby but there is no harm in a hobby turning into a portfolio of sort I guess. Which means the plan is to finish the top-down-zombie-shooter-tower-defense game on XNA.
Speaking of which, here it is in all it's early-stage glory (programmers never were good at art):
![]() |
Credit for tutorials/help to this dude |
The game side of it, I will try a couple of small detail things that won't blow anyone away but hopefully will make for somewhat an intriguing experience. They might not even work well, I just want to experiment with some game design.
Anyway, I'll make a separate post for that in a while when it advances a bit more. Today's post was all about variety (or ADHD), Unity, 3D and...EVIL CUBES!
Monday, 7 May 2012
The State of things
Having a menu system built was one of my top priorities, because well, that's the first thing the game has. When I started as a complete clueless game programmer, I thought that would be one of the simplest things. After having a few mini-projects built, none of which having a menu system, showed me that it was in fact one of the harder things.
It's because the creation of menus is tied to a key component of the code and that is the key to managing the state of the game. Once I read about it and understood it (or I thought I understood it), I just couldn't apply it, there was something missing. I tried understanding Microsoft's game state management project, and even though I could do simple things within it, if someone asked me to reverse engineer that, I simply couldn't. As I didn't know the thinking behind it when building it.
And I think reverse engineering any given code is important because if you can't, it means you don't know what it's doing and most of your coding later on will be based on luck or hours of frustration until you fumble into the solution.
So I did more and more reading and finally came across this amazing tutorial. There is not much to say about it other than it walks you through the process which is amazing. And it is a process that leads to an amazingly built clean and powerful library. It still took me some time to understand his explanation but the fact I now have a state management system that I can reverse-engineer is a great boost.
It does lack one thing though, it doesn't set exercises for you to make sure you understood what he is doing. So it is worth doing few exercises on your own. Like adding a screen from scratch that he doesn't have. Having menus go into other menus, or having a Exit game showing you a "are you sure?" pop-up. By end of Part 4 I could do all that confidently which is a testament to the strength of his "show code, explain code" method.
That is another thing done. Now I really need to figure out, as mentioned in the last post, what kind of project I actually want. Otherwise it's hard to code when I don't know what I should be coding. If nothing comes to mind it'll be a collection of mini-games that are different genres, or I might emulate an existing game in full somewhere down the line.
For now though, learning continues.
It's because the creation of menus is tied to a key component of the code and that is the key to managing the state of the game. Once I read about it and understood it (or I thought I understood it), I just couldn't apply it, there was something missing. I tried understanding Microsoft's game state management project, and even though I could do simple things within it, if someone asked me to reverse engineer that, I simply couldn't. As I didn't know the thinking behind it when building it.
And I think reverse engineering any given code is important because if you can't, it means you don't know what it's doing and most of your coding later on will be based on luck or hours of frustration until you fumble into the solution.
So I did more and more reading and finally came across this amazing tutorial. There is not much to say about it other than it walks you through the process which is amazing. And it is a process that leads to an amazingly built clean and powerful library. It still took me some time to understand his explanation but the fact I now have a state management system that I can reverse-engineer is a great boost.
| This is what you end up with after following the tutorial. As simple as it looks, it has a powerful code backing it. |
It does lack one thing though, it doesn't set exercises for you to make sure you understood what he is doing. So it is worth doing few exercises on your own. Like adding a screen from scratch that he doesn't have. Having menus go into other menus, or having a Exit game showing you a "are you sure?" pop-up. By end of Part 4 I could do all that confidently which is a testament to the strength of his "show code, explain code" method.
That is another thing done. Now I really need to figure out, as mentioned in the last post, what kind of project I actually want. Otherwise it's hard to code when I don't know what I should be coding. If nothing comes to mind it'll be a collection of mini-games that are different genres, or I might emulate an existing game in full somewhere down the line.
For now though, learning continues.
Wednesday, 14 March 2012
Jack of all trades, master of none
I have been messing around with XNA a lot more now. Got my head around *basic* game development in general and it is nice to know when I try another engine like Unity, I am not completely clueless. Add my experience to millions of developers out there when they say, if you learn one, you can use them all.
This blog has served its purpose, it pushed me through the harsh beginnings but now I feel whenever I want to post here it's going to be a tutorial you can find 100s of out there (lots of great XNA help on the web) or it's going to be half-baked ideas/demos like the ones below.
I have done side scroller, top down mechanics [seen below] and am now working on point and click but I never get too far because I have no vision. So I need to sit down and do the pre-development phase, and get a full vision for a game before I sit down to code it. That is what I have learnt from all this. Seems obvious in hindsight but after all this started as strictly programming exercise.
I will open another blog [or post here] when I have a game in mind and it'll be much more interesting to blog a game progress instead of random programming ramblings.
Hope to see you then.
This blog has served its purpose, it pushed me through the harsh beginnings but now I feel whenever I want to post here it's going to be a tutorial you can find 100s of out there (lots of great XNA help on the web) or it's going to be half-baked ideas/demos like the ones below.
I have done side scroller, top down mechanics [seen below] and am now working on point and click but I never get too far because I have no vision. So I need to sit down and do the pre-development phase, and get a full vision for a game before I sit down to code it. That is what I have learnt from all this. Seems obvious in hindsight but after all this started as strictly programming exercise.
I will open another blog [or post here] when I have a game in mind and it'll be much more interesting to blog a game progress instead of random programming ramblings.
Hope to see you then.
Sunday, 30 October 2011
Objectify the world (and running into walls, literally)
Here is a video of Ash running into walls:
This has happened to me the other day, I wanted to modify something in my file and ran into hours of hair ripping frustration, simply because:
Also I don't get a lot of time to work on this, what with work-work and uni work. But hopefully next update should be a good one (and less word heavy, more screens/videos), as the foundations for the game are slowly but surely building.
Note: The lag comes from FRAPS.
This version is different from the last version of my project that was posted. You might be thinking, "duh, you went from a side scroller to a top down adventure game". While that is the obvious change, there is a much more important change hidden away at the back-end; everything is objectified.
This is a key programming technique that most tutorials I went through to learn stuff ignored for some reason. This caused huge confusion and mess when trying to implement different aspects from different tutorials.
This confusion and mess in fact is why object-orianted programming took off. It's much easier to design, code, and manage.
It didn't help the confusion and the mess that I didn't know 100% what was happening in those tutorial files. So I just want to take a minute to write about being careful about doing tutorials. Learn the process, don't just do it. If you don't understand the ideas behind the code, even if you understand the code itself (there IS a difference between the two), it will cause you a lot of problems in the near future.
This has happened to me the other day, I wanted to modify something in my file and ran into hours of hair ripping frustration, simply because:
- It wasn't OO (object oriented)
- I wasn't really sure what was going on in the code because I didn't understand the tutorials fully as I was doing them
So those are two things that stuck with me through this experience and I took my knowledge from the side scroller project to a new project that is coded better/tidier from the ground up and is in a genre I am much more interested in working with.
Other than learning through pain and transitioning to a new project, I've also been working on:
Other than learning through pain and transitioning to a new project, I've also been working on:
Collision
It was a big pain and I'm glad it is out the way. It got out the way hugely thanks to this tutorial. Not only did he nicely explain the concept and the practise behind the collision engine, he also gave a source file that was OO! So, a great help there.
With the code objectified, and collision engine set-up, I can now at least design a screen, which gives me great momentum to carry on this project.
Speaking of design, everything you see is placeholder assets.
To do list
(in the order of where they are swimming around in my head):
(in the order of where they are swimming around in my head):
- Animation- As you may have noticed, there is no animation. Last engine I used shown in the last post was way too messy and didn't go well with my clean OO project. Not to mention, once again, I hadn't fully grasped it. I will be implementing one that I understand and so even if it isn't neat, I can tidy it up myself.
- Screen management- Figure out screen management system and implement it. Once implemented, it will give me a main menu, in game menus and ability to switch screens. This one is a biggie and will be another momentous push once figured out.
- Do some paper work design- This is indeed mostly a programming project, but I also want to get some paper work done on the game itself. Design screens on paper, script, some kind of back story, overall story arc, and so on.
- HUD- I am mainly thinking a mini-map but my [so far] little research lead me to believe it might be way out of reach of my current abilities, not to mention the game might not need it. If I'm convinced the game needs it, it will probably be one of the later things I build so I am better experienced by that point and the location layouts have been designed that the mini-map can copy.
Also I don't get a lot of time to work on this, what with work-work and uni work. But hopefully next update should be a good one (and less word heavy, more screens/videos), as the foundations for the game are slowly but surely building.
Monday, 17 October 2011
I like to move it move it!
Animations done! Shown in video: 'idle' animation. More to come (not silly little videos, updates...and maybe silly videos).
Subscribe to:
Posts (Atom)

