Game Idea
Synopsis
The game is set in a place known as Avalon where a war has broken out between the seraph and the hellion clan. The seraph kind are beings of light whereas hellions are beings of darkness. The war started when the clan leader of the hellions kidnapped the daughter of the seraph kind’s leader and rescuing the princess will be the main mission for the game. In the game you will play as the female protagonist named Aurelia who is the sister of the kidnapped princess Oriel.
Objective
The way my game works in terms of controls and gameplay is very much inspired by the game Horizon zero dawn that was initially released on February 28 this year, in the game Horizon you get to play as the strong female protagonist, Aloy. At the start I thought of using a male protagonist who is the love interest of the kidnapped princess but I thought that that would be too cliché so I decided to use a strong female lead instead because you don’t get to see many games with strong female protagonists.
In a way my idea was also a little bit inspired by the original super mario where mario has to go and rescue the princess from the antagonist of the game. I thought of using a rescue based storyline because I felt like it would add more feeling and character to the plot of the game.
Target Audience
Since my game idea is heavily inspired by the game Horizon zero dawn I’d say that we’ll probably have around the same age demographics. When I was researching Horizon’s user ratings I found out that 888 of the voters were male and only 101 were female. There were 409 that voted who were between the ages of 18 and 29, 360 of which are male and only 44 being female. There were also 416 voters between the ages of 30 and 44 of which 371 of them are male and only 39 female voters. My game will have a different PEGI rating as Horizon is only 16, mine will have a higher rating because my game will include violence, blood and maybe some slight nudity where as in Horizon you only go around fighting robots. As for my target audience based on the research that I did on Horizon’s user rating or age demographic my game will be targeting people between the ages of 30-44.
Legal and Ethical Checklist
I have checked my work for decency, representation of race, gender religion and sexuality and decided that I believe that it has met an appropriate standard. I also confirm that I own any relevant intellectual property withing the work that I have produced. If I were to use something as a reference I will make sure to site it to where I got reference from.
Delivery
By the end of this project I expect to have a full collection of scanned and photographed versions of my concept art portfolio for my game idea. The collection should include concept sketches, alternative designs and final design of the protagonist, antagonist, NPCs, objects and terrain. The collection should also include the planning of the concept like the research and the mind maps for each of the topics that I will be creating sketches for.
By the end of this project I expect to have a full collection of scanned and photographed versions of my concept art portfolio for my game idea. The collection should include concept sketches, alternative designs and final design of the protagonist, antagonist, NPCs, objects and terrain. The collection should also include the planning of the concept like the research and the mind maps for each of the topics that I will be creating sketches for.
These are the 10 principles of agile.
1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential
User Involvement
In some cases it's not always possible to have the users to be directly involved in developing projects, like if the agile development project is to build a product where the real end users will be the external consumers and customers. In this kinds of events it is crucial to have the a senior or and experienced user representative involved throughout the process of the project. There are many reasons why it is important to have an experienced user representative or a senior in these events, however I will only mention a few which I think are important
- Requirements of the project will be clearly communicated and understood at a high level at the outset.
- Each requirements are appropriately prioritized depending on the needs of the user and the market
- Timely decisions are made about the project's features, priorities, issues, and whether the product is ready or not.
- It makes the user/business interested in the project's daily development.
- There is completely transparency throughout the development of the project as there should be nothing to hide.
- The right product can be delivered.
All of the many reasons are very important to the development of the project however, some are just more important than others. But it's clear and safe to say that communication is key for an efficient and effective delivery of the product.
Links:http://www.nhsinvolvement.co.uk/about-involvement/what-is-involvement
Team Empowerment
It is necessary for an agile development team to have members that can make decisions on a timely basis. The first principle is one of the few other principles that enables this, meaning that the user or user representative from the business must be very involved on a daily basis.
The project team must be empowered in some way to make decisions in order for them to take responsibility on delivering the product and they must have complete ownership of this. Interfering with the project team can be disruptive and can reduce their motivation.
The team must first establish and clarify the requirements together, prioritize them together, agree to the tasks required to deliver them together and estimate the effort involved together.
This means that to for maximum efficiency the project development team must work on everything together to ensure that the product is delivered properly.
I think that this is a key principle because it fortifies buy-in and the commitment from the whole of the project development team from the beginning of the development and this is something that then pays dividends, this is something that that company pays its shareholders out of its profits.
However as all kinds of challenges arise throughout the development of the project, the team then feels a real sense of ownership things then doesn't feel so expensive.
Links:
https://miovision.com/blog/top-10-tactics-for-managing-in-an-empowered-environment/
Develop small, incremental releases and iterate
Agile development projects are usually delivered in small bite-sized parts. In a more traditional way of doing software development projects the simplified cycle is usually to analyse, develop and test. They do this by first gathering all the known requirements for the product, then develop all the elements of the software and they then test the whole of the product until they feel like it is fit for release. They must repeat the cycle of analyse, develop and test for each feature of the product, one feature at a time. Following this principle comes with a few advantages. It reduces the risk of problems arising because it allows clear visibility of what is and what is not completed to date throughout the project. It increases the value of the product as it allows you to deliver some benefits early which then enables you to release the product whenever it is deemed good enough, which saves you the effort of having to wait for all intended features to be ready. It also for more flexibility withing the production because you can choose to change direction or adapt the other iterations by basing it on what you are actually seeing and using the product. And lastly it results to better cost management because unlike all-too-many software development projects where you run over the budget, some values can still be realized meaning that there will be no need to throw everything in the trash when you run short on the funds.Before moving on to a completely different development projects you must first make sure that each feature has been fully developed otherwise this approach will not be practical.
Links:
https://www.etsy.com/listing/192312819/how-do-you-eat-an-elephant-animal
80/20 principle.
the 80/20 rule also known as Pareto's law. Is a theory about the law of distribution and how many of these things have a similar distribution curve.And this typically means that 80% of what you get, may only come from only 20% of what you actually do.
Pareto's law is visible in many situations, it may not be exactly 80/20 but is most certainly that of the principles which the majority of your results will most of the time come from the minority of your efforts. In agile development it is important to focus on the 20% effort which gets the majority of the results rather than blindly focusing on the work that takes a lot of effort but doesn't actually produce much result.
Links:
http://theviewinside.me/live-the-8020-rule/
Project stack.
For my final major project I decided to create a project stack because it allows for me to plan and control the development of the project. A project stack is basically a stack of listed tasks that is required for the development of the project which also acts as a guide.It is a creative way of managing a project as you can manipulate the sizes of the boxes based on how important or how long you think that task will take and as you can see from the image on the right, it is the project stack that I made for my final project and you can see how some task bow are bigger than others, some might be equally the same size but that only means that they're about as important as the other.
You can also see that it's quite an appealing technique as it as colorful as it is useful, The colors mean whether each task is finished, in development or not yet started. Green means that it's basically finished or nearly there, yellow or orange means that it is still in development and red means that it has not yet been started.
This technique can be very useful for both a small group and a single person. Its useful for a group because each box on the stack can be assigned to each person which can then allow for them to who is nearly finished, in development or not yet started by using the colors, it also takes into consideration that not every will have equal workloads because of the sizes of the box each member was assigned to.
I think that the project stack matches the 80/20 principle well because the sizes of the task boxes represent their importance and so you are able to identify which ones will take less effort but produce the most results.
The image below is the spreadsheet that I also made to help me manage my final major project. Unlike the project stack a spreadsheet is less colorful however it is just as useful.
The spreadsheet I would say is more specific in terms of numbers because as you can see from the image below, it allows for you to set up a schedule for each stack and it clearly outlines the estimated start and end date of each task, it also allows you to show which member of the group is assigned to that particular task which in this case I will be the only one to do the tasks so I assigned my name for all of the tasks. It is important to keep updating either the project task and spreadsheet because it's important to know where you are up to otherwise the project will fall apart.
If I was to choose which one I would primarily use I would say that I would use the project stack because it is more appealing to me due the use of colors and it's not so boring to look at.
I think that both of these techniques match the agile manifesto very well.
I think that the spreadsheet matches the user involvement principle well because of the fact that you are able to set each task to different people which will allow you to get everyone else opinion on the development of the project.
Smart Target
A smart target is another effective way of planning things out, in some sense it's quite similar to the project task because it allows for you to identify which tasks need to be prioritized over the others. However it's different because smart targets are more of a daily thing. The way this works is that everyday you must give yourself a smart target depending on what it is that needs to be done, these smart target must be specific, measurable, attainable, relevant and time-based which is also what each letter of the word SMART stands for.
Smart targets are useful because they allow you to have a clear overview on what needs to be prioritized and finished on that specific day. Everyday in lesson my teacher would hand me a sheet of formatted paper and sit with me and look over the work that I currently had then he would write on the paper the task and other things that I had to do in that lesson. This helped because it acted as a guide which helped me to identify the things that I needed to prioritize and get done before the others. The image below is one of the smart targets that my teacher had set for me which outlines the things that I have done and have yet to start.




No comments:
Post a Comment