Personal Blog - Happy Holidays!

Thought I'd take the opportunity to wish everyone a good break, and I'm already looking forward to seeing you all again when the next term begins. And thanks to James for a great introduction to Games Development!

I'm going to be using the time off to try and fix up this blog, seeing as I've not been able to get around to it beforehand. I already sorta know that I could probably do with making it a bit simpler than I was intending to... only a bit simpler, mind you. And catch up on sleep, of course. Lots and lots of sleep.

Anyway, happy holidays!

Assignment 7 - Game Engines

Assignment 7 Game Engines

In this assignment, I will be looking at four game engines either currently in use in today's game industry, or engines that will be released in the future for next generation games development.

Unity Engine 4 is an engine released during the Summer of 2012, and comes in two forms... the basic free version and a paid for Unity Pro version. The engine was originally developed for Apple platforms, although it has since evolved to encompass any platform from games consoles to mobile phones. The developers state that their intention for Unity is to provide a low cost engine to enable more developers to afford to create new games quickly and cheaply, and to that end it includes several features including an asset shop to download ready made assets and supporting software which can cut time considerably. Unity also includes inbuilt animation capabilities to allow animation and motion capture within the engine, certain assets created outside the engine to be automatically updated without requiring files to be uploaded with edits, and for textures and assets to be used across games designed for multiple platforms. Overall, my impression of the engine is that it lacks the punch of other engines, but the above aspects on top of making use of C+ programming languages serves to help a games development team produce games for consoles and phones in a fairly efficient manner, and therefore seems like an engine that would benefit those that are new to the games industry.

The Source engine was developed by Valve and showcased in 2004 in the games Counter Strike : Source and Half Life 2. Since then, the engine has gone through several upgrades as technology has advanced, the same engine being used in more recent games like Portal 2 and Defence of the Ancients 2 with new features designed to ensure the engine's long life, like improved particles and lighting. Additionally, the Source engine is accessible to anyone whom has purchased at least one game, which has made the engine very popular amongst the modding community, although the vast majority of games that are made using Source tend to be First Person Shooters – Exceptions include the RPG Vindictus and the top down shooter Alien Swarm. However, aside from the latter games mentioned, relatively few games have been developed commercially with the Source engine outside of Valve itself, with the unwieldy SDK tool set and a need to deeply understand coding commands being amongst the chief reasons for being underused – with Valve employees all being required to understand how Source engine functions.

Unreal Engine 3 was developed by Epic Games in 2004, and as with previous versions of the engine it has proven highly popular in the games industry, with flexibility to create many different genres of game and a largely intuitive tool kit. Many games I have enjoyed over the years have utilised the engine, including the Gears of War series (made by Epic) and the Mass Effect series, and both of these games are distinctive from one another... with one being a cover based shooter and the other being an RPG. Like Source, UE3 has proven very popular within modding communities, and in 2009 Epic further opened up their engine to allow the development of mods into stand alone games in exchange for royalties and a small fee.

And the last engine I looked at is one that is not yet available, and that is the Luminous Engine by Square Enix, with the real time tech demo “Agni's Philosophy” recently being showcased to demonstrate it's capabilities. First and foremost, Luminous is an engine very much aimed towards taking full advantage of the next generation of gaming consoles, but it also offers the flexibility of being used for a variety of current platforms and mobile devices... a feature similar to that of Unity 4 and therefore potentially of greater benefit to games development teams being able to use one engine to create games for different platforms instead of learning to use multiple engines and of course widen the audience developers can aim at.

One aim for Luminous has been to create an engine capable of creating graphics on par with those used in pre rendered animation, and this also includes aspects like creating particles and lighting on the fly rather than having to render these sorts of changes, which can consume time as builds are tested and iterated on.

Assignment 7 - Luminous Engine

Luminous Engine? A next generation engine currently in development by Square Enix. There, that was a nice start.

In all seriousness however, I've found direct information on what the engine is capable of to be rather... ... sparse. The most recent tech demo released is Agni's Philosphy, a real time demonstration of the engine's capabilities, which I understand many people have already seen in class, but just for emphasis -:



I've only really found articles on gaming sites that hint at the intention of the engine besides improved lighting and an ability to produce pre render quality graphics, with no games presently said to be in development using the technology.

 http://www.edge-online.com/news/square-enix-shows-photo-realistic-next-generation-engine/

http://kotaku.com/5848982/square-enixs-new-engine-could-mean-pretty-games-faster/gallery/1?tag=luminous-engine

A couple of things that I DID uncover however claim the the engine is capable of reflecting light more efficiently than current gen with colours being reflected off coloured surfaces, and including animation capabilities that automatically adjust character animation when using equipment of different weight or if they are walking on uneven surfaces, something chiefly designed to create increased realism in next generation games. If I were to think of games like Elderscrolls Skyrim, character animations were very fixed even when running or fighting on sloped surfaces, or the entire character rising upwards if stepping on a rock.

On top of that, like in Unity 4, the engine is also planned to be functional for multiple platforms, working on current generation platforms as well  as those of the future, and ranging from consoles to phone devices... with graphics etc being scalable.

