To anyone who happens to look here, I have set-up a new blog for my dissertation (just to highlight it and keep it separate). It can be found at the following address http://scarletnightmares.blogspot.co.uk/
So until next time, that's all folks!
Monday, 20 August 2012
Sunday, 6 November 2011
Managing Games and some other stuff
Right, here I am back for the bi-weekly blog post on the readings that we've undertaken at Uni. As the title suggests, the readings that I am going to be talking about are related to managing games and some other stuff... I say some other stuff because the readings that we had this week were about Games Design in general rather than a specific type of game. There were 2 readings relating to managing for one week and a reading based around the layers of Games Design and another about rules of play in Games Design for the 2nd week. So let's dive right into this thing and kick off with the managing games.
-----------------------------------------------------------------------------------------
Managing Games
Right well, I said there were 2 readings for managing games... and there were but... the 2nd was a bit... meh (or at least I thought it was - I got 1 note from it which was 'Interaction in management games fuels narrative simply')... so I'm only going to talk about the other reading which comes from Trefry's book on Casual Games Design as many of the other readings have and more specifically it is chapter 7 of Trefry's book.
In this chapter, Trefry goes on to explain what makes a managing game, what they are and why we find them fun and all the usual stuff - yet again backing up all his work with a plethora of examples to get his point across. I know it may seem like I keep having a go about it and well, that's because I am, but seriously, the guy needs to learn to shorten the amount that he talks about specific game examples. Anyways, back on topic, Trefry states that games often walk a fine line between work and play - at their core, with games we as the player need to put in effort to see outcomes which is much like work. Managing games in particular though are almost exactly like work though rather than walking the fine line between work and play, this is because, for the most part, managing games tend to be simulations of a job.
While only a couple of examples, Cake-Mania and Diner Dash illustrate the idea that managing games simulate work. Cake-Mania puts the player in charge of a cake shop and it is their duty to make cakes to the customer's specifications and Diner Dash makes the player a waitress in a, well, diner, and has them takes orders, etc. This shows that these games merely simulate an actual existing job and for that reason the games are literally a means of work - of course they are not the same as doing the job yourself but they are the closest you can come to doing the job without actually doing it. Trefry alludes to this himself, stating that he believes that this is part of the appeal of managing games (despite being work) as it allows people to experience different jobs that they otherwise would not be able to do.
Trefry then does on to explain in-depth about what it is that makes Cake-Mania and Diner Dash work for them, the bits that you can take and apply to managing games in general however though are management games are essentially keeping track of multiple variables, in Diner Dash it is merely multiple timers whereas in Cake Mania it is remembering different ingredients. He even makes a link to RTS (Real-Time Strategy) games an how they are partially management games as they are keeping track of multiple units parameters, etc.
Trefry then goes on to use a couple more examples but there's nothing worth mentioning from them in particular. In summary, with managing games, as they are just keeping track of various variables you have to remember not to overwhelm your player as they boil down to the ability to keep focus more than anything else - at the same time however they must be demanding as this is where the fun of these games comes from.
------------------------------------------------------------------------------------------
Layers of Games Design
The next reading that I am going to talk about is an article by Tony Vetrice called 'The Four Perspectives of Games Design'. The article basically talks about thing that we discussed last year about how Designers see games in a different way to how the consumer ultimately sees them, how they all link together and so on, but despite this I actually found it an interesting articles to read.
Vetrice breaks up the 4 layers into Concept, Paradigm, Mechanics and Features, and Interface and says how the only thing that is truly inventive and created is the concept - everything else may be added as and when it is needed but these needs stem from the concept; the same is true with the 3 other perspectives. Basically, the concept leads to the paradigm which leads to the mechanics which leads to the interface but these things can all flow through and affect each other - all stemming from the concept. Concept is basically the idea, paradigm is the frame of mind the player (unknowingly) uses, mechanics support the paradigm/enables the player to do it and finally the interface is how the player sees and uses the mechanics.
There isn't much to say on concept as it is self-explanatory so I'll move on paradigm... Paradigm is something the player knows about the game or what to expect from it just from what type of game it is - Genre is a good way of exemplifying paradigm; from the genre of FPS or Strategy the player will know exactly what type of game it is but the specific mechanics and features of that game will (or rather, should) be different to other games. Mechanics is what the designers and programmers work on and understand more than the consumer, the mechanics are added to make the game work, they add or remove mechanics as they are needed and shape them into what makes the game unique. Finally, Interface is how the player sees all this stuff that the designer has made - the player doesn't need to necessarily see EVERY mechanic but the mechanics are still there working nonetheless; they need to see only what they need to and not be overwhelmed.
So that is basically it, it's a good read and re-affirmed stuff we knew but in a different and interesting way.
------------------------------------------------------------------------------------
Rules of Play
Finally, the last reading comes from Eric Zimmermann and Katie Salen entitled 'Rules of Play: Games Design Fundamentals' and... well... it is a good read but it was difficult to read and take notes on... I don't know why... I just did... The article talked about conflict in games, how it leads to goals, how it stems from rules, and so on and was generally very in-depth about it but, to be honest, none of it was anything new - it was stuff we had looked at and read last year and it is very much imprinted into my brain now... maybe that was why I found it hard to take notes, I don't know.
Anyways, to sum the article up, Conflict takes many forms individual conflict the game's AI or co-operative conflict against the AI or conflict against each other, this conflict is defined by the internal rules of the game world and the conflict in turn leads to the goals of the game. The player goes through this conflict as a competition to reach the goal and finds fun in this, however, the game must be fair and balanced otherwise the player will just think it is unfair and quit.
------------------------------------------------------------------------------------------
So there we have it - the readings from this week. 'Til next time - that's all folks!
-----------------------------------------------------------------------------------------
Managing Games
Right well, I said there were 2 readings for managing games... and there were but... the 2nd was a bit... meh (or at least I thought it was - I got 1 note from it which was 'Interaction in management games fuels narrative simply')... so I'm only going to talk about the other reading which comes from Trefry's book on Casual Games Design as many of the other readings have and more specifically it is chapter 7 of Trefry's book.
In this chapter, Trefry goes on to explain what makes a managing game, what they are and why we find them fun and all the usual stuff - yet again backing up all his work with a plethora of examples to get his point across. I know it may seem like I keep having a go about it and well, that's because I am, but seriously, the guy needs to learn to shorten the amount that he talks about specific game examples. Anyways, back on topic, Trefry states that games often walk a fine line between work and play - at their core, with games we as the player need to put in effort to see outcomes which is much like work. Managing games in particular though are almost exactly like work though rather than walking the fine line between work and play, this is because, for the most part, managing games tend to be simulations of a job.
While only a couple of examples, Cake-Mania and Diner Dash illustrate the idea that managing games simulate work. Cake-Mania puts the player in charge of a cake shop and it is their duty to make cakes to the customer's specifications and Diner Dash makes the player a waitress in a, well, diner, and has them takes orders, etc. This shows that these games merely simulate an actual existing job and for that reason the games are literally a means of work - of course they are not the same as doing the job yourself but they are the closest you can come to doing the job without actually doing it. Trefry alludes to this himself, stating that he believes that this is part of the appeal of managing games (despite being work) as it allows people to experience different jobs that they otherwise would not be able to do.
Trefry then does on to explain in-depth about what it is that makes Cake-Mania and Diner Dash work for them, the bits that you can take and apply to managing games in general however though are management games are essentially keeping track of multiple variables, in Diner Dash it is merely multiple timers whereas in Cake Mania it is remembering different ingredients. He even makes a link to RTS (Real-Time Strategy) games an how they are partially management games as they are keeping track of multiple units parameters, etc.
Trefry then goes on to use a couple more examples but there's nothing worth mentioning from them in particular. In summary, with managing games, as they are just keeping track of various variables you have to remember not to overwhelm your player as they boil down to the ability to keep focus more than anything else - at the same time however they must be demanding as this is where the fun of these games comes from.
------------------------------------------------------------------------------------------
Layers of Games Design
The next reading that I am going to talk about is an article by Tony Vetrice called 'The Four Perspectives of Games Design'. The article basically talks about thing that we discussed last year about how Designers see games in a different way to how the consumer ultimately sees them, how they all link together and so on, but despite this I actually found it an interesting articles to read.
Vetrice breaks up the 4 layers into Concept, Paradigm, Mechanics and Features, and Interface and says how the only thing that is truly inventive and created is the concept - everything else may be added as and when it is needed but these needs stem from the concept; the same is true with the 3 other perspectives. Basically, the concept leads to the paradigm which leads to the mechanics which leads to the interface but these things can all flow through and affect each other - all stemming from the concept. Concept is basically the idea, paradigm is the frame of mind the player (unknowingly) uses, mechanics support the paradigm/enables the player to do it and finally the interface is how the player sees and uses the mechanics.
There isn't much to say on concept as it is self-explanatory so I'll move on paradigm... Paradigm is something the player knows about the game or what to expect from it just from what type of game it is - Genre is a good way of exemplifying paradigm; from the genre of FPS or Strategy the player will know exactly what type of game it is but the specific mechanics and features of that game will (or rather, should) be different to other games. Mechanics is what the designers and programmers work on and understand more than the consumer, the mechanics are added to make the game work, they add or remove mechanics as they are needed and shape them into what makes the game unique. Finally, Interface is how the player sees all this stuff that the designer has made - the player doesn't need to necessarily see EVERY mechanic but the mechanics are still there working nonetheless; they need to see only what they need to and not be overwhelmed.
So that is basically it, it's a good read and re-affirmed stuff we knew but in a different and interesting way.
------------------------------------------------------------------------------------
Rules of Play
Finally, the last reading comes from Eric Zimmermann and Katie Salen entitled 'Rules of Play: Games Design Fundamentals' and... well... it is a good read but it was difficult to read and take notes on... I don't know why... I just did... The article talked about conflict in games, how it leads to goals, how it stems from rules, and so on and was generally very in-depth about it but, to be honest, none of it was anything new - it was stuff we had looked at and read last year and it is very much imprinted into my brain now... maybe that was why I found it hard to take notes, I don't know.
Anyways, to sum the article up, Conflict takes many forms individual conflict the game's AI or co-operative conflict against the AI or conflict against each other, this conflict is defined by the internal rules of the game world and the conflict in turn leads to the goals of the game. The player goes through this conflict as a competition to reach the goal and finds fun in this, however, the game must be fair and balanced otherwise the player will just think it is unfair and quit.
------------------------------------------------------------------------------------------
So there we have it - the readings from this week. 'Til next time - that's all folks!
Monday, 24 October 2011
The paper prototyping
Another quick blog, basically me being lazy. Basically, over the weekend, to assist us in our modding module, Tom, Matty & I decided to paper prototype the map that we have designed. We first of all did a paper based prototype to help with room arrangements and potential layouts and then, once we had finalized our map, made it in 3D(ish) using foam-board and cork.
The reason why this blog post is lazy is that, rather than me blogging all the pictures and inforamtion about our prototyping process I am simply going to redirect you to Tom's blog where he has posted about our prototyping session - no point in both us doing it when we did the same thing.
So yea, here's the link:- http://weaveswonderblog.blogspot.com/2011/10/weekend-paper-prototyping.html
'Til next time - that's all folks!
The reason why this blog post is lazy is that, rather than me blogging all the pictures and inforamtion about our prototyping process I am simply going to redirect you to Tom's blog where he has posted about our prototyping session - no point in both us doing it when we did the same thing.
So yea, here's the link:- http://weaveswonderblog.blogspot.com/2011/10/weekend-paper-prototyping.html
'Til next time - that's all folks!
Friday, 21 October 2011
Making money from flash games essay
Quick blog post as it's easy to do - just copy and pasting my essay from Uni. The essay we had to write was a written report on the ways in which games developers can make money through making flash games, discussing how effective they are and the optimum route to take.
So, here is my essay. Enjoy!
--------------------------------------------------------------------------------------------
So, here is my essay. Enjoy!
--------------------------------------------------------------------------------------------
Monetising Flash Games
Adobe Flash professional is a great program for making games suitable for Flash websites and social websites as the games are quicker and cheaper to make and get released than AAA console games. However, making Flash games and making money from them is more complex than console games and there are many routes that you can take, each with their own benefits and flaws. This essay will look at some of these routes, state the good and bad points of using them and sum up the recommended route a developer should take and why.
The first thing to note when making money from Flash games is that, regardless of the route you take, your Flash game will ultimately end up being uploaded to a website that is a hub for Flash games. Websites like Armor Games and Kongregate allow developers to upload their games, users then visit the website and can search through all the games available and play them. Most ways of monetising Flash games comes through various features and/or deals that come through uploading your games to these websites, these ways include, but are not limited to, the following:-
· Advertisement Revenue
· Sponsorship
· Licensing
· ‘Freemium’ Content
· Subscription Content
· Micro-transactions
Advertisement revenue is the most simple and easiest way to monetise your Flash game but it is not necessarily the most effective way. Once your game is uploaded onto a website, you as a developer can choose to allow the website to display adverts in the background of your game – this generates revenue whenever one of these adverts is clicked; the website takes some of it and the rest goes to you.
The main advantage of monetising your games like this is that it is very easy, you can rest easy knowing you don’t need to worry about setting the adverts up, etc, as it will all be done for you. The drawbacks are that money is only generated by clicking on adverts, not just looking at them, and most people won’t do this – you will ultimately need to do more than just sit back and wait for money. The best thing to do is to advertise yourself on the hosting website’s forums and blogs, attracting the users and visitors that use them to go and play your games; be careful though, if your game isn’t up to standard and people spread this around your game is finished.
There are further decisions to make with this though as you need to decide whether it is better or not to upload your games to just one website or many. If you upload your games to one website you will generate a solid user community for your games on that website, the game is easy to update and you know exactly where your money is coming from, on the other hand, you are limiting your audience and as a result it will be harder to get noticed and you will ultimately have less chances of getting money. If you upload your games to many websites you maximise the number of players and in turn maximise your money, however, it is harder to keep track of your games earnings and harder to update the games (as you will have to update your game on every website to ensure everyone is happy).
As a whole however, trying to generate revenue from advertisements alone really isn’t advisable if you are looking to make a major profit on your Flash game. As an example of why this is, looking at the research gathered on the blog of Lost Garden, an online blog that writes articles relating to art and game design, 2 millions users of your Flash game will generate about $650 of revenue which equates to just $0.000325 per user. These numbers alone speak for themselves as to why ad revue should not be used as the only source of income for your Flash games if you are trying to monetise them as efficiently as possible; you should use other methods alongside advertisements.
One such other method is to try and negotiate a sponsorship deal on your Flash game. Effectively what this entails is approaching the gaming websites or other independent sponsors and trying to get money from them to make your game – this money can be the website buying exclusivity of your game (either forever or for a period of time) or including branding of their website in your game, so that the website can be seen no matter where it eventually gets hosted.
The process is normally simple and generally speaking the deal will be made with the website that makes the highest bid for the best terms, not necessarily the one that makes the highest bid. An example of why this is so can be found at an article on the blogging website of games developer Andy Moore where he took a lower deal of $25,000 rather than the highest of $35,000 for his game ‘SteamBirds’ because the terms in the $35,000 deal meant he couldn’t make a sequel when he liked and the sponsor could refuse a sequel being produced, etc.
To further help with getting sponsorship there are actually specific websites that help developers find sponsors that are prepared to back them, for example, the website http://www.Flashgamelicense.com/ allows both developers and sponsors to sign up and allows them to seek each other out specifically.
The advantages of getting sponsorship are that you get money upfront, and normally a fairly reasonable sum, ensuring that your Flash game has made money before it is even released. Getting sponsorship itself is good for advertising and other ways of getting noticed as the fact that a website is prepared to invest in your game shows that it must at least be reasonably good – no one intentionally backs a loser. If the games you make are successful it also prompts the initial sponsor to want to back you again, creating a lasting chain of games development and revenue.
The disadvantages of sponsorship are that entering into sponsorship details can fill you with a false sense of monetary security and belief that your games must be good – even though you have been paid for your work and you have got the money, your game could still fail and you could lose future sponsorship deals and actually make no money through the game itself. Also, depending on the exact terms and conditions, you can limit yourself to a select audience (only visitors of the website you make the deal with). However, there is a way around this potential problem with the option to enter into a licensing deal rather than a sponsorship deal.
Licensing is similar to sponsorship except that is doesn’t limit exclusivity; it merely means a few versions of the game may need to be made. The reason for this is that licensing involves adding extra features, branding, etc, for the website that licenses your game but you are allowed to release the game elsewhere as long as these features aren’t included. As a result of this you will still receive money for promoting the licenser but can still draw in audiences from other sites and make money through them – typically though, due to this, the amount made through these deals are lower than those of sponsorship deals.
The advantages then of licensing are obvious, you gain the bonus of getting a lump sum of money for making your game simply for adding in branding, etc, for your game but with the added benefit that you can still make money from other sites.
As always though, there are some negative points, most directly the fact that in terms of initial money gain it is worse than sponsorship, so if your game doesn’t attract enough money through advertisement revenue, etc, to make up the amount that could have been gained through sponsorship you have ultimately lost out. Secondly, because of the fact that you have made an agreement with one website to effectively make a better version of for them, other websites that get the stripped down version of the game may feel a sense of animosity towards you as ultimately users will not visit their site to play the lesser version when they can play the version with extra features elsewhere.
Extra features themselves are good may to monetise Flash games. Extra features can effectively be grouped as ‘Freemium’ and subscription content, and Micro-transactions; all three are forms of charging users real money to get a boost of some sorts in your Flash game. The boosts are more often than not ways of getting stuff that is already available in your game quicker than what is naturally available – and you as the developer are charging the user for this right.
An example of a game that utilises micro-transactions is the tower defence game ‘Bloons Tower Defence 4’. The game is an addictive tower defence game made by NinjaKiwi that has been released in many forms on many websites and other operating systems and it utilises micro-transactions very well by offering the player the ability to unlock new turrets and upgrades ahead of when they should be able to for a fee.
These forms of transactions are a great source of income as it gives the user a choice – they aren’t forced to pay for anything for they would otherwise be unable to get but can choose to if they so wish. While the number of people who will use this feature may vary, because the amount that you can charge for this content is set by you a lot of money can be made from just a few users – if you have 100000 users and only 1000 choose to pay for boosts, at £1 a time that’s still £1000 from these transactions alone.
Micro-transactions can also be as much of a deterrent and make you lose money as much as they can help you though. Some users may feel that because a person can pay to get an advantage over others it makes the game unbalanced and as a result stop playing the game.
In conclusion there are many different ways in which Flash games can be monetised, the only constant is that before you can make any money you have to make a Flash game and upload it to a website of some kind – from there you can undertake any of the paths detailed in this report to profit as much as possible.
If I was going to monetise the Flash game that I made last year, Matt Defence (a tower defence game), I personally would most likely take the route of adding in micro-transactions – much like Bloons Tower Defence does. I would make it so that you could pay money to unlock new turrets and upgrades ahead of when you would normally be able to – this would benefit those who just wish to play the game as they wish and also allow players who want to progress normally to do so. This route should work efficiently as nothing is forcing players to pay for these features and its nothing they would otherwise be unable to get if they don’t pay.
Overall, there is no ‘optimum route’ to take when monetising Flash games as all of the possible routes have their own set of benefits and drawbacks – sometimes focusing on one method of monetising flash games works better but sometimes trying to get a mix of all of them works better. For example, as reported in an article on GamaSutra, the Flash game ‘Dino Run’ by PixelJam Games utilises micro-transactions and advertising, and made a licensing deal that has profited them $4000, $11,500 and $22,000 respectively. This proves that as long as you are prepared to make a Flash game to a high quality and invest the time and effort in getting your game into the public eye then your game has a great chance of being a success and you can indeed make money from them.
References
- Flash Game License, 2011, About Flash Game License, [online] Available at <http://www.flashgamelicense.com/view_library.php?page=about> [Accessed October 2011]
- Hyman, P., 2009, Where’s [online] Available at <http://www.gamasutra.com/view/feature/3924/wheres_the_cash_for_flash.php?page=2> [Accessed October 2011]
- Lost Garden, 2009, Flash Love Letter (Part 2), [online] Available at <http://www.lostgarden.com/2009/07/flash-love-letter-2009-part-1.html> [Accessed October 2011]
- Moore, A., 2010, Steambirds: By the Numbers [online] Available at <http://www.andymoore.ca/steambirds-by-the-numbers/> [Accessed October 2011]
- NinjaKiwi, 2011, Bloons Tower Defence 4, [online] Available at <http://ninjakiwi.com/Games/Tower-Defense/Play/Bloons-Tower-Defense-4.html> [Accessed October 2011]
Word Count: 1999
-----------------------------------------------------------------------------------------
So, anyways, 'til next time - that's all folks!
So, anyways, 'til next time - that's all folks!
Thursday, 20 October 2011
Reading posts are going bi-weekly...
As the title suggests, this blog post is another one about readings that we have undertaken along the course, however, as it also suggests I am going to make these blog posts about readings for a combination of 2 reasons:-
--------------------------------------------------------------------------------------------
We actually read 4 articles but I'm only writing about 3; why is that you ask, well it's because if I'm perfectly frank I personally didn't get much from the 4th article (I got 1 note from it which was 'Keep it new and fresh') - this was mainly because it was a case study and as I said in my previous blog post I find it hard to extract relevent general information from specific case studies.
But anyways, onto the 3 articles in question. The first 2 come from Trefry as the Matching and Play ones did previously; this time the chapters that I read about were about sorting games and seeking games and were generally rather interesting to read and provided me with food information on these game types. The final one came from Craig Brannon in the Fall 2009 issue of Casual Connect magazine and his article entitled 'Come Out, Come Out, Wherever You Are' - this was also related to seeking games and as a result I will discuss this articles alongside Trefry's seeking chapter.
So without further ado let us start with Trefry's chapter on sorting games
-------------------------------------------------------------------------------------------
Sorting
Trefry stated that sorting is a fun pass time for us because of the fact that we naturally sort things in our life as it is; we put socks together, we match the same types of clothes together, we even put people together. This makes sense then to turn this natural mechanic into a game, if we have a natural desire to sort as it is then there is nothing the game needs to really teach us - it is all primal instinct and it is this primal instinct that gives us the thrill of success when everything is finally sorted.
Sorting is ultimately linked to matching - where matching just has us place the same things together regardless of the outcome and purpose of it, sorting makes us put these things together and then sort them into orders, colour, size, weight or any other category - it adds logic and purpose to simply parting the same things together. It is because of this that I prefer sorting to matching as it is ultimately more complicated then matching without being complicated at all - this in turn allows you to add more depth to your games without alienating potentail players with over-complicated details, rulings and mechanics.
In light of over-complicating games, Trefry goes on to gives examples of the sorting games Solitaire and Spider Solitaire and how they are computer game phenomenons - and part of this is because they are on computers. Some games work better when they are not done electronically such as seeing the dice roll, the dealing of cards but for games like solitaire computers eliminate the tedious process of setting the game up and as a result casual players can open the game and play to their hearts content with little worry. Also in terms of over-complicating, Trefry noted how Solitaire and Spider Solitaire are ultimately the same game just one is more complex then the other (as there is more to sort in one), yet we still see them as different - no one version is better or worse than the other; it all depends on the level of challenge you are prepared to give yourself.
He goes on to use 2 other case studies however I didn't get much out of these other than the fact that every rule in a game matters; they can make or break the game and should only be used to help the game flow along and not used unnecessarily. Also, he talked about the aspect of randomness and how it makes games more interesting and allows games to not just be puzzles that you solve once and are then done with, and yet also how they can often lead to players losing a game they would not otherwise lose from their own skill at sorting - for this reason randomness is a double-edged sword.
In summary, sorting is advanced matching and Trefry sums up well how they work and how best to make them - naturally and with simplicity.
-------------------------------------------------------------------------------------------
Seeking
Seeking games annoy me. I understand the attraction of them as seeking is natural - Trefry even states it and uses the example of treasure hunting or looking for Easter eggs to back it up - but seeking games just... don't seem to work... in my opinion. Trefry elaborates on this point by saying that, while successful, seeking games have almost no replayability as once you have played them and found all the items or whatever you are supposed to find in the game, you know where everything is and you no longer have the thrill of finding something again for the first time. He also stated that this is where the fun in seeking games comes from, the build up of tension as you hunt for objects and can't find them and the sweet release and satisfaction you get when you finally do find them.
Trefry didn't talk as much about seeking games as he did previous game types, possibly because like me he feels that the games work but don't hold much lasting appeal and are tricky to get right. One key aspect he did draw upon for making seeking games is how he feels it is better to make seeking games where the objects you are seeking serve some narrative purpose or some purpose in gameplay rather than just seeking items for the sake of it. Seeking games are generally very artsy, with many layers of items beautifully layered on top of each other to make them difficult to find, but that's not to say the items can't relate to each other and have a purpose - Trefry uses the example of in 'Mystery Case Files' how it is illogical that an Axe is amongst general household items.
Craig Brannon's article further elaborates seeking games and how they are very artsy games, stating how hiding objects in shadows and lighting key areas as clues can help make the game more interesting and add another side to how they work. He added that seeking games need to make sure they don't 'trick' players or be unfair with item placement; your game should make players go 'Why didn't I see that before?' rather than going 'How was I supposed to notice that!?'
Linked in with Trefry, he also added how seeking games need more than just seeking to be successful nowadays - you need multiple game modes, hint features, plots, etc - this ties in with Trefey's thoughts on how he believes seeking games need to be logical and have purpose.
In summary, seeking games work but are generally flawed if they are not developed right - they are simple and easy to understand, very artsy, not overly complex in gameplay but need something more than the core mechanic to make them stick.
---------------------------------------------------------------------------------
So there we have, another 2 weeks of reading done - hopefully I've been academic here and showed that I am taking things in from these readings and analysing them correctly.
So anyways, until next time - that's all folks!
- If I leave it for every 2 weeks it means I have more to write about in one go and therfore can hopefully churn out a lengthy blog post full of thoughts and insight.
- At the end of the day, I am not marked on my blog for this year and have plenty of other work to be getting on with in the meantime - my blog is hardly a priority in light of this.
--------------------------------------------------------------------------------------------
We actually read 4 articles but I'm only writing about 3; why is that you ask, well it's because if I'm perfectly frank I personally didn't get much from the 4th article (I got 1 note from it which was 'Keep it new and fresh') - this was mainly because it was a case study and as I said in my previous blog post I find it hard to extract relevent general information from specific case studies.
But anyways, onto the 3 articles in question. The first 2 come from Trefry as the Matching and Play ones did previously; this time the chapters that I read about were about sorting games and seeking games and were generally rather interesting to read and provided me with food information on these game types. The final one came from Craig Brannon in the Fall 2009 issue of Casual Connect magazine and his article entitled 'Come Out, Come Out, Wherever You Are' - this was also related to seeking games and as a result I will discuss this articles alongside Trefry's seeking chapter.
So without further ado let us start with Trefry's chapter on sorting games
-------------------------------------------------------------------------------------------
Sorting
Trefry stated that sorting is a fun pass time for us because of the fact that we naturally sort things in our life as it is; we put socks together, we match the same types of clothes together, we even put people together. This makes sense then to turn this natural mechanic into a game, if we have a natural desire to sort as it is then there is nothing the game needs to really teach us - it is all primal instinct and it is this primal instinct that gives us the thrill of success when everything is finally sorted.
Sorting is ultimately linked to matching - where matching just has us place the same things together regardless of the outcome and purpose of it, sorting makes us put these things together and then sort them into orders, colour, size, weight or any other category - it adds logic and purpose to simply parting the same things together. It is because of this that I prefer sorting to matching as it is ultimately more complicated then matching without being complicated at all - this in turn allows you to add more depth to your games without alienating potentail players with over-complicated details, rulings and mechanics.
In light of over-complicating games, Trefry goes on to gives examples of the sorting games Solitaire and Spider Solitaire and how they are computer game phenomenons - and part of this is because they are on computers. Some games work better when they are not done electronically such as seeing the dice roll, the dealing of cards but for games like solitaire computers eliminate the tedious process of setting the game up and as a result casual players can open the game and play to their hearts content with little worry. Also in terms of over-complicating, Trefry noted how Solitaire and Spider Solitaire are ultimately the same game just one is more complex then the other (as there is more to sort in one), yet we still see them as different - no one version is better or worse than the other; it all depends on the level of challenge you are prepared to give yourself.
He goes on to use 2 other case studies however I didn't get much out of these other than the fact that every rule in a game matters; they can make or break the game and should only be used to help the game flow along and not used unnecessarily. Also, he talked about the aspect of randomness and how it makes games more interesting and allows games to not just be puzzles that you solve once and are then done with, and yet also how they can often lead to players losing a game they would not otherwise lose from their own skill at sorting - for this reason randomness is a double-edged sword.
In summary, sorting is advanced matching and Trefry sums up well how they work and how best to make them - naturally and with simplicity.
-------------------------------------------------------------------------------------------
Seeking
Seeking games annoy me. I understand the attraction of them as seeking is natural - Trefry even states it and uses the example of treasure hunting or looking for Easter eggs to back it up - but seeking games just... don't seem to work... in my opinion. Trefry elaborates on this point by saying that, while successful, seeking games have almost no replayability as once you have played them and found all the items or whatever you are supposed to find in the game, you know where everything is and you no longer have the thrill of finding something again for the first time. He also stated that this is where the fun in seeking games comes from, the build up of tension as you hunt for objects and can't find them and the sweet release and satisfaction you get when you finally do find them.
Trefry didn't talk as much about seeking games as he did previous game types, possibly because like me he feels that the games work but don't hold much lasting appeal and are tricky to get right. One key aspect he did draw upon for making seeking games is how he feels it is better to make seeking games where the objects you are seeking serve some narrative purpose or some purpose in gameplay rather than just seeking items for the sake of it. Seeking games are generally very artsy, with many layers of items beautifully layered on top of each other to make them difficult to find, but that's not to say the items can't relate to each other and have a purpose - Trefry uses the example of in 'Mystery Case Files' how it is illogical that an Axe is amongst general household items.
Craig Brannon's article further elaborates seeking games and how they are very artsy games, stating how hiding objects in shadows and lighting key areas as clues can help make the game more interesting and add another side to how they work. He added that seeking games need to make sure they don't 'trick' players or be unfair with item placement; your game should make players go 'Why didn't I see that before?' rather than going 'How was I supposed to notice that!?'
Linked in with Trefry, he also added how seeking games need more than just seeking to be successful nowadays - you need multiple game modes, hint features, plots, etc - this ties in with Trefey's thoughts on how he believes seeking games need to be logical and have purpose.
In summary, seeking games work but are generally flawed if they are not developed right - they are simple and easy to understand, very artsy, not overly complex in gameplay but need something more than the core mechanic to make them stick.
---------------------------------------------------------------------------------
So there we have, another 2 weeks of reading done - hopefully I've been academic here and showed that I am taking things in from these readings and analysing them correctly.
So anyways, until next time - that's all folks!
Saturday, 8 October 2011
Return to weekly readings
So here we go, let's get on with it straight way and just jump into it - this blog is going to be talking about the readings we have undertaken at Uni for the first 2 weeks back (weeks 2 and 3 to be specific as week 1 was introductory). This time a lot of the readings come from the book 'Casual Games Design: Designing Play for the Gamer in all of us' by Gregory Trefry... in fact in the past 2 weeks we have had to do 5 readings, 3 of which come from Trefry and the other 2 come from Eric Zimmermann and John Rose respectively.
The readings discuss the following:-
-------------------------------------------------------------------------------
Reading No.1 - Level and Iterative Design
Basically, to start this off bluntly, I didn't get much from the Zimmermann article... okay that sounds bad, what I mean is I got nothing much new that I didn't already know. Zimmermann talked about iterative design, how it worked and how it is useful which good for a recap but ultimately I know about iterative design from last year - the process of adding and changing your rules and games in small doses through iterations; if the new rule doesn't work then you can take it out before trialing a new rule and then add more and so on. That's all I have to say on Zimmermann, much of the same, good for a recap and good for relating it to examples that he personally has experienced.
Trefry's section on iteration was ultimately the same as well to be honest, just nailing down what iteration is and how it helps. The level design half was more interesting and was more new to me than the iteration stuff, but in some ways when I was reading it to me it felt like he was stating the obvious... I don't know how to describe it... I guess it's just when I was reading it I was going 'Well I know that, that's obvious', so I guess it didn't teach me anything new but at least brought the ideas of level design to the front of my mind which is never a bad thing. The main ideas he talked about in level design we ideas that you need to make sure your level is easy enough to play yet challenging too, easing players into the game, not chucking them in the deep end and giving them space to learn and feel the game. This then led to playtesting and ultimately iteration.
So overall, in my opinion, nothing much learned from this reading but at least good for making you think of these things and making them more prominent in your head.
-------------------------------------------------------------------------------
Reading No.2 - Mechanics
I thought I'd do this first to get the non-Trefry articles out of the way. The mechanics article comes from Gamasutra and is titled 'Fewer Mechanics, Better Game' and, as stated above was written by John Rose. As the titles suggests the articles talked about the idea of having less mechanics and/or simpler mechanics in games to ultimately make them better.
The article talked about how games are systems waiting to be understood by the player with the fun being the mastery of these systems and mechanics are ultimately what guide a system and allow a player to do so - as a result of this, it comes to reason that the more mechanics there are the harder a game system is to master and the harder it is to get fun out of the game. The article went on to explain about not including what doesn't belong, using examples prominently, and basically saying if something isn't needed, doesn't feel right, doesn't fit, etc, then it isn't needed and shouldn't be included - boiling the game down to it's core mechanics or 'trimming the fat' as the article put it.
To be fair, a lot of the article was just a long argument leading to the ultimate conclusion that games work better when they use only what is needed and making THESE aspects better improves the game rather than adding stuff for the sake of it. I agree with this for the most part, sometimes having more than the core mechanic isn't needed but can add another side to a game - but this is just personal opinion.
-------------------------------------------------------------------------------
Reading No.3 - Play
So... the 3rd reading was the entirety of Chapter 3 of Trefry's book. To me this chapter was another recap one, it talked about the underlying philosophy of what makes a game a game and what aspects of them lead to fun. This chapter also linked to mechanics somewhat but not fully which is why I kept this reading separate - as it was finding the core aspect of play this linked to the core mechanics of games and keeping them simplistic for the sake of more fun, etc.
Basically, the chapter started by identifying that there are many playful activities that we do in everyday life that we do for fun but don't consider them play or games because, well, they aren't... but it boils down to play sparks fun and games designers take this and structure the play into a game. The rest of the chapter then goes on to talk about the many forms of play that there are and the unlimited number of game possibilities there are from taking these everyday, playful activities and turning them into games simply by structuring them with goals and purpose.
It is for this reason that the chapter felt more like a recap than anything new, as we had looked several times at defining what games are last year. However, as stated earlier, this is not a bad thing as its always good to make yourself think about these things and bring them to the front of your mind.
-------------------------------------------------------------------------------
Reading No. 4 - Matching
Finally, the next reading was the entirety of Chapter 4 of Trefry's book about matching games. All of this was new to me as this year we are looking at individual, specific mechanics (for the most part) than games in general. However, I found this reading informative but not in such a way that I could take notes on or put down in words... the reason for this is that it is too example based; it looks closely at matching in existing games and why they work FOR THOSE GAMES and not enough in general. In the chapter he uses the examples of Bejeweled, a LEGO game and Snood.
Trefry talks about these games, what makes them work and appealing to players, linking it to the simplicity of their mechanics and then saying how if you tried adding or changing aspects of the games then they wouldn't work - but again, these were all specific to the games he was taking about, which makes it hard to take away general points that work for the matching mechanic in general; they work for the matching mechanic IN THE GAME. In summary though, you can draw out of this reading that, as a mechanic, Matching offers clear goals and feedback to the player and as a result it is a good base on which to build around.
-------------------------------------------------------------------------------
So there we have it, the first readings of my 2nd year. I know it sounds like a lot of moaning but it isn't... really, I'm serious, it's always good to recap and some of it was new. The readings we do are always good and worth a look even if it's stuff that you think 'That's obvious' about it - the only readings I don't like are ones where they link what they are talking to into examples but then don't talk about it in general/linger on the example for pages and pages.
I don't learn like that, examples are good for making a point so you can relate what you're talking to with an existing game that the reader can understand and see, but you only need to do it for a paragraph, after that you go too in-depth with it and everything becomes related only to that game, making it hard to extract the general information you can apply to any situation.
So anyways, until next time - that's all folks!
The readings discuss the following:-
- Trefry No.1: Level design and Iterative design
- Trefry No.2: What is 'Play'
- Trefry No.3: Matching Games
- Zimmermann: Iterative Design
- Rose: Simple Mechanics
-------------------------------------------------------------------------------
Reading No.1 - Level and Iterative Design
Basically, to start this off bluntly, I didn't get much from the Zimmermann article... okay that sounds bad, what I mean is I got nothing much new that I didn't already know. Zimmermann talked about iterative design, how it worked and how it is useful which good for a recap but ultimately I know about iterative design from last year - the process of adding and changing your rules and games in small doses through iterations; if the new rule doesn't work then you can take it out before trialing a new rule and then add more and so on. That's all I have to say on Zimmermann, much of the same, good for a recap and good for relating it to examples that he personally has experienced.
Trefry's section on iteration was ultimately the same as well to be honest, just nailing down what iteration is and how it helps. The level design half was more interesting and was more new to me than the iteration stuff, but in some ways when I was reading it to me it felt like he was stating the obvious... I don't know how to describe it... I guess it's just when I was reading it I was going 'Well I know that, that's obvious', so I guess it didn't teach me anything new but at least brought the ideas of level design to the front of my mind which is never a bad thing. The main ideas he talked about in level design we ideas that you need to make sure your level is easy enough to play yet challenging too, easing players into the game, not chucking them in the deep end and giving them space to learn and feel the game. This then led to playtesting and ultimately iteration.
So overall, in my opinion, nothing much learned from this reading but at least good for making you think of these things and making them more prominent in your head.
-------------------------------------------------------------------------------
Reading No.2 - Mechanics
I thought I'd do this first to get the non-Trefry articles out of the way. The mechanics article comes from Gamasutra and is titled 'Fewer Mechanics, Better Game' and, as stated above was written by John Rose. As the titles suggests the articles talked about the idea of having less mechanics and/or simpler mechanics in games to ultimately make them better.
The article talked about how games are systems waiting to be understood by the player with the fun being the mastery of these systems and mechanics are ultimately what guide a system and allow a player to do so - as a result of this, it comes to reason that the more mechanics there are the harder a game system is to master and the harder it is to get fun out of the game. The article went on to explain about not including what doesn't belong, using examples prominently, and basically saying if something isn't needed, doesn't feel right, doesn't fit, etc, then it isn't needed and shouldn't be included - boiling the game down to it's core mechanics or 'trimming the fat' as the article put it.
To be fair, a lot of the article was just a long argument leading to the ultimate conclusion that games work better when they use only what is needed and making THESE aspects better improves the game rather than adding stuff for the sake of it. I agree with this for the most part, sometimes having more than the core mechanic isn't needed but can add another side to a game - but this is just personal opinion.
-------------------------------------------------------------------------------
Reading No.3 - Play
So... the 3rd reading was the entirety of Chapter 3 of Trefry's book. To me this chapter was another recap one, it talked about the underlying philosophy of what makes a game a game and what aspects of them lead to fun. This chapter also linked to mechanics somewhat but not fully which is why I kept this reading separate - as it was finding the core aspect of play this linked to the core mechanics of games and keeping them simplistic for the sake of more fun, etc.
Basically, the chapter started by identifying that there are many playful activities that we do in everyday life that we do for fun but don't consider them play or games because, well, they aren't... but it boils down to play sparks fun and games designers take this and structure the play into a game. The rest of the chapter then goes on to talk about the many forms of play that there are and the unlimited number of game possibilities there are from taking these everyday, playful activities and turning them into games simply by structuring them with goals and purpose.
It is for this reason that the chapter felt more like a recap than anything new, as we had looked several times at defining what games are last year. However, as stated earlier, this is not a bad thing as its always good to make yourself think about these things and bring them to the front of your mind.
-------------------------------------------------------------------------------
Reading No. 4 - Matching
Finally, the next reading was the entirety of Chapter 4 of Trefry's book about matching games. All of this was new to me as this year we are looking at individual, specific mechanics (for the most part) than games in general. However, I found this reading informative but not in such a way that I could take notes on or put down in words... the reason for this is that it is too example based; it looks closely at matching in existing games and why they work FOR THOSE GAMES and not enough in general. In the chapter he uses the examples of Bejeweled, a LEGO game and Snood.
Trefry talks about these games, what makes them work and appealing to players, linking it to the simplicity of their mechanics and then saying how if you tried adding or changing aspects of the games then they wouldn't work - but again, these were all specific to the games he was taking about, which makes it hard to take away general points that work for the matching mechanic in general; they work for the matching mechanic IN THE GAME. In summary though, you can draw out of this reading that, as a mechanic, Matching offers clear goals and feedback to the player and as a result it is a good base on which to build around.
-------------------------------------------------------------------------------
So there we have it, the first readings of my 2nd year. I know it sounds like a lot of moaning but it isn't... really, I'm serious, it's always good to recap and some of it was new. The readings we do are always good and worth a look even if it's stuff that you think 'That's obvious' about it - the only readings I don't like are ones where they link what they are talking to into examples but then don't talk about it in general/linger on the example for pages and pages.
I don't learn like that, examples are good for making a point so you can relate what you're talking to with an existing game that the reader can understand and see, but you only need to do it for a paragraph, after that you go too in-depth with it and everything becomes related only to that game, making it hard to extract the general information you can apply to any situation.
So anyways, until next time - that's all folks!
Saturday, 1 October 2011
The 2nd year begins...
So here we are, at the end of the first week of being back at Uni... you soon learn that nothing has changed since you left, straight away you're back into the swing of things and know that you have to crack on and get everything done. The only differences between this year and last year are that you have an idea of how much you will need to work, and the fact that everyone knows each other this time round so it makes it easier to just get in and get on with work as opposed to trying to get to know everyone and then work.
So what is this blog post is for, well basically just me talking about how I feel about all my modules and assignments that I have been set thus far and how I think they will go, etc. So without further ado, let us begin!
-----------------------------------------------------------------------------------------
Modding
At first I was slightly apprehensive about modding as it is a module that we didn't do anything on last year. Our modding is basically designing and putting together our own level in UDK... doesn't sound to difficult but it is as we have to really focus on getting the map layout working to a high standard, do all the 3D models and textures, fill it all with research, etc, so it is actually a very thorough and in-depth module.
For modding we put ourselves into self-chosen 3 person groups, my group consists of Matthew Jarvis, Tom Weaver and myself which is good for 3 reasons, 1) We're all good friends which will make getting on with the work fun, 2) We live in the same flat so its easy for us to sort out aspects of the mod together whenever we so wish and 3) Our skills at 3D modelling are all equally moderate, so we can evenly divide the work-load and know that no one persons models will look out of place with anothers.
For our mod we have chosen the theme of Ancient Egypt (we had a choice of 4; Medieval, Space and Industrial being the others), however, to put our own spin on it, we are having it set in modern times. To do this we are having our map layed out as if it is an archeological dig site that has discovered an Ancient Egyptian tomb - this fits the theme but also allows us to experiment with our models and textures compared to the norm.
Overall, modding looks promising thus far and we should hopefully do well in this module. -----------------------------------------------------------------------------------------
Practical Prototyping
I knew what practical prototyping was going to be before we started it - a mixture between Critical Games Studies from last year and a new area of making board games (which we did briefly touch upon last year to be fair), it gets us focusing in on what makes the games we make fun, right down to the core of theory.
In this module we work alone to make 2 board games across the course of the 2 12-week semesters that we have, the first is to focus on one core mechanic of play that we will be studying over the early weeks of the semester and the second is to focus on a particular theme that, again, we will work on over the early weeks of the second semester.
So far we haven't actually only started any work for this module apart from having to take note from a reading which I will do later on today or tomorrow. Overall, this module seems like it could be both interesting and very challenging so I will have to see how it develops over the year.
-----------------------------------------------------------------------------------------
Scripting
Scripting is an extension of the introduction to scripting module from last year, namely, involving making games and coding them in flash. This year, however, we are also going to learn how to do basic coding in Unity, a 3D modelling code program which should be interesting - this isn't until the second semester though.
For the first part of this module, which is the flash part, we have to work in self chosen pairs to make 3 flash prototype games (each based on a randomly chosen theme) over a period of 4 weeks each (totaling the first semester). There is also an essay that we have to do which is in for just about 3 weeks time... that's kind of chucking us in at the deep-end but I guess it works to get us going again and gets it out of the way.
For making the flash games I ended up going with Tom Weaver yet again, this is actually a sensible move though as the 'working in pairs' format effectively means 1 artist and 1 coder... and while I don't consider myself to be a coder the amount of coders in our class is lacking so, being one of the better 'average' coders I knew I would most likely end up doing this and therefore having Tom as my artist made sense as he is one of the best artists in our class. Also, like modding it means we can meet-up and sort the work out easily, etc.
Our theme for the first game is matching and so far we have done quite a good prototype actually... and quickly too which has suprised me... maybe I'm a better coder than I thought... anyways, if the rest of the module goes as smoothly as it is so far this module should be good.
-----------------------------------------------------------------------------------------
Group Project
The group project has changed considerably since last year. As we are 2nd years we are managing this year as opposed to last year when we were the development team, however, this year the development method we are using is different which actually involves the managers being much more involved with the making of the games itself which is both good and bad. It is good as it means there should be a constant stream of contact and communication between us and the 1st years but it is bad as it feels like we as 2nd years have got a much greater workload than the first years.
The development method we are using this time around is agile or scrum development which essentially, in laymans terms, means that we think of all the features or aspects of our game and put them in a lost (the product backlog), from this break them down into tasks (user stories) and then these tasks get prioritised and completed over 4 week sprints. This means that at the end of a sprint you have a working game - it might not be good, but it is a working game that you can test nonetheless.
My group, which were not chosen by us this time, is made up of Jack Stalley and myself as the 2nd year managers and Maria Barte and Leah Cheung as the 1st year developers. I'm happy with my team as 1) Jack and I get on well and so can work together easily and 2) Both are 1st years are good artists, so we are set on this front. This has left Jack and me doing the managing (as we have to), animation, sound and coding and, while I am not thrilled about being the coder in 2 separate modules when I'm not even supposed to be a coder, this means that we have a good spread of work.
For this module our theme is independence... how well exactly the idea that we have will go down I don't know, but as long as the game we make isn't to heavy on coding (for my own capabilities) and we have good story and artwork, etc, it should be good indeed.
-----------------------------------------------------------------------------------------
3D Modelling
Like with scripting 3D modelling is mostly an extension of what we started in the previous year which is good. This year, however, we are allowed to tie in work from 2 modules; namely we are allowed to make and model assets for our modding module in modeling. This is great, not just from a workload point of view but because it gives us an idea of how works would get passed around different departments.
The modelling is more intensive than last year, but mostly works in the same way, and because it is allowed to tie into modding we are marked on the quality of the model itself and the research gone into it rather than how it has been used to construct a level as we are in modding. Due to this, yet again, I am working with Tom and Matty but as this is effectively 2 modules links it doesn't matter and is beneficial if anything - we are still graded individually for our models and research though obviously.
-----------------------------------------------------------------------------------------
Anymation
finally, this module is the most fun but also the most scary as, like modding, it is completely new to us, but also because it is completely new to the Uni - it has been approved this year to begin just for us, we are the guinea-pigs as it were. This module as the name suggests involves making animation/s in a variety of ways - the 1st semester in more traditional animation software and art styles and the 2nd semester in Machinima... I am more looking forward to the traditional animation than the Machinima...
For the first semester we basically have as much freedom as we like, we have to make either 6 animation features (20 second long or so animations showing animation aspects such as walking, standing idly, etc) or make a short, full animation. This is good as it allows the module to be as fun as we want it to be and doesn't seem to taking... the only real problem is that having no prior animation experience I have no idea how easy or hard it will be.
So far, I have begun thinking of initial ideas and have got some good ones (I think)... I guess for this module I really have just got to wait and see how it turns out...
-----------------------------------------------------------------------------------------
So there you have it, that is what I am going to be doing for the year (or 1st Semester if I don't know exactly what the 2nd one entails)... I think it is going to be a mixture of fun, challenging and scary but that's to be expected - let's get to it and work hard!
So anyways, 'til next time - that's all folks!
So what is this blog post is for, well basically just me talking about how I feel about all my modules and assignments that I have been set thus far and how I think they will go, etc. So without further ado, let us begin!
-----------------------------------------------------------------------------------------
Modding
At first I was slightly apprehensive about modding as it is a module that we didn't do anything on last year. Our modding is basically designing and putting together our own level in UDK... doesn't sound to difficult but it is as we have to really focus on getting the map layout working to a high standard, do all the 3D models and textures, fill it all with research, etc, so it is actually a very thorough and in-depth module.
For modding we put ourselves into self-chosen 3 person groups, my group consists of Matthew Jarvis, Tom Weaver and myself which is good for 3 reasons, 1) We're all good friends which will make getting on with the work fun, 2) We live in the same flat so its easy for us to sort out aspects of the mod together whenever we so wish and 3) Our skills at 3D modelling are all equally moderate, so we can evenly divide the work-load and know that no one persons models will look out of place with anothers.
For our mod we have chosen the theme of Ancient Egypt (we had a choice of 4; Medieval, Space and Industrial being the others), however, to put our own spin on it, we are having it set in modern times. To do this we are having our map layed out as if it is an archeological dig site that has discovered an Ancient Egyptian tomb - this fits the theme but also allows us to experiment with our models and textures compared to the norm.
Overall, modding looks promising thus far and we should hopefully do well in this module. -----------------------------------------------------------------------------------------
Practical Prototyping
I knew what practical prototyping was going to be before we started it - a mixture between Critical Games Studies from last year and a new area of making board games (which we did briefly touch upon last year to be fair), it gets us focusing in on what makes the games we make fun, right down to the core of theory.
In this module we work alone to make 2 board games across the course of the 2 12-week semesters that we have, the first is to focus on one core mechanic of play that we will be studying over the early weeks of the semester and the second is to focus on a particular theme that, again, we will work on over the early weeks of the second semester.
So far we haven't actually only started any work for this module apart from having to take note from a reading which I will do later on today or tomorrow. Overall, this module seems like it could be both interesting and very challenging so I will have to see how it develops over the year.
-----------------------------------------------------------------------------------------
Scripting
Scripting is an extension of the introduction to scripting module from last year, namely, involving making games and coding them in flash. This year, however, we are also going to learn how to do basic coding in Unity, a 3D modelling code program which should be interesting - this isn't until the second semester though.
For the first part of this module, which is the flash part, we have to work in self chosen pairs to make 3 flash prototype games (each based on a randomly chosen theme) over a period of 4 weeks each (totaling the first semester). There is also an essay that we have to do which is in for just about 3 weeks time... that's kind of chucking us in at the deep-end but I guess it works to get us going again and gets it out of the way.
For making the flash games I ended up going with Tom Weaver yet again, this is actually a sensible move though as the 'working in pairs' format effectively means 1 artist and 1 coder... and while I don't consider myself to be a coder the amount of coders in our class is lacking so, being one of the better 'average' coders I knew I would most likely end up doing this and therefore having Tom as my artist made sense as he is one of the best artists in our class. Also, like modding it means we can meet-up and sort the work out easily, etc.
Our theme for the first game is matching and so far we have done quite a good prototype actually... and quickly too which has suprised me... maybe I'm a better coder than I thought... anyways, if the rest of the module goes as smoothly as it is so far this module should be good.
-----------------------------------------------------------------------------------------
Group Project
The group project has changed considerably since last year. As we are 2nd years we are managing this year as opposed to last year when we were the development team, however, this year the development method we are using is different which actually involves the managers being much more involved with the making of the games itself which is both good and bad. It is good as it means there should be a constant stream of contact and communication between us and the 1st years but it is bad as it feels like we as 2nd years have got a much greater workload than the first years.
The development method we are using this time around is agile or scrum development which essentially, in laymans terms, means that we think of all the features or aspects of our game and put them in a lost (the product backlog), from this break them down into tasks (user stories) and then these tasks get prioritised and completed over 4 week sprints. This means that at the end of a sprint you have a working game - it might not be good, but it is a working game that you can test nonetheless.
My group, which were not chosen by us this time, is made up of Jack Stalley and myself as the 2nd year managers and Maria Barte and Leah Cheung as the 1st year developers. I'm happy with my team as 1) Jack and I get on well and so can work together easily and 2) Both are 1st years are good artists, so we are set on this front. This has left Jack and me doing the managing (as we have to), animation, sound and coding and, while I am not thrilled about being the coder in 2 separate modules when I'm not even supposed to be a coder, this means that we have a good spread of work.
For this module our theme is independence... how well exactly the idea that we have will go down I don't know, but as long as the game we make isn't to heavy on coding (for my own capabilities) and we have good story and artwork, etc, it should be good indeed.
-----------------------------------------------------------------------------------------
3D Modelling
Like with scripting 3D modelling is mostly an extension of what we started in the previous year which is good. This year, however, we are allowed to tie in work from 2 modules; namely we are allowed to make and model assets for our modding module in modeling. This is great, not just from a workload point of view but because it gives us an idea of how works would get passed around different departments.
The modelling is more intensive than last year, but mostly works in the same way, and because it is allowed to tie into modding we are marked on the quality of the model itself and the research gone into it rather than how it has been used to construct a level as we are in modding. Due to this, yet again, I am working with Tom and Matty but as this is effectively 2 modules links it doesn't matter and is beneficial if anything - we are still graded individually for our models and research though obviously.
-----------------------------------------------------------------------------------------
Anymation
finally, this module is the most fun but also the most scary as, like modding, it is completely new to us, but also because it is completely new to the Uni - it has been approved this year to begin just for us, we are the guinea-pigs as it were. This module as the name suggests involves making animation/s in a variety of ways - the 1st semester in more traditional animation software and art styles and the 2nd semester in Machinima... I am more looking forward to the traditional animation than the Machinima...
For the first semester we basically have as much freedom as we like, we have to make either 6 animation features (20 second long or so animations showing animation aspects such as walking, standing idly, etc) or make a short, full animation. This is good as it allows the module to be as fun as we want it to be and doesn't seem to taking... the only real problem is that having no prior animation experience I have no idea how easy or hard it will be.
So far, I have begun thinking of initial ideas and have got some good ones (I think)... I guess for this module I really have just got to wait and see how it turns out...
-----------------------------------------------------------------------------------------
So there you have it, that is what I am going to be doing for the year (or 1st Semester if I don't know exactly what the 2nd one entails)... I think it is going to be a mixture of fun, challenging and scary but that's to be expected - let's get to it and work hard!
So anyways, 'til next time - that's all folks!
Subscribe to:
Posts (Atom)