Job's found on Gamasautra:
Games Design:
All Levels:
Shiver Entertainment have an advertisement on Gamasutra for a game designer. The requirements for this position are, minimum of one professional title, to be motivated and passionate about a broad range of genres and platforms. This advertismen also details they will hire artists and game play programmers. This new start up company will produce freemium games for Windows, Android and iOS. This company is focused on immersive gaming experiences for the plat forms listed above. The idea is for the designers to bring AAA experiences to mobile and tablet devices. The CEO is John Schappert, the former COO if EA and Synga and former head of Microsoft.
http://jobs.gamasutra.com/job/game-designers-all-levels-miami-florida-25277
Since I will be creating my game in Unity, my project could be transferred to a mobile platform and the controls would have to be simple enough for players to use on a tablet device. The job type for this is 'Game Design' and the studio is located in Miami, Florida.
The experience level for this application is N/A and the educational requirement for it is a basic high school certificate.
Senior:
Interactive Selection
Location: Midlands, UK
Involves: Working on AAA title, taking on responsability for for large sections of game design, leading junior team members. Reporting to lead designer, one will ensuring quality of design in allocated area. Must be working with and developing design staff and will act as a champion of quality across game team. Must be flexible, approachable and motivated.
Requirements: At least 5 years industry experience. Experience working as a senior designer on at least one published title current generation console (PS3). Consistent high quality of work, excellent communication skills, can write in a stylish and persuasive manner, excellent working knowledge and passion for racing games.
http://www.gamesindustry.biz/jobs/interactive-selection/midlands/england/uk-and-europe/senior-games-designer-games-innovator-id62140
Programming:
Junior:
Hay Specialist Recruitment
Experience: Mobile games.
Education Bachelor's Degree
This role is mainly about coding the front-end client for games, yet you need to be involved with every stage of game development from beginning to the end.
Essential: Computer Science Degree with games technology module.
Desired: Enthusiasm (plus one or more of the following), experience with Unity, Unity3D, C#, SQL, JAVA, FLASH.
http://jobview.monster.co.uk/Junior-Games-Developer-Job-London-London-UK-126117353.aspx?from=indeed
Senior:
Linden Lab
Software Engineer, Unity
Education: Bachelor's Degree Location: San Francisco
The job involves working on new and exiting game projects. One's has to deal with versatility and change
and as an engineer one will end up learning new skills. The task involves working on live code bases.
What's involved:
Building new systems and improve existing ones. Collcaborate with other engineers on live products in using agile development. Extending and optimizing large scale game systems, such as physics and game play mechanic. Aid mentor and help juniors, and work closely with other department such as artists and designers.
Required skills:
5+ years of software engineering.
High proficiency in C# or C++
Sharp focus on prioritization on user-experience and know where and when trade offs need to be made.
Collaborative and fast to adapt in a multi-tasking, fast paced distributed thinking environment.
Strong 3D maths skills
Bonus Skills:
Previous Experience with Unity
Previous game industry experience
Experience with physics systems development
Lead:
Rumble Entertainment Inc.
Experience: Mid-Senior
Direct a team of programmers for an online AAA game with a large scale deployment. The department also works with other disciplines of games design.
Desired Skills: Fluent in C#, C++ or Java, experience with other languages is a plus. BSc in Computer Science or equivalent experience.
Effective in directing and delivering production soft-ware for high quality games.
10+ years development experience with one shipped game product as a technical lead.
Direct experience with client/server typologies used in online games.
Bonus: iOS or Android experience, Unity 3D game engine experience, Experience with online game services.
Saturday, 26 October 2013
Thursday, 24 October 2013
Balancing an in-game economy
In this Gamasutra article, Soren Johnson discusses how to balance in-game economies using forms of inflation.
However in some games if the economy is not pruned and tested thoroughly, things can become chaotic very quickly and backfire. E.g. when Ultilma Online started, it was famous for how quickly the economy spiralled out of control. Zachary Simpson analysed UO in 1999, showing a number of the more notable errors experienced at launched.
- Players used vendors as infinite safety deposit boxes by setting the prices of their own resources vastly above the market value.
- Resource hoarding forced teams to leave the closed-loop economy as the game world started to run out of goods.
- Cartels (including one from a rival game company) monopolised the market on magical Reagents, stopping average players form casting spells.
- The item crafting system encourage vast over-production via rewarding players for each item produced.
- Due to over production, this led to hyper-inflation as NPC-shopkeepers printed more currency on demand to purchase the worthless items.
Fortunately since then, MMO (and offline games) have come far since them. EVE: Online hired an economist graduate for balance out the economy by analysing the flow of game resources and the fluctuation of in game prices.
Can markets balance the game?
Many games designers have used economic game structures as a tool for balancing out their games. E.g. Rise of Nations, every time the player purchases a unit such as a Knight, the price of the future unit of the same item raises. This simulates pressure of demand based on the price. This design encourages the player to diversify their forces in game, this was to maximise their in game purchasing power.
Through allowing the variables of different paths and options to float around during a game, designers present players with a constantly evolving landscape, this extends the re playability through guaranteeing no dominant strategy.
Although if this method is taken too far, auto-balancing by tweaking the economy can potentially destroy a game. Valve back in 2006 conducted an experiment with it's game Counter Strike: Source, by implementing a dynamic weapon pricing algorithm. The idea the developers has was "the prices of weapons and equipment will be updated each week based on the global market demand for each item. As more people purchase a certain weapon, the price for that weapon will raise and other weapons will become less expensive."
However, due to the overwhelming popularity of certain weapons this trumped the ability of the algorithms tp balance the game. E.g. very effective weapons sky rocketed, whilst the less useful weapons flat lined, this led to some extreme cases. If this persists, by the price climbing higher and higher, this can become prohibitive for many players and they may not only just change their strategy. If they are not having fun they can just change to a different game unlike a real world economy.
Due to this, playing with a games economy is a slippery slope. If the cost of a player's favourite weapon has been raised it may feel like a penalty and should only be done if the imbalance is actually destroying the game play.
Putting the Economy Inside the Game
In some cases a better use of economic dynamics is as a transparent mechanic inside a game itself. Plenty of board games provide examples of certain free markets. The game Puerto Rico increases subsidies to improve the appeal of unpopular technologies and roles. In the case of the first one, every turn no one decides to be a Craftsman, a single gold piece is added as a "reward" for choosing the role. When the gold increases gradually, a few players will can resist such a bounty, that nicely solves the problem of making sure roles are chosen.
In Puerto Rico, the game has clearly better or worse options, they merely change from turn to turn. In this instance auto-balancing actually works, and keeps the game fun because players are rewarded for choosing less common strategies, instead of penalising players for sticking with their favourite strategies. Also the effects of the market are transparent before the game, so it doesn't feel like the game is against the players'.
the game power grid is a great example of a free market since it's based around actual resources. In this game, all resources are purchased from one central market to supply their power plants. The resources are placed along a linear track of escalating prices. Each turn, X new items are added to the market, and the players purchase Y pieces. As the supply fluctuates, does the price of each item.
By making the demand mechanic transparent to the players, the market becomes its own war zone. By purchasing as many resources as possible, a single player could drive the price out of range for most players in the next round, causing some players to not be able to power their plants that turn. Therefore, with a completely free open market, the price of items can be used as a weapon, just like a bullet with a gun.
Benefits of Having Free Trade
A number of strategy games, which include Age of Empires, have included free markets which players are able to purchase or sell products, influencing nationwide prices with their actions. These markets serve as "greed tests" in which players are frequently tempted to sell when they require cash or to purchase when they are short of a specific resource, however they realise in the back of their minds each time they use the market, they could be giving an advantage to another player.
However , the market dynamics of these games generally repeat themselves, since the prices usually bottoming out once the players' production overwhelms their needs. This effect stems from the fact the game maps emphasise economic fairness, each player is guaranteed a decent quantity of resources near their start location. Spreading resources randomly around the map may lead to a far more dynamic market mechanic, however this is at the cost of overall pay balance for a game with a core military mechanic.
However in some games like M.U.L.E. the player has to specialise in a certain resource, and gain economic dominance through this. due to this the players' rarely can produce all the resources they need on their own and have to purchase resources from other outlets and players.
The players are arranged at the bottom of the screen, and the sellers at the top. As buyers go up, so does their asking price. As their position moves down, so does their asking price, where the two are level, a transaction is made.All information is public for greater transparency. The mechanics are, the player either has to adjust their prices or cave in to the other players. Some times a player will have to spend money to produce resources to power their buildings or food and drink to feed the labour, the player may want to save every last penny. This this case, prices generally fall only if the a player is scared another player may sweep in and gain the benefits.
What Might be in my game?
Since my game revolves around an economy I may include in inflation mechanic since I find this aspect interesting and it could help my games economy. However, I require more research on the topic, and it depends if I have the time to do it in my project. If I do have the time to include this in my dissertation it will probably be involved when upgrading aspects of the game. For example health capacity, how powerful a certain ability is.
Tuesday, 22 October 2013
Emergence and Progression (how I can use these with managing mechanics)
History of Emergence and Progression
Games of emergence are those of fairly simplistic rules but much variation. The term if used because the puzzles and the order of events are not planned beforehand but occur during game play. Emergence is produced due to the many possible combinations of rules in card games, board games and so fourth. Juul says "Emergence is the primordial game structure" (p. 324) many early games were those of emergence.
Games of emergence come in many different, states, forms and configurations during game play. The possible arrangements of the game pieces in drafts constitute different game states, since the arrangement of a single draft by even one position can make all the difference. The possible combinations of draft pieces on game board is large, however the rules for the game can sit on a page of A4 paper and the game is still played to this day.
Games of progression however, offer many pre designed puzzles and challenger which the designer ordered, generally through level design. Progression usually relies on a intricately controlled series of events. The designer controls the challenges the player comes across through designing the levels in such as fashion the player has to encounter the events in the specific sequence. In a game of progression the quantity of game states is quite small, the designer has complete control over what is included in the game. When a player is put on a set track like an on rails game, the player travels from one in game challenge to the next one.
Emergence
When people use the term emergence, originated from the term in complexity theory. It refers to how a system behaves which can't be derived from its constituent parts. Whilst, Juul is cautious not to confuse emergent behaviour in games that display behaviours the designer did not fore see before hand (2002). Like in any complex system, the big picture is greater than all of it's part together. Some games such as chess have relatively simple rules yet generate an great deal of depth. Games like these are constructed from relatively simplistic parts, yet the number of approaches and strategies they allow are huge. No two sessions feel alike. Emergent games do not come fro the complexity of the parts it's made from but from the complexity of the many iterations with all of it's parts.
Simple Parts in Complex Systems
The contents of complexity studies all manner of complex systems in life.The agent or elements in these complex systems may be sophisticated in itself, these are particularly simulated with simple models. E.g. the flow of pedestrians in different environments, great results have been obtained by simulating pedestrians with merely a small number of rules and achievements (Ball, 2004, pp. 131-147). It is possible to generate emergent games with a small number of complex parts, mechanics of games systems which work with simplistic components yet still create emergent game play are more interesting.
Progressive
With progressive games, many of them contain stories to drive them in a particular direction, this is frequently told over the course of several game levels. Each level usually has clearly defined missions which structure the tasks in and set the player's goals for them in order to finish the level. The designer must plan out the game and the levels in such as fashion the game produces a consistent experience. Frequently the designers use a variety of mechanics to manipulate how the player is able to move through a game. When designing a game with an interesting story, understanding the progression mechanic is vital.
When designing game levels, progression in an important aspect. There key elements when a designer has to control when parts players will encounter first, these include, what they need to complete to proceed, what resources they start off with. The designer decided that abilities the player has control of and manipulating the lay out of the level, including where items are placed in the game, for example power ups. Through this, players are not thrown into the game, they are gradually brought into it. E.g. as player's go through the game exploring it and gaining experience and skills, they will gradually have an experience that is story like by gaining relevant information from event in the level.
The rules of a game are relate to the number of possible states, but it's not completely true more rules will lead to more possible states. Along with this, when a game produces a large quantity or possible states whilst using only a few rules, the game will become more accessible to players.
Game States and Game Play
When designers talk about the path the player(s) take through the possible states of a game, probability space, people sometimes describe the path a a trajectory. The different possible game play trajectories and states through a game are emergent properties of a game rule system. Game which allow lot's of different, intriguing trajectories arguably have a greater quantity of game play than games which generate fewer trajectories or not as interesting ones. Although, to determine the kind and quality of the game play is not easy, if not impossible, by merely observing the rules. By comparing the rules of two different yet simple games, you can see these difficulties. E.g. Naughts and Crosses and Connect Four.
Naughts and Crosses
1. The game is played on a 3 by 3 grid.
2. Players take turns occupying a space.
3. A space may only be taken once.
4. The first player to occupy three spaces in a row (orthogonally or diagonally) wins.
Connect Four
1. The game is played on a 6 by 6 grid.
2. Both players take turns to take up a square.
3. A space may only be taken once.
4. Only the bottom most available space in a given column is about to be occupied.
5. The first player to take up four spaces in a row wins.
While there may only be a few differences between the rules for two similar games, the difference in the game play can be massive. It can be far greater than the amount of mental effort required in order to understand the rules.
In the commercially available version of Connect Four, the most complex rule, (no. 4) is enforced via gravity: player's tokens will just automatically fall to the lowest available space in the upright playing area. This saves players from manually enforcing this rule and permits them to focus on the rule's effects instead. Even though the small differences in the complexity of the rules, tic-tack-toe is appropriate only to small children, therefore Connect Four is about to be played by adults. The latter allows for different strategies on a great scale, and takes longer to master the game. When two experienced players compete, it will certainly be an exiting match. Rather than being a certain draw as the case is with Naughts and crosses.
Comparing Emergence and Progression
In Juul's original article, he expresses a preference for game which use emergence: "On a theoretical level, emergence is the more interesting structure" (2002, p.328). This regards emergence as an approach which permits designers to produce games in which the freedom of the player is leveled with the control of the designer. In a game of emergence, the designers don't specify every single event in detail before the game is published. Though the rules might make certain events quite likely. However, in practice, a game with an emergent structure often still follows fairly consistent patterns. This is discussed by Juul, the gun fights which almost always erupt in a game of Counter-Strike (p.327).
In his other book Half-Real, he is nuanced in his discussion of emergence and progression (2005). The majority of modern computer games are hybrids. They include some features of both. GTA: San Andreas has a vast open world yet also has a mission structure which influences new elements and unlocks this world piece by piece. In the game Dues Ex, the player is shows the main path yet there are different strategies to each mission and can use different paths when they encounter different challenges along the way.
Emergence and progression are simply different, neither is better. Pure emergence games and pure progression games represent two different extremes. many casual games, are pure emergence. Pure progression games are very rare. The majority of games include elements of both mechanics, like a level in a game my exhibit emergent behavior with in a game based around a progression mechanic.
What parts will I use in my game?
Due to the nature of management games, and my research I will use progression in my game since the player will be progressing to the next level trying the reach the set goal in the level. However a little emergence may be used since pure progression games are rare. A few of the in game entities will have only a few different game states since these will be be performing one task however this could change.
What parts I might use in my game
I may use emergence on a small scale in my game since a few of the entities will not have many states, there fore adding some variety to the games state. However due to the nature of the game and the mechanics this will be on a limited scale.
References
Ball, Philip. 2004. Critical Mass: How One Thing Leads To Another. New York, NY: Farrar, Straus and Giroux.
Jull, J. 2002. "The Open and the Closed: Games of Emergence and Games of Progression.". Finland: Tampere. pp. 323-329.
Jull, J. 2005. Heal-Real: Video Games between Real Rules and Fictional Worlds. Cambridge, MA: MIT Press.
Games of emergence are those of fairly simplistic rules but much variation. The term if used because the puzzles and the order of events are not planned beforehand but occur during game play. Emergence is produced due to the many possible combinations of rules in card games, board games and so fourth. Juul says "Emergence is the primordial game structure" (p. 324) many early games were those of emergence.
Games of emergence come in many different, states, forms and configurations during game play. The possible arrangements of the game pieces in drafts constitute different game states, since the arrangement of a single draft by even one position can make all the difference. The possible combinations of draft pieces on game board is large, however the rules for the game can sit on a page of A4 paper and the game is still played to this day.
Games of progression however, offer many pre designed puzzles and challenger which the designer ordered, generally through level design. Progression usually relies on a intricately controlled series of events. The designer controls the challenges the player comes across through designing the levels in such as fashion the player has to encounter the events in the specific sequence. In a game of progression the quantity of game states is quite small, the designer has complete control over what is included in the game. When a player is put on a set track like an on rails game, the player travels from one in game challenge to the next one.
Emergence
When people use the term emergence, originated from the term in complexity theory. It refers to how a system behaves which can't be derived from its constituent parts. Whilst, Juul is cautious not to confuse emergent behaviour in games that display behaviours the designer did not fore see before hand (2002). Like in any complex system, the big picture is greater than all of it's part together. Some games such as chess have relatively simple rules yet generate an great deal of depth. Games like these are constructed from relatively simplistic parts, yet the number of approaches and strategies they allow are huge. No two sessions feel alike. Emergent games do not come fro the complexity of the parts it's made from but from the complexity of the many iterations with all of it's parts.
Simple Parts in Complex Systems
The contents of complexity studies all manner of complex systems in life.The agent or elements in these complex systems may be sophisticated in itself, these are particularly simulated with simple models. E.g. the flow of pedestrians in different environments, great results have been obtained by simulating pedestrians with merely a small number of rules and achievements (Ball, 2004, pp. 131-147). It is possible to generate emergent games with a small number of complex parts, mechanics of games systems which work with simplistic components yet still create emergent game play are more interesting.
Progressive
With progressive games, many of them contain stories to drive them in a particular direction, this is frequently told over the course of several game levels. Each level usually has clearly defined missions which structure the tasks in and set the player's goals for them in order to finish the level. The designer must plan out the game and the levels in such as fashion the game produces a consistent experience. Frequently the designers use a variety of mechanics to manipulate how the player is able to move through a game. When designing a game with an interesting story, understanding the progression mechanic is vital.
When designing game levels, progression in an important aspect. There key elements when a designer has to control when parts players will encounter first, these include, what they need to complete to proceed, what resources they start off with. The designer decided that abilities the player has control of and manipulating the lay out of the level, including where items are placed in the game, for example power ups. Through this, players are not thrown into the game, they are gradually brought into it. E.g. as player's go through the game exploring it and gaining experience and skills, they will gradually have an experience that is story like by gaining relevant information from event in the level.
The rules of a game are relate to the number of possible states, but it's not completely true more rules will lead to more possible states. Along with this, when a game produces a large quantity or possible states whilst using only a few rules, the game will become more accessible to players.
Game States and Game Play
When designers talk about the path the player(s) take through the possible states of a game, probability space, people sometimes describe the path a a trajectory. The different possible game play trajectories and states through a game are emergent properties of a game rule system. Game which allow lot's of different, intriguing trajectories arguably have a greater quantity of game play than games which generate fewer trajectories or not as interesting ones. Although, to determine the kind and quality of the game play is not easy, if not impossible, by merely observing the rules. By comparing the rules of two different yet simple games, you can see these difficulties. E.g. Naughts and Crosses and Connect Four.
Naughts and Crosses
1. The game is played on a 3 by 3 grid.
2. Players take turns occupying a space.
3. A space may only be taken once.
4. The first player to occupy three spaces in a row (orthogonally or diagonally) wins.
Connect Four
1. The game is played on a 6 by 6 grid.
2. Both players take turns to take up a square.
3. A space may only be taken once.
4. Only the bottom most available space in a given column is about to be occupied.
5. The first player to take up four spaces in a row wins.
While there may only be a few differences between the rules for two similar games, the difference in the game play can be massive. It can be far greater than the amount of mental effort required in order to understand the rules.
In the commercially available version of Connect Four, the most complex rule, (no. 4) is enforced via gravity: player's tokens will just automatically fall to the lowest available space in the upright playing area. This saves players from manually enforcing this rule and permits them to focus on the rule's effects instead. Even though the small differences in the complexity of the rules, tic-tack-toe is appropriate only to small children, therefore Connect Four is about to be played by adults. The latter allows for different strategies on a great scale, and takes longer to master the game. When two experienced players compete, it will certainly be an exiting match. Rather than being a certain draw as the case is with Naughts and crosses.
Comparing Emergence and Progression
In Juul's original article, he expresses a preference for game which use emergence: "On a theoretical level, emergence is the more interesting structure" (2002, p.328). This regards emergence as an approach which permits designers to produce games in which the freedom of the player is leveled with the control of the designer. In a game of emergence, the designers don't specify every single event in detail before the game is published. Though the rules might make certain events quite likely. However, in practice, a game with an emergent structure often still follows fairly consistent patterns. This is discussed by Juul, the gun fights which almost always erupt in a game of Counter-Strike (p.327).
In his other book Half-Real, he is nuanced in his discussion of emergence and progression (2005). The majority of modern computer games are hybrids. They include some features of both. GTA: San Andreas has a vast open world yet also has a mission structure which influences new elements and unlocks this world piece by piece. In the game Dues Ex, the player is shows the main path yet there are different strategies to each mission and can use different paths when they encounter different challenges along the way.
Emergence and progression are simply different, neither is better. Pure emergence games and pure progression games represent two different extremes. many casual games, are pure emergence. Pure progression games are very rare. The majority of games include elements of both mechanics, like a level in a game my exhibit emergent behavior with in a game based around a progression mechanic.
What parts will I use in my game?
Due to the nature of management games, and my research I will use progression in my game since the player will be progressing to the next level trying the reach the set goal in the level. However a little emergence may be used since pure progression games are rare. A few of the in game entities will have only a few different game states since these will be be performing one task however this could change.
What parts I might use in my game
I may use emergence on a small scale in my game since a few of the entities will not have many states, there fore adding some variety to the games state. However due to the nature of the game and the mechanics this will be on a limited scale.
References
Ball, Philip. 2004. Critical Mass: How One Thing Leads To Another. New York, NY: Farrar, Straus and Giroux.
Jull, J. 2002. "The Open and the Closed: Games of Emergence and Games of Progression.". Finland: Tampere. pp. 323-329.
Jull, J. 2005. Heal-Real: Video Games between Real Rules and Fictional Worlds. Cambridge, MA: MIT Press.
Saturday, 19 October 2013
More research in managing mechanic Machinations
More on managing mechanics and a little about economy's. But mostly managing mechanics.
I have been reading a 'Gamasautra' article about Machinations, which is about the flow and management of resources in a complex games system.It is interesting because there is a free flash tool for developers to test out their systems. It simplifies complex games systems and the user can break down their systems to individual parts to see how their in game flow of resources works. The reason this was invented was because it is difficult to paper prototype complex systems and if you do it via code, this can take a while and if it doesn't work, the code and time is wasted. This is also good for testing out feed back loops in game economies and certain structural features in games.
It can also be good for testing the resource flow of multi-player games for a single play because the designer can get into the mind set of a single player and look at their in game options. It is also a good way to look at the structural qualities of game mechanics with out any complex coding.
The main purpose if Machinations is for designers to model activity, communication between parts of a games internal economy and interaction. The article says any games economic system is dominated by the flow of it's resources.
The tool allows designers to model a game's internal economy by using Machination diagrams that use several types of nodes which, push, pull, gather and distribute game resources. It also has resource connections to determine how these resources move between two elements, and the state connections determine how the current distribution of resources in game modifies all the other elements of the diagram.
How does it work?
The diagrams are composed or pools and resource connections. A pool is a location which is where resources are gathered. In the applet they are represented by open circles and the ones with more complicated functions have a tweaked visual appearance (but that's for later). The resources stored with in them are represented by smaller circles stacked up on them. When the amount of resources is to high to show visually, they are represented by an integer number with in the circle.
Pools are used to model entities in an economy (but they can't use factional values, only integers). For example if you had a resource called 'Petrol' and an entity called 'Player's petrol tank', one would use a pool to model the petrol tank.
The most basic form of connection is a 'resource connection', it drives resources form a single to node (or entity) to another in the feedback loop game structure. In the diagram they are represented as solid arrows connecting the nodes in the diagram. These connection can transfer resources at all sorts of rates. There is a label adjacent to the resource connection indicating the quantity of resources that can be moved along the connection in a single time step. If the label is blank, it means it transfers one resource.
The random flow rates of resources between nodes can be specified and tweaked using the label box. Random rates are represented in different forms. For example, the rates can be represented using different die rolls and a die symbol will show near the connection. Due to this the applet diagram will randomly generate a number from the type of die (or dice) specified and possibly add a modifier to the combination. In other words the Mechinations Tool is able to generate random number combinations like pen and paper role-playing games. In PRG's a six sided die is represented as a D6 and two of those dice is represented as 2D6, thus the result would produce a number between 2 and 12.
But there is another way. These random number can be represented as percentages. A resource connection labeled 25 percent indicated there is a 25% change one resource can flow along the connection at each time step. One can use percentages higher than 100%. E.g. 350% means a transfer rate of at least three plus a 50% chance if one more.
Activation modes
In each iteration nodes can fire. When a node fires, it transfers resources along the connections which are connected to it. A node can fire depending on it's activation mode. A node has four activation nodes.
A node can fire automatically, so every iteration it fires. All automatic nodes fire together.
A node can be interactive, meaning it fires when the player clicks on it representing a player action. In the Machination tool these fire when a player clicks them. These nodes have a double out line.
A node can also be a starting action, this is represents with a little 's'. These fire before the first iteration, just after the user clicks the 'run' button.
A node can also be passive, meaning it only fires in response to a trigger generated by another element. Resources are able to be pushed to other nodes, but they don't push or pull unless triggered, these don't have a special mark.
Pulling and Pushing Resources
When a pool fires, it will attempt to pull any resources through any inputs connected to it in some way. The quantity it draws is determined by the rate set by the push nod. When in this node, when the pool fires, it pushed resources through it's out put connections, at the rate of it's out put resource connection. A pool push mode is indicated with a p, a pool which has only out puts is always considered to be in push mode, in that case the P marker is omitted.
If a pool is attempting to pull more resources than exits at the end of it's inputs, it will deal with it in one of two possible ways.
Automatically a node draws many resources as it possibly can, up to the flow rates determined by it's inputs. If not enough resources are accessible, it can still pull those which are.
Alternatively, a node (or pool) is able to be set to draw all of no resources. In this mode, when too few resources are accessible, nothing is drawn.
In a managing game this would be useful when dealing with an internal economy and distributing resources.
What will I include in my game from this?
For my recourse managing game I will include, resource pools since these are entities for resources to be held in.
Interactive nodes will defiantly be present since they represent a player action, when interacting with other entities to transfer resources. This action could be used as a trader for example in an economy.
Automatic nodes will be in my management game. I could use this to represent a 'source' where resources are created in the game for the economy.
Passive nodes. This could be used as a possible source or drain. However this would be more suited to being a converter or trader if used in an economy. In my option though it is more suited to being a converter. It could loosely be used as a source, but one that is infrequently used though.
Resource connections
I will defiantly use these in my game since resources need to flow to and form different entities in order to operate correctly. I could also utilize the rate at which the resources flow in these connections between entities. This would be useful when transferring resources from sources to another entity at specific rates, which could later be modified.
Pushing and pulling Resources
A node that pushes resources from one entity to another would be useful with a 'source' in a managing game since sources create resources from thin air and do not require any input. These would just push resources to the next node required or store them in the entity until needed.
If there was a player avatar this would be both a push and pull node since the player would gather all resources they could get from sources, yet they would push resources towards drains. E.g. bullets towards and enemy until the enemy dies in which the enemy is the drain.
A drain in a game economy would require a pull function since it will be physically removing resources from the game itself. It would be set to pull all resources because if not enough of a resource is available it will destroy any sent to it down a resource connection.
A converter and trader would need both a pull and push node since a resource product would flow through one connection and out the other end. A trader would be represented by a node that only draws resources when enough are available, if not nothing is drawn. This is because a trader needs a specific number of resources to trade for another set of resources.
This would also be good for a bank entity or inventory to store resources for a later time in a game. This is because all they have to do is store resources regardless of the quantity flowing from each connection.
What Might be included from this?
A converter on the other hand would pull any resources from it's inputs in order to convert the resources. This would be useful since it will pull as many resources as it can, up to the rates of it's inputs (upon t activation of certain conditions). However if not enough resources are available, it will pull as many as it can. This could work with a converter because it could convert as many resources as it can get it's hands on, depending of the requirements of the process.
Starting action nodes. I'm not sure weather this will be needed in the economy. It could be used to trigger of an event in a level in the game.
References
Adams, E. (2012). The Designer's Notebook: Machinations, A New Way to Design Game Mechanics. Available: http://www.gamasutra.com/view/feature/176033/the_designers_notebook_.php?page=1. Last accessed 19th October 2013.
I have been reading a 'Gamasautra' article about Machinations, which is about the flow and management of resources in a complex games system.It is interesting because there is a free flash tool for developers to test out their systems. It simplifies complex games systems and the user can break down their systems to individual parts to see how their in game flow of resources works. The reason this was invented was because it is difficult to paper prototype complex systems and if you do it via code, this can take a while and if it doesn't work, the code and time is wasted. This is also good for testing out feed back loops in game economies and certain structural features in games.
It can also be good for testing the resource flow of multi-player games for a single play because the designer can get into the mind set of a single player and look at their in game options. It is also a good way to look at the structural qualities of game mechanics with out any complex coding.
The main purpose if Machinations is for designers to model activity, communication between parts of a games internal economy and interaction. The article says any games economic system is dominated by the flow of it's resources.
The tool allows designers to model a game's internal economy by using Machination diagrams that use several types of nodes which, push, pull, gather and distribute game resources. It also has resource connections to determine how these resources move between two elements, and the state connections determine how the current distribution of resources in game modifies all the other elements of the diagram.
How does it work?
The diagrams are composed or pools and resource connections. A pool is a location which is where resources are gathered. In the applet they are represented by open circles and the ones with more complicated functions have a tweaked visual appearance (but that's for later). The resources stored with in them are represented by smaller circles stacked up on them. When the amount of resources is to high to show visually, they are represented by an integer number with in the circle.
Pools are used to model entities in an economy (but they can't use factional values, only integers). For example if you had a resource called 'Petrol' and an entity called 'Player's petrol tank', one would use a pool to model the petrol tank.
The most basic form of connection is a 'resource connection', it drives resources form a single to node (or entity) to another in the feedback loop game structure. In the diagram they are represented as solid arrows connecting the nodes in the diagram. These connection can transfer resources at all sorts of rates. There is a label adjacent to the resource connection indicating the quantity of resources that can be moved along the connection in a single time step. If the label is blank, it means it transfers one resource.
The random flow rates of resources between nodes can be specified and tweaked using the label box. Random rates are represented in different forms. For example, the rates can be represented using different die rolls and a die symbol will show near the connection. Due to this the applet diagram will randomly generate a number from the type of die (or dice) specified and possibly add a modifier to the combination. In other words the Mechinations Tool is able to generate random number combinations like pen and paper role-playing games. In PRG's a six sided die is represented as a D6 and two of those dice is represented as 2D6, thus the result would produce a number between 2 and 12.
But there is another way. These random number can be represented as percentages. A resource connection labeled 25 percent indicated there is a 25% change one resource can flow along the connection at each time step. One can use percentages higher than 100%. E.g. 350% means a transfer rate of at least three plus a 50% chance if one more.
Activation modes
In each iteration nodes can fire. When a node fires, it transfers resources along the connections which are connected to it. A node can fire depending on it's activation mode. A node has four activation nodes.
A node can fire automatically, so every iteration it fires. All automatic nodes fire together.
A node can be interactive, meaning it fires when the player clicks on it representing a player action. In the Machination tool these fire when a player clicks them. These nodes have a double out line.
A node can also be a starting action, this is represents with a little 's'. These fire before the first iteration, just after the user clicks the 'run' button.
A node can also be passive, meaning it only fires in response to a trigger generated by another element. Resources are able to be pushed to other nodes, but they don't push or pull unless triggered, these don't have a special mark.
Pulling and Pushing Resources
When a pool fires, it will attempt to pull any resources through any inputs connected to it in some way. The quantity it draws is determined by the rate set by the push nod. When in this node, when the pool fires, it pushed resources through it's out put connections, at the rate of it's out put resource connection. A pool push mode is indicated with a p, a pool which has only out puts is always considered to be in push mode, in that case the P marker is omitted.
If a pool is attempting to pull more resources than exits at the end of it's inputs, it will deal with it in one of two possible ways.
Automatically a node draws many resources as it possibly can, up to the flow rates determined by it's inputs. If not enough resources are accessible, it can still pull those which are.
Alternatively, a node (or pool) is able to be set to draw all of no resources. In this mode, when too few resources are accessible, nothing is drawn.
In a managing game this would be useful when dealing with an internal economy and distributing resources.
What will I include in my game from this?
For my recourse managing game I will include, resource pools since these are entities for resources to be held in.
Interactive nodes will defiantly be present since they represent a player action, when interacting with other entities to transfer resources. This action could be used as a trader for example in an economy.
Automatic nodes will be in my management game. I could use this to represent a 'source' where resources are created in the game for the economy.
Passive nodes. This could be used as a possible source or drain. However this would be more suited to being a converter or trader if used in an economy. In my option though it is more suited to being a converter. It could loosely be used as a source, but one that is infrequently used though.
Resource connections
I will defiantly use these in my game since resources need to flow to and form different entities in order to operate correctly. I could also utilize the rate at which the resources flow in these connections between entities. This would be useful when transferring resources from sources to another entity at specific rates, which could later be modified.
Pushing and pulling Resources
A node that pushes resources from one entity to another would be useful with a 'source' in a managing game since sources create resources from thin air and do not require any input. These would just push resources to the next node required or store them in the entity until needed.
If there was a player avatar this would be both a push and pull node since the player would gather all resources they could get from sources, yet they would push resources towards drains. E.g. bullets towards and enemy until the enemy dies in which the enemy is the drain.
A drain in a game economy would require a pull function since it will be physically removing resources from the game itself. It would be set to pull all resources because if not enough of a resource is available it will destroy any sent to it down a resource connection.
A converter and trader would need both a pull and push node since a resource product would flow through one connection and out the other end. A trader would be represented by a node that only draws resources when enough are available, if not nothing is drawn. This is because a trader needs a specific number of resources to trade for another set of resources.
This would also be good for a bank entity or inventory to store resources for a later time in a game. This is because all they have to do is store resources regardless of the quantity flowing from each connection.
What Might be included from this?
A converter on the other hand would pull any resources from it's inputs in order to convert the resources. This would be useful since it will pull as many resources as it can, up to the rates of it's inputs (upon t activation of certain conditions). However if not enough resources are available, it will pull as many as it can. This could work with a converter because it could convert as many resources as it can get it's hands on, depending of the requirements of the process.
Starting action nodes. I'm not sure weather this will be needed in the economy. It could be used to trigger of an event in a level in the game.
References
Adams, E. (2012). The Designer's Notebook: Machinations, A New Way to Design Game Mechanics. Available: http://www.gamasutra.com/view/feature/176033/the_designers_notebook_.php?page=1. Last accessed 19th October 2013.
Thursday, 17 October 2013
Refining the mechanics to a degree
One of my ideas was to look into procedural generation. I mentioned this to Chris and I read a book on it that he decremented, and I read the areas he decremented I start on and other parts I was interested in. He suggested looking into textures, then noise, then another area (I think bump maps(but my memory is horrible)).
Therefore over the weekend I read the chapters on texturing, noise, bump mapping, fractals and terrain. Even though these areas were interesting, the mathematical formulas were a bit above my level and I worked out they would annoy me in the long run.
After this I worked out I would rather make a resource management game in Unity. I have previously worked with resource management game in a past project. I enjoyed creating the game and researching the managing resource mechanic, however I do not feel I fully explored the area and would like to make a robust game out of it.
For the time being I will keep the helicopter game idea with the managing mechanic but I will develop the skin for it later (but shortly).
What mechanics and things my game will contain
Resource managing mechanic:
Resource managing is when a player is forced to keep track of multiple elements while frantically clicking around a computer screen attempting to keep everything stable and on track. When creating a board game there variables must be limited since people can't keep track of too many variables. However with computers, the designer can hide tonnes of these and show only what the player needs to see, which adds more polish and complexity. This can mean keeping track of more game pieces, but managing more items such as capacity variables and and how far away some pieces are to each other (Trefy, G. (2010), p139).
Resources:
A resources is any concept which can be measured numerically (either as an integer or decimal). Nearly anything in a game can function as a resource, (this includes disposable items under the players control). Anything a player can gather, produce, collect or destroy is most likely a resource of some kind (Adams, E and Dormans, J. (2012), p60).
Tangible
A tangible resource is a resource which holds physical qualities and can be stored in a particular place in world space and occupies world space. These often have to be more else where in the game world. An example of this is a players inventory like a ruck sack or if a player has mined gold and need to store it some where like a bank (Adams, E and Dormans, J. (2012), p60).
Intangible:
Any resources in the game world that do not occupy world space or posses physical properties are intangible and they do not need to be held is a specific location. This can include, player health, or time for a timer (Adams, E and Dormans, J. (2012), p60).
Entities:
An entity can store specific quantities of a resource. For example in my game, the player avatar, water tower or house, are entities since they store resources at a specific quantity (Adams, E and Dormans, J. (2012), p.61).
Simple entities:
A simple entity stores only one value of a resource. For example, a glass can only hold fluid in it. In my game for the time being, the houses on fire will be simple entities since they will only be able to hold the variable for the fires value (unless things become more complex) (Adams, E and Dormans, J. (2012), p.61).
Compound entities:
These are a collection of a number of related simple entities, meaning compound entities can hold more than a single value. For example, the main avatar in my managing game will have a maximum speed value, damage value and maximum water value. All of these entities tied together compose a compound entity, and the simple entities are relabeled as attributes (Adams, E and Dormans, J. (2012), p.61).
Sources:
This mechanic creates completely new resources out of thin air. They may produce a resource when a certain condition is met, at a certain time. A source will generate a resource of some kind and store it in an entity some where in the game world. Sources can produce resources and a continuous production rate, or can be triggered by events in game. They can also be activated and deactivated (Adams, E and Dormans, J. (2012), pp.61-62).
Drains:
These are the polar opposite of sources. These physically take resources out of the game, reducing the amount stored in an entity permanently removing them from the game (Adams, E and Dormans, J. (2012), p.62). For example in my game, when I put out a fire, the fire is a drain since it reduces the amount of water in the game world.
What my game will possibly contain
Converters:
A converter physically turns one kind of resource into another in the game world. For example if a player has some iron ore and they convert it into a iron block when it is smelted. The act of smelting is a converter mechanic and converts resources at a specific rate, in some game the player can upgrade the efficiency of the process (Adams, E and Dormans, J. (2012), p.62).
Traders:
A trader, moved resources from one place in game to another completely different place in the opposite direction, according to a given exchange rule. Unlike converters, traders do not crate of destroy resources, just move them from one entity to another (Adams, E and Dormans, J. (2012), p.62).
References
Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p60.
Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p61.
Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p62.
Trefy, G (2010). Casual Games Design: Designing Play for the Gamer in All of Us. Burlington: Morgan Kaufmen. p139.
After this I worked out I would rather make a resource management game in Unity. I have previously worked with resource management game in a past project. I enjoyed creating the game and researching the managing resource mechanic, however I do not feel I fully explored the area and would like to make a robust game out of it.
For the time being I will keep the helicopter game idea with the managing mechanic but I will develop the skin for it later (but shortly).
What mechanics and things my game will contain
Resource managing mechanic:
Resource managing is when a player is forced to keep track of multiple elements while frantically clicking around a computer screen attempting to keep everything stable and on track. When creating a board game there variables must be limited since people can't keep track of too many variables. However with computers, the designer can hide tonnes of these and show only what the player needs to see, which adds more polish and complexity. This can mean keeping track of more game pieces, but managing more items such as capacity variables and and how far away some pieces are to each other (Trefy, G. (2010), p139).
Resources:
A resources is any concept which can be measured numerically (either as an integer or decimal). Nearly anything in a game can function as a resource, (this includes disposable items under the players control). Anything a player can gather, produce, collect or destroy is most likely a resource of some kind (Adams, E and Dormans, J. (2012), p60).
Tangible
A tangible resource is a resource which holds physical qualities and can be stored in a particular place in world space and occupies world space. These often have to be more else where in the game world. An example of this is a players inventory like a ruck sack or if a player has mined gold and need to store it some where like a bank (Adams, E and Dormans, J. (2012), p60).
Intangible:
Any resources in the game world that do not occupy world space or posses physical properties are intangible and they do not need to be held is a specific location. This can include, player health, or time for a timer (Adams, E and Dormans, J. (2012), p60).
Entities:
An entity can store specific quantities of a resource. For example in my game, the player avatar, water tower or house, are entities since they store resources at a specific quantity (Adams, E and Dormans, J. (2012), p.61).
Simple entities:
A simple entity stores only one value of a resource. For example, a glass can only hold fluid in it. In my game for the time being, the houses on fire will be simple entities since they will only be able to hold the variable for the fires value (unless things become more complex) (Adams, E and Dormans, J. (2012), p.61).
Compound entities:
These are a collection of a number of related simple entities, meaning compound entities can hold more than a single value. For example, the main avatar in my managing game will have a maximum speed value, damage value and maximum water value. All of these entities tied together compose a compound entity, and the simple entities are relabeled as attributes (Adams, E and Dormans, J. (2012), p.61).
Sources:
This mechanic creates completely new resources out of thin air. They may produce a resource when a certain condition is met, at a certain time. A source will generate a resource of some kind and store it in an entity some where in the game world. Sources can produce resources and a continuous production rate, or can be triggered by events in game. They can also be activated and deactivated (Adams, E and Dormans, J. (2012), pp.61-62).
Drains:
These are the polar opposite of sources. These physically take resources out of the game, reducing the amount stored in an entity permanently removing them from the game (Adams, E and Dormans, J. (2012), p.62). For example in my game, when I put out a fire, the fire is a drain since it reduces the amount of water in the game world.
What my game will possibly contain
Converters:
A converter physically turns one kind of resource into another in the game world. For example if a player has some iron ore and they convert it into a iron block when it is smelted. The act of smelting is a converter mechanic and converts resources at a specific rate, in some game the player can upgrade the efficiency of the process (Adams, E and Dormans, J. (2012), p.62).
Traders:
A trader, moved resources from one place in game to another completely different place in the opposite direction, according to a given exchange rule. Unlike converters, traders do not crate of destroy resources, just move them from one entity to another (Adams, E and Dormans, J. (2012), p.62).
References
Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p60.
Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p61.
Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p62.
Trefy, G (2010). Casual Games Design: Designing Play for the Gamer in All of Us. Burlington: Morgan Kaufmen. p139.
Sunday, 13 October 2013
More ideas and refinements: from particle systems to proceduralgeneration
After talking through things with my tutors I have made some progress with ideas. Firstly I thought concentrating on coding with Unity particle effects along with physics. However after a discussion with Chris, I found out when dealing with particle systems interacting with in game physics, Unity does not deal with this well. After this I decided to concentrate more on particle systems themselves.
I found out Unity has two types of particle systems, the legacy one which has to be built out of components and is controlled via scripting. The other being the new Shrunken system, which is for newer users and does a lot for you. After talking to Chris again, he said to research the topic to see if there is enough work to cover a year with the new particle system. After the discussion, I got to work reading the Unity documentation. Unfortunatly after doing this I found out there wasn't enough work to cover a whole year. Due to this I began reading the documentation on the legacy documentation, but again over another disscussion with Chris I discovered the Legacy system's days are numbered since the Unity developers are planning on phasing out the old system.
After this I asked Chris about procedural generation. He said it could easily fill a years worth of work. He recommended starting with textures, then adding noise to the textures and building up from there if I want to build a level with it.
I will go into more detail about what I have been reading with my next blog post.
Sunday, 6 October 2013
Ideas for my dissertation (helicopter game)
Hello, this is the first blog for keeping track on what I have done so far for my dissertation. This blog post will be explaining what my dissertation is about.
For my dissertation I would like to demonstrate a T - shaped skills set. This means I have one of two skills that are the back bone of the project, but showing I also have other skills in the field that may be useful to a company or if I go independent.
The back bone of the project will be my code and design skills since these are versatile skills and are valued by many companies. The other reason is I would like to refine the code and design skills I already have whilst learning new skills in the field (including useful skills in the other areas).
The design fields I would like to explore are the managing mechanic and some level design. The reason for this is, they would both fit well together for this game for the player to travel across the level. The other reason is I have experimented with managing mechanics before, however I would like to explore it in more depth. Because this would be a resource management game. I would also like to explore some aspects of unity animation, level design as well as the managing mechanic as a whole.
How would I like to be marked:
I would like to marked on my code and design skills in general. I would like to be marked on the other sides like animation, modelling and the such, but these are not the first priority for marking. for some textures I may purchase them or find royalty free ones and reference them as to not hinder the development of the game.
Ideas:
- The fires could change shape or alter in some way depending on what start they are in or if the player is extinguishing them.
- If the player uses the wrong type of extinguisher, the fire could be exaserbated or not change.
What my aims with this project:
To have the helicopter,
To have at least two levels (Including a tutorial level as Level 1)
My target audience for this game are young males ranging to teenagers, possibly early twenties.
Basics
Mechanics:
Skin (Art):
Note:
This is the first attempt at refining the ideas, mechanics and art. In the next blog post these ideas will be more refined and improved (possibly some of the mechanics to a degree). The items discussed in this blog post such as the theme or skin of the art assets may be subject to change. However these changes will be confirmed shortly as to not delay the development of the project itself. Also how I would liked to be marked on the project will be confirmed shortly, to make sure I am on the right track.
For my dissertation I would like to demonstrate a T - shaped skills set. This means I have one of two skills that are the back bone of the project, but showing I also have other skills in the field that may be useful to a company or if I go independent.
The back bone of the project will be my code and design skills since these are versatile skills and are valued by many companies. The other reason is I would like to refine the code and design skills I already have whilst learning new skills in the field (including useful skills in the other areas).
The design fields I would like to explore are the managing mechanic and some level design. The reason for this is, they would both fit well together for this game for the player to travel across the level. The other reason is I have experimented with managing mechanics before, however I would like to explore it in more depth. Because this would be a resource management game. I would also like to explore some aspects of unity animation, level design as well as the managing mechanic as a whole.
How would I like to be marked:
I would like to marked on my code and design skills in general. I would like to be marked on the other sides like animation, modelling and the such, but these are not the first priority for marking. for some textures I may purchase them or find royalty free ones and reference them as to not hinder the development of the game.
In my next blog post I will include the research I have done for this project. These things include, art style, animation techniques, types of games similar to this on the market and so fourth.
Ideas:
- Player controls a helicopter that fires water from a canon attached to it. (possibly a bucket type thing as well?)
- The player uses the water cannon to put of fires on buildings, forests and/or feilds.
- The player could rescue people / objects or animalsfrom burning buildings.
- The fires could get worse if the player doesn't act on them quickly.
- Fires could, spread, become more intense or get worse in clour or more damaging.
- Fires could spread to different buildings or objects.
- There could be different types of fires, e.g. electrica, chemical, normal, oil. These could require different types of extinguishers.
- These fires could combine and get get worse.
- The fires could change shape or alter in some way depending on what start they are in or if the player is extinguishing them.
- If the player uses the wrong type of extinguisher, the fire could be exaserbated or not change.
- Lots of resource managing mechanic possibilities and level design opportunities.
- The player could transfport repair supplies or something to other parts of the level or gain extra points.
- The helicopter could be repaired and refuled
- The player could upgrade the helicopter between levels.
- If the player can't get past a level, the can replay a level they are good at and pay to unlock the next level.
- Laser guide
- Modular level design and creation
- Semi-procedural generation?
What my aims with this project:
To have the helicopter,
To have at least two levels (Including a tutorial level as Level 1)
How can I make the player want to out out the fires and do some good in the game world.
How ca I make them think, 'oh crap' if one of the fires has gotten out of hand.
Target Audience:
Target Audience:
My target audience for this game are young males ranging to teenagers, possibly early twenties.
Basics
Mechanics:
Controlling an object.
Firing water (or fluid) at a flammable objects (specifically fire).
Resource managing mechanic - player manages water resources for fires. Players must make sure fires don’t go out of control.
The fires could damage the avatar if the player get’s too close, or it could damage the building.
The fire could change shape when being extinguished by the water. Different types of fire could be more difficult to put out.
The fires could also be a clock, therefore also a time management game? E.g. The fires could become more intense over time and/ or spread their area. This could be used also af a time management mechanic, since time could be a resource if the player doesn’t keep an eye on things.
The player will only be able to jump (or fly) to a certain height or distance.
Because this is a resource managing mechanic, the player will have to refuel somehow or refill their water. Time could be done in later levels by allowing the player to have enough water for early levels, but then the player could go to a source in the level and refill. However the player would have to manage their time correctly. Or the water could replenish automatically over time and the avatar could be a source.
Bullet Time - The player can slow down time for a limited period.
Player Avatar - kangaroo, flea, Extra terrestrial sauces or space craft. Other anthropomorphic creature.
Fire(s) - these would be implemented via a particle effect. This method seems efficient and versatile. As the fire grows over time the color could become more intense and spread. It could also activate another fire particle system. adjacent to it. It could also be affected by wind, or external forces.
When the player is extinguishing the fire, it could reduce in size and intensity. Also if the fire has a different cause, such as electrical or chemical, the particle colour could be different or tinted in some way. Or it could have a different hue, to show the player this is a different type of fire,
Smoke around fire - this again would be implemented via a particle effect emitter. This will be very dark in colour. It will gradualy become larger than the fire itself as the fire grows larger.
- Fire details
Art style - slightly cartoony
Possible themes. Kangeroo. Alien abduction.
I may not go with a helicopter since helicopters are used more in simulation games, which have a serious tone. Some people find this entertaining however, it would be difficult to make this fun in some way. For this reason I may change the player avatar to something more anthropomorphic or humanoid since this will aid with player, avatar bonding and will make the player
Houses. - Detached, semi-detached, 2 - 3 floors. Normal triangular roof. The houses could appear more damaged or the colour tint could change as the fire gets worse.
Buildings - Offices, Shops, 10, 20 or thirty stories tall. Glass office buildings.
Trees. - Small trees, different breeds of trees.
Bushes or shrubs?
GUI -- Score counter
GUI -- water tank display
GUI -- energy or fuel display?Note:
This is the first attempt at refining the ideas, mechanics and art. In the next blog post these ideas will be more refined and improved (possibly some of the mechanics to a degree). The items discussed in this blog post such as the theme or skin of the art assets may be subject to change. However these changes will be confirmed shortly as to not delay the development of the project itself. Also how I would liked to be marked on the project will be confirmed shortly, to make sure I am on the right track.
Subscribe to:
Posts (Atom)