Assignment 7 - A look at the Unity Engine

I'm not nearly as far into the research as I would like to be at this late stage, but I'm doing the best I can. It is likely that I will be doing some work in college... at least, that is the hope. If there is somethign else going on during the class, then I may be sliiiightly scraped for time.

But I thought a good place for me to start working was the Unity Engine, it being something that we didn't discuss in class. And on reflection, this is proving to be a fortunate choice, for reading up on what the engine is capable of has given me features to look out for in the rest of my research.

I shall try not to regurgitate information found on either their website or their Wikipedia page, but in essence... the engine seems to be focused on accessibility and workflow. Without having used their engine directly I cannot possibly say for certain whether this is indeed the case, but based on their word... Unity is capable of publishing content onto multiple gaming platforms... for example, publishing on Xbox 360 and Playstation 3 without having to work on seperate versions. Being a player of games upon PC, I have witnessed first hand some rather shoddy ports of console games, normally as a result of developers outsourcing to external companies... I imagine that at present, creating the same game for different platforms can be time consuming and a drain on resources and time for game developers. To be able to do this without using too much manpower or exporting it to another company... well, that would certainly save time and money for a team.

Another aspect of the engine seems to revolve around an in-application store where assets can be purchased... and although I question why a development team would want to use something premade... I can appreciate the usefulness this could bring to speeding up the production cycle, like say... if I were making a game and I had a lot of content to create, then being able to purchase some elements to enable more time to work on other elements would be a considerable boost.

I also read about the engine being able to accept edited image files without having to reimport the file intothe engine everytime. That gave me a teeny tiny flashback to Thursday when I saw the on the fly lighting and particle systems in the UE4 engine. That might not be the greatest comparison, given that particles would rather trump imagery/textures, but in both cases, these are all about shaving time off work schedules, and that can soon add up.

And I think I'm going to stop there for now. It is a start.

(Edit: This link )

Assignment 7 - Initial Thoughts

I'm afraid that I haven't had much chance yet to get down to even writing this entry, let alone actually get on with the research. As it stands, I'm now in the midst of moving my belongings into a newly decorated bedroom, but I'm hoping to have this out of the way by Monday.

But to talk on the subject of this new assignment, which is to take a look at 4 game engines and write 1000 words overviewing each of those engines, I have to say that the lecture we had on Thursday was quite the eye opener. I struggled at first to think about how game engines could be used to quicken the working process of developers, and on reflection this stems largely from never having really known just what these engines can actually do NOW, or what technology is just around the corner. I really don't know what I was expecting.

I find the topic to be very interesting, however. I already know that I'm going to take a look into the following;

• Unreal Engine
• Source Engine
• Unity Engine

But I'm still looking for that final engine to fill in the empty space. I'm resisting the instinct to look at Cry Engine... partly because I have no real connection to any of the games made with that engine, and partly because I feel like it would be cheating to look at that on top of Unreal and Source after looking at all three in class. I'm going to finish my move and then think of some games I've enjoyed playing and finding out what engine powers them.

(I did try to look at Visceral Engine, used in Dead Space 2... but I'm really guessing that is an internal engine, I really couldn't find any information on it other than as part of a top ten on IGN. Oh, and a wikipedia entry that only exists in Russian... which I somehow suspect doesn't have anything to do with what I might be wanting to research. 

Onwards and outwards!

Assignment 6 Conclusion

Tuesday has been and gone, work handed in and everyone's work reviewed in an informal discussion. Everyone did very well with the assignment, and it was great to see what sort of levels were being made.

What I didn't enjoy though was having to stand in front of the class and explain the map. And this isn't necessarily because I am shy... because really, I'm not. I'm just not capable to thinking up a talk on the spot, and I was simply caught offguard and unable to express my reasoning for the level being structured as it was. Hopefully I can do that now.

In essence, I felt that I bit off a little more than I could chew with the level, setting it in an outdoor environment, although I still believe that I worked the best I could and made something that with some further development could be made into something fun and challenging. And the one thing that I really want to get off my chest is that although I did not place too many placements specific to certain classes, if one is to look into the level design of the maps already in Mann Versus Machine, they are not made to the same standard as say, a capture point or payload map. There is not quite so much emphasis on creating class specific routes and that is because the AI used in the mode follow fixed paths... fixed paths that can differ from wave to wave, but fixed paths none the less, and with very few exceptions there are not spots or paths that can only be accessed via double jump or rocket/sticky jump. I made the level so that certain points COULD be rocket jumped and certain distances double jumped, but at no point did I want to create an area that could potentially prevent robots from being able to reach players.

I made some poor design choices along the way, and the more I look at the map now, the more I wonder if I really should have had the path go back on itself toward the end... or if the level is simply too long in length. In any scenario, I'm satisfied with the assignment, and if anything it only gives me the drive to go back to the drawing board and refine the design some more. I made the mistake of ending up working on the fly rather than drawing out alternate ideas... one I shall try not to repeat next time.

Assignment 6 3D Level Design

I consider this as close to being finished as I can achieve whilst flailing my hands on the keyboard in the vague hope I'm learning something.

Anyway, this is my map for the assignment, a Mann vs Machine level for Team Fortress 2. And to explain MvM in a nutshell, players spawn on one side of the map, which is also the area they are defending. AI controlled robots approach from the other side of the map, trying to deliver a bomb to the player spawn... if the bomb makes it, the wave is lost... and if the players defeat all the robots, the wave is won.

I designed my map around the idea of a vertical level (Inspired by Upward and Offblast maps in TF2), meaning that the map itself may not be all that large, but the ability to ascend and descend compensates for this. The idea was partly inspired by the airblast mechanic as used by the Pyro, a level that held a lot of opportunities for being pushed off the map or to a lower level. I included fences to make it harder for a Pyro without upgrades to achieve this.

  And so yes. Basically, the robots start at the bottom of the map, and climb their way up to the top, and the players must prevent them doing so. (Would write more, but short on time thanks to sudden dinner and early trains)

Assignment 6 - 04/12/12 @ not 7pm

 And I've probably got as much done as I feel I am able to do. I might make some final adjustments when I next wake up before heading to college, but for the most part, this is my level.

I'm going to draw up a proper key to accompany these pictures and the work I'll be submitting when I hand in the work tonight. But in a nut shell, the magenta signifies areas that the player cannot walk on, and the bright blue signifies robot spawns. I hid some extra spawns in other parts of the map as well to allow for spy bots to appear behind players. The green squares in turn signify ammo and health pick ups, and the tiny bit of red is the player spawn.

I wanted to include two 2-story buildings on either side of the map to provide another route to the higher road near the end, but I found it too fiddly to hollow out the grey blocks I created as placeholders. I may add black squares to signify entrances and exits. I also had to move the alternate routes from the first island to the second, although I like this compromise... it fits a lot better.

First part of the map, robot spawn point.

First mountain on the second 'island'

The alternate route off the main path... links up to the third 'island'

Player Spawn and Bomb Chute. Medic for size comaprison.

Assignment 6 - 03/12/12 Part 3

I seem to be doing a lot of updates today. But given that development has to be shown, I might as well explain what I'm up to at present.

I decided to ask some friends about their thoughts on the design I had from the previous post, and the feedback was positive... one said that it would make a great Payload Race Map (Another mode in Team Fortress 2, where each team has a bomb that they are trying to push to a goal whilst trying to stop the other team from doing the same.), and to add some platforms and such.

Building/cover placement has proven difficult and it continues to give me grief as I try and finish the design... it is starting to deviate significantly from the top down design I drew up to help me. The main path towards the objective remains relatively unchanged, although the alternate route for the first section of the map has had to be removed due to the space between the first and second section being a lot larger than I thought it would be. I still need to get that alternate route in somewhere, although I also need to think about platforms that players can set up snipers or sentries on, and luckily I'm on the right path I think.

I'm also still having to consider which areas are going to be falling hazards, and which aren't. Without further ago, pictures.

View of the front of the map. The bottom left platform will be the area that robots spawn during each wave.

View of the back of the map. The red circle signifies the bomb chute, and the red roofed blocks are the player spawns.

Top Down view. The basic design is relatively faithful to the drafts.

Assignment 6 - 03/12/12 part 2

The work continues. The terrible realization that I've perhaps made the map too large has started to dawn on me, but I feel that it is now a bit late to change much of this. Priority remains getting the actual map done before I try to make corrections, and for the most part I am still working alright with my top down design. But enough typing, updated pictures.

The image that makes me honestly believe that the level is too large. Those two blurs towards the left are a Heavy and Medic.

Assignment 6 - 03/12/12

My work isn't progressing as quickly as I was hoping it would. It doesn't help that half way through, I realised that I could make things simpler on myself by concentrating on one side and then using the flip along action to mirror the map. This is likely going to be rather useful to me as well as hopefully speed up my progress in the final stretch.

Also working against me is the realization that I could work the paths a little differently to provide more of that vertical gameplay I want. I will only make those additions if I feel like I have enough time to do it.

It still isn't anything to look at, but another couple of screenshots taken just a few moments ago.

Assignment 6 - What am I doing?

I'm not uploading any more pictures, at least not yet. When I get round to showing some other aspects of my research, I'm going to try and link the images to their original source.

But I've not made much progress over the last couple of days. I've had a busy couple of weeks and I've been trying to unwind with little success. Some research has been made into New Mexico deserts to try and get a feel for what I'm trying to do, although I'm undecided if I'm basing the level on that classic TF2 default or if I'm perhaps going to go more for the Alpine theme that the game also features.

That said, I don't think I'm going to be able to make the map all THAT elaborate. I simply don't know Sketchup well enough and I'd rather get the level completed then get lost in details. Historically, I'm very much someone that wants to make things as perfect as possible... but I already know that I don't know how to do the things I want to do here. Curved, sloping paths that connect each vertical height are my main obstacles right now, and I'm close to resorting to keeping it square for the sake of simplicity. Priority remains getting the map planned out before I try to make anything look even slightly more organic.

I want to be able to hand the work in on Tuesday with something that resembles a map design.