gamedesignanddev-blog

[gamedesignanddev-blog]

Week 12

So, as this module draws to a close and we put the finishing touches to our game which in all honesty I’m extremely unhappy with. We took it into university too test, changed a few things around and once we got home the game was completely broken without a backup in sight. We added in all of our assets that we got from both the unity asset store as well as making some of them ourselves and assessed what we had created. The first thing that came to mind was utter disappointment in both ourselves and the short comings of other modules this semester that meant we weren’t left with ample time to finish off the game as we would have liked. Overall myself and Aymane did work well as a team but commitments to other modules was our short coming and we didn’t manage our time in the later weeks as well as we could have.

[gamedesignanddev-blog]

Week 11

This week was presentation week, we had an alpha build of the game but unfortunately, we weren’t able to get it to work on the university computers to show alongside out presentation. I feel our presentation went well and we created a really good narrative throughout the PowerPoint and pitched our idea with confidence. We got a couple of difficult questions from our peers mainly about why we didn’t have a game to show on the day, which we felt quite embarrassed that we hadn’t tested on the university computers due to the Easter break and not having a lesson after adding a fair bit too the game which for some reason meant it didn’t work!

Moving onto what I was working on this week… This week I was tasked with getting the jump powerup working. This powerup is very similar to the speed one in the sense that all I did was tweak it so when the powerup was collected I would multiply the current jump power by the powerup version essentially making the jump a couple of time higher than it originally was. I used another bool for this variable as I’ve mentioned before in the jumping pickup post It just makes it a lot easier to turn on and off the powerup when needed. This bool inside of an if statement meant I could set it up to last a period of time and then switch off, we haven’t decided on a specific time length for the powerups but we have tested it with 10 sections and we feel it’s probably what we are going to go with.

This week my teammate Aymane was working on improving the player movement as I point out an issue with the jump not being consistent, he’s having a look into that as its one of the core mechanics of the game and therefore one of the most important as its constantly used throughout gameplay. He also worked some more on adding in the rest of the buttons that are required for our UI.

[gamedesignanddev-blog]

Week 10

This week I began working on the death and pause menus. To start with the death menu, I created a bool variable that I set to false from the start as we obviously don’t want the death menu active from the start otherwise we’d have no game! I then used an else if statement that allowed me to disable to the score from counting up, disable the game from continuing to play by freezing the character controller, and then enabling the GUI death screen that I created so that the player would have options after they fail the game. I have two options in this menu for the moment. One being to replay from the start and another to exit too main menu. The death menu is a very basic part of the GUI and thus didn’t take a lot of time or effort to implement!

Moving onto the pause menu, the pause menu is an interesting one for us as we have a few conflicting ideas on how we should be presenting it. I feel personally we need a countdown timer after un pausing the game to give the player a chance to recover their bearings before continuing their run. To pause the game, I set the control as the escape key, once the escape key was pressed the pause menu (which was also set on a bool) would become active and display to the screen. Once this was set active I also set the time scale too zero, essentially pausing the game. The pause menu then displays three options, the first option is to continue the game, essentially all this does is set the time scale back to 1 and allow the player to continue on as normal. We would however like to add a countdown timer to that in the near future as an additional feature. An option to restart the game is also included, this works exactly the same as the death menu option for retrying. Just sending the player back to their origin a resetting all of the powerups, coins, score and obstacle spawning systems so it would play through like a fresh run.

This week my teammate was working on getting the start menu and the destroy script for the obstacles once they left the screen, the power ups and the coins when you collide with them.

[gamedesignanddev-blog]

Week 9

This week I started work on the GUI for the game; including displaying the coin collection stats, start menu, death menu and the score text. We hoped this would make it feel more like a ‘game’ after adding these features in as at the moment we don’t have any kind of score or menu’s just the core game itself.

As we had already written the code for most of the menus and coin/score stat displays all I needed to do was connect up the pieces. This ended up being fairly straight forward as I had done this before in a previous project, though I do normally stay away from the UI and leave it to someone more imaginative than myself. Firstly, I created a class and called in GUI manager (what else would you call the GUI manager!) and set about bringing everything together in one place so again, since we are in a group project we need too always keep everything neat and tidy as well as everyone being on the same page. I then went on to add in all of the canvas’s that I needed in order to create the menus and added text where I needed to display the score. As most of the code was set up elsewhere I was essentially just calling in scripts to be attached to the canvas buttons and effect the score text. I did however decide to move one script into the GUI manager because we kept getting a bug that we couldn’t seem to work out how to tackle. When we were calling in the coin manager we weren’t able to display anything past the number 10 which was really strange as I had used the same method in the past! The script I moved was the score script, this script essentially just counts the number of time passed by the player and thus is figuratively the ‘score’ for the game. I used two if statements for this section of code, essentially one to turn on the score at the start of the game and one too turn it off at the end when the player died. The score counter also stores the data it receives in player prefabs as at a later date we are looking to implement some sort of leader board if we have time.

[gamedesignanddev-blog]

Week 8

This week I started working on the power ups for the game to start really adding in the features that will make the game both stand out and add an element of fun as well. As we are moving into the vertical slice stage and myself and Aymane are a team of two we will not be taking on any specific roles at this stage, instead we will be meeting and setting tasks for both of us too do throughout the week.

As I mentioned before this week I will be working on the powerups, mostly looking at getting both the jetpack and speed boost implemented. I initially started working on the jetpack powerup early on in the week. The idea behind the jetpack is it gives the player a chance to rest in the middle of their run which can get quite intense as you progress into the level. You pick up the powerup and get propelled up into the air for a period of time (we haven’t decided yet how long we want the power ups too last for).

To spawn the pickups for the powerups I have used a very similar script to the one we have used for obstacle and coin generation with one slight difference. That difference being all of the powerups are stored together in a pool and a random one from the pool will be spawned in front of the player at any time. The powerups will always be spawned a few titles in front of the player so you cannot see them actually spawning in. This gives that desired endless road effect to the game.

All of the code for the jetpack is located in the player controller itself. This is so that we are able to minimise the amount of scripts we are using and keep everything organised. As it’s a group project and we are sharing it via GitHub and using Source Tree for version control it is of paramount importance that we always know where to look for different pieces of code. Firstly, I set the variables for both the flying speed and also the flying height of the player, these will be the basis for our code and the two variables that control how the jetpack will act in game. Secondly, I added in an if statement so once the jetpack pickup has been collected it can be set to activate. Essentially in this if statement we have two bools that set ‘running’ too false and ‘flying’ too active. This allows us to more easily switch off the jetpack after the pickup has expired. Other than that, the jetpack is a relatively simple pickup with the height and speed of the playing being temporarily changed to fly high above the endless track! Naturally we cannot use the same camera for this powerup as the height and the angle of the player will change as they are flying through the sky. I have rectified this issue by including a ‘flycam’ in the if statement the fly cam is essentially just a second camera that the shot will change too once the pickup has been activated, this camera is adjusted at a different angle and height to the normal one, giving the player a good view of the map while they are soaring through the sky!

The next power up I implemented this week as the speed boost powerup. The speed boost powerup was one of the easiest to implement as I was able to just change the speed of the player for a short amount of time while the pickup was active. I did this by multiplying the current running speed by a new variable which would be the speed boost variable. This piece of code would also be attached to the player control for the same reasons as I mentioned before. An if statement was also what I used for this in the same fashion as the jetpack powerup as it allows us to turn it on and off in a more efficient way without encountering any issues. I feel like the decision to make the code for both of these powerups very similar will help with explaining it to my teammate and help with our productivity and work flow as well as being a robust part of our game.

My teammate this week was working on the obstacle generation and improving that as we had encountered some difficulties with objecting pooling and spawning consistently. Check back next week for another update!

[gamedesignanddev-blog]

Week 7 (Update)

I was unable to post my blogs due to never ending buffer bar at the top. I had this issue for two weeks on my laptop whist I was away from home and I’ve only just been able to upload them on return to my desktop. Apologies.

[gamedesignanddev-blog]

Game Design and Dev - Week 7

 This week myself and Aymane decided that we really needed to start developing the art style for our game. And with the removal of James from the group we were able to agree on a lot more of the art than before and we got started with the development from mood boards too concept sketches and finally creating the assets themselves in either Maya or C4D. We also completely updated the trello board to reflect exactly what we want to do going forward as a now team of two. As we now don’t have a 3rd team member nor artists working with us myself and Aymane will be taking on all of the roles as a collective until the end of this project. This will allow us both to contribute massively to all aspects of the game and not leave a bulk of the work up to only one person. Attached below are the screen shots from the work we completed this week. Next week we will be looking to finalize them and implement them into a working version of the game.

MOOD BOARDS

CONCEPT SKETCHES

 CONCEPT ASSETS

 UPDATED TRELLO BOARD

[gamedesignanddev-blog]

Game Design and Dev - Week 6 (Update)

 Towards the end of this week we were informed that the module leaders would be removing James from the group, this was due to his lack of contribution towards the project. This was noticed by them in week 3/4 and monitored up until now with the decision ultimately that he wasn’t contributing enough so needed to be removed to allow myself and Aymane to keep working on the game we have contributed the most towards since its inception. This decision was both fortunate and unfortunate because we are now a team of artists down as well as being a man down on the programming end as well but overall it was music to our ears as it now frees us up to revert back to our original art style and ideas that myself and Aymane had agreed on before James joined the group in week 2/3. Moving into week 7 we hope that when the project is graded our group; now missing 3 artists and now also one team member is taken into serious consideration when deciding on the grading.

[gamedesignanddev-blog]

Game Design and Dev - Week 6

 This week was the final showcase of our game in the prototyping stage as we will now be moving into working on the vertical slice. That being said we had to present our work in the practical session this week and we received some feedback. The feedback we received was both constructive and positive. Essentially we were told that our game is going down the right path and looks good at this stage, however there were a few issues pointed out to us. We were aware of them beforehand but with this being the prototyping stage different things are supposed to be attempted so we wanted an opinion before making changes. The issues that were outlined were the fact the game seems to speed up too quickly making it hard for the player to attempt a high score, and also the lack of variety in terms of different obstacles for the player to avoid in game. Both of these things we will address moving forward and ensure this isn’t a complaint in the final vertical slice.

 This week my primary role was to lead the team, this was quite difficult and as a collective we didn’t really get much done in the way of progress towards the third prototype as we showed it so early in the week. This was due to the fact myself and Aymane would be away for the remainder of the week with family matters. Next week we are hoping to work on the art style now we have many of the core mechanics implemented as unlike other groups we are without a team of artists to do it for us!

[gamedesignanddev-blog]

Game Design and Dev - Week 4 & 5

 Hello and welcome back to my blog, this week I’m going to be blogging both week 4 and week 5 as a combined post. This is due to some personal circumstances that meant I was away from my computer for a substantial amount of time over the course of these two weeks.

 These two weeks were the last two in which we worked on the third and final prototype. This prototype should incorporate the basic idea and most of the mechanics that will be included within the vertical slice and use a combination of the mechanics from the previous two prototypes. The first thing I want to mention about the third and final prototype is that it was made by myself and Aymane with no input from the third team member who didn’t follow through with the work that had been agreed on and set for him within these two weeks. With that being said myself and Aymane agreed on what we mostly needed to add to the third the third prototype, those being; obstacles spawning in front of the player, attempting to get power ups working, starting to create the user interface, working on the obstacle spawning system, player score system, and saving an achieved score to a leader board. We also agreed that all of the features that we had implemented into the second prototype would be moved over to this third and final one and if anything we would be making improvements to what we already had rather than completely removing anything. The only thing we did decide to remove was the camera controller that James added last week, this was due to the fact the script he used was directly copied from the unity asset store and wasn’t functioning in the way we had discussed anyway. The main challenges we encountered during these two weeks were actually myself and Aymane picking up the slack and not being able to get everything we wanted implement because of this. My role for these two weeks was really to be the lead programmer and I feel like I did a good job in the role, myself and Aymane got a lot done for the prototype considering we were basically a two-man team and I feel we have managed to close the gap on the other teams in terms of where the development of the core mechanics are at this stage.

 As mentioned above these two weeks were strenuous for personal reasons and because we had a team member who wasn’t really contributing as they should have been. This basically amounted to myself and Aymane not really taking on set roles and mostly chopping and changing to try and get as much as we could have done in the given time. With that being said, my person contributions this week started with working on spawning random obstacles in front of the player across the x axis (sliding obstacles not currently being implemented until we have the animation completed for the sliding motion). The spawning obstacles script uses obstacle prefabs that are spawned inside of the same lanes as the player is able to run in and the range in which they are spawned is controlled and set by the ‘Random.Range’ function. A screenshot of the main body of code can be seen below as well as screen shots of the temporary assets we are using for obstacles during this final prototyping stage.

 I also worked on the player scoring system this week which is incorporated into the Player motor script, essentially just adding what we had already planned too from the start. Essentially just allowing the players score to increase as the time increases when the player is set to active, the further the player gets, the higher the score goes. For the actual score script itself I just basically set the score to activate (increase) and deactivate (stop increasing) when the player starts the game and dies in that order. This is then called into the player motor script which is used to drive the player forwards and is linked as that script lets the score script know when the player is active/ not active thus telling it when to increase the score and stop increasing the score. Screenshots of the code can be seen below.

 The final thing I worked on for the final prototype was the speed of the player increasing as the time played increased. The only thing I really did to change this was manipulate the running speed variable using Mathf.Lerp. This allowed me to add a ‘speed increase’ variable that would be changeable in the editor. This then allowed the players speed to increase over time using the Time.DeltaTime function. We will be tweaking this feature as it seems to speed up extremely quickly regardless of the input used in the editor. A screenshot of the code used for this is inserted below.

 I think in these two weeks I have contributed quite a lot to the team considering I was away from my main computer and working off of a laptop for the majority of the time. I was able to get a sizable amount of programming done as that’s all I was really able to do with the equipment I had available. Next week I hope to be contributing more towards the team in terms of asset building for our vertical slice and start looking at implementing some of the power up functions that we’ve tested but not fully been able to implement into the game yet as well as looking into adding the slide function as that is the last fundamental part of the character’s movement that we are yet to add.

 This week the team wasn’t really a ‘team’ more like a duo (myself and Aymane) this was because any task that was set for James wasn’t completed nor were we made aware he was unable to complete them in ample time. Myself and Aymane however worked really well together, helping one another write the code and come up with ideas for the assets that we would be adding into our final vertical slice. We sponged off of one another’s knowledge of different aspects of building games in terms of the coding, for example I had already a good idea of how to do the object spawning system so I contributed and helped with that whereas Aymane had a really good idea of how to do the platform generation and creating a few of the assets so we delegated jobs well based on our individual skill sets. We communicated constantly within the WhatsApp group we have set up for the team and also Skype called one another from time to time if we got stuck or needed help/ advice on an aspect of the prototype we were working on. We essentially overcame the lack of a third team member by allowing it to serve as motivation to get more done ourselves in the time given which seemed to help us be more productive and essentially get a similar amount of work done had we had a third team member contributing anyway. I would say the overall performance of the team was good if that was excluding James as he contributed next to nothing in these two weeks and moving forwards I hope he’s able to contribute more towards the vertical slice so we can make a game that entertaining and enjoyable to play.

 To summarize these two weeks, I feel like as a collective we could have got more done but unforeseen circumstances prevented me from contributing to my full ability and we also had a completely missing team member. Moving forwards I hope we can pull together and catch the rest of the groups up in the coming weeks by implementing all of the ideas we have and starting to polish off a playable version of the game by week 8/9. Next week we will be pitching this final prototype and getting feedback from Garry which should be extremely helpful moving forwards. Thanks for reading, see you next week!

[gamedesignanddev-blog]

Game Design and Dev - Week 3

Hi welcome back to my blog, this week we were predominantly working on the second prototype so it would be ready to present at the end of the week. This meant again all of us splitting off and working individually on tasks we had all set at the start of the week. This week we initially did set the roles as myself programmer, Aymane artist and James the project lead. However as the week drew on we all contributed to the prototype's mechanics more than working on the artwork as we have decided to leave that until a later date when we are done with the initial prototyping. 

Starting off on the second prototype we essentially kept all of the features we implemented from the first one and improved on them/ added what we would eventually use in the final vertical slice of the game. Those features being platform generation based on the players potion and basic lateral movement using the directional keys. With that being said we won't be removing any of the features that we implemented into our first prototype but essentially just adding and refining the basic movement and tile generation we will use in the final vertical slice. The main reason for the lack of development from prototype one moving into the second one was down to the fact we didn't have a third team member when we initially came up with the idea so we created a very basic prototype one so we could easily change and not waste any time implementing the final ideas. The challenges we faced when developing the second prototype were making the three lane system work, creating the platforms so that there wouldn't be any gaps in them behind the player that the camera could see once they were ready to be deleted and making the platforms spawn fast enough in front of the player. These issues were mainly just a learning curve as we were getting used to the core mechanics that an endless runner requires. I personally contributed to the first prototype by creating the movement script and continued the development on that into the second prototype. For the second prototype I changed the basic lateral moment into a three lane system that we had decided would be best to go with on this project and also added a jump function that could only be activated when the player was touching the ground. We all assigned roles in the practical for week 3 at the end of week 2 when we first met up as a complete team for the first time, the assigned roles were, myself as programmer, James as the project lead and Aymane as the artist. We didn't specifically stick to these roles this week as once we had the okay given to us from James who just joined myself and Aymane began implementing the features we had initially wanted too.

This week my responsibility was to be the main programmer as i mentioned before, this role meant that i continued on from where i left off in week two, developing the movement script. This week I added a three lane movement system, this meant that when the user presses the left directional key and the right directional key they would move into either lane 1 or -1 respectively, with the middle lane being lane 0. This was quite hard to implement at first but with a few google searches and some research I managed to get it working in a good amount of time. The second feature was adding the jump, this was easy to implement for me as I had created an endless runner for a project last year and essentially used the same idea in my code for this project. The jump function includes an 'if' statement that allows the game engine to know when the player is touching the ground and allows the player to jump if the 'isGrounded' Boolean came back as being true. Screen shots of the code are included below and last week I included the old moment script for a comparison. I hope to add a function that allows the player to slide under objects as well as jump higher the longer the space bar is held down. I am also hoping that it will be possible to make the lane switching smoother later on down the line in the projects development. To reflect and evaluate my contribution this week I believe that the movement script has been upgraded significantly and wont require many if any changes moving into the vertical slice, only additional things being added will be the main focus for us from this point. I do feel like all of these features could have been included in the first prototype but as I mentioned before we were a team that formed in the second week so we needed to ensure the third team member wanted to go the same direction with the project as the two of us that came up with the initial idea. The code that I wrote this week was tested by myself and both of my teammates for basic things in the unity editor. These included ensuring that the three lane system was robust and allowed for the player to move between lanes seamlessly, making sure that the jump function worked as desired with the main focus around ensuring the 'isGrounded' function working properly so the user was only able to jump when grounded. My secondary role this week was to project lead, I contributed to the team on this front by ensuring that everyone was staying on task and checking their progress so we could have the final prototype two together at the earliest convenience for everyone in the team. This was done using the WhatsApp group that I set up for team communication during week 2. I feel I could have done more in this secondary role by interacting more with my team and offering my help to my teammates, I will work on this and make sure I implement that in week 4.

Moving on to my other team members contributions and roles this week. As I mentioned before we assigned the roles as myself- programmer, Aymane- Art and James- Project lead but we didn't really stick to those roles this week as we already had an idea of what we would be doing for the project and that was given the OK by our late arriving third team member. Myself and Aymane worked really well together this week, collaborating on the coding of the core mechanics of the game. I was working on the movement script and he was working on the tile generation and deleting the tiles behind the player for the second prototype. James told us that he would look into the art side of things and come up with some concepts for the art that we will work on after we have finished prototyping our ideas. The difficulties that we ran into this week as a team were defiantly people not responding to messages and Skype calls in ample time. This was frustrating as it meant we weren't always able to communicate between us and some ideas may have gone unfinished due to the uncertainty that the rest of the team would give it the OK. This miss communication was mainly down to us all being busy at different points of the day throughout the week. We did however manage to overcome these issues towards the end of the week by ensuring that no matter what we were doing we would make it a priority to reply to messages as soon as we received them. Towards the end of the week we even sat down in a Skype call and managed to collaborate as a team when placing together the final prototype two ready to be shown in the practical session at the end of the week. To sum up the overall performance of the team I would say we did a good job considering we had only just come together as a team in the previous week and still had to finalize ideas with our new team member which was the main reason for the slow progress at this stage.

The presentation of the second prototype was revived exactly how we had imagined it. We were told that what we had done was about a week less than the rest of the groups, we had expected this response due to the fact we had essentially had a week less as a team. We were mainly going over the idea and working on a Trello board to keep track of all of our ideas rather than actually getting down to the programming we needed to be doing. We will catch up in the coming weeks and our prototype three should be fairly robust and looking along the lines of what our vertical slice will be like. Moving into week 4 we expect to have the movement and jump refined a little as well as all of us learning about object pooling so we are able to implement that into our project. With those being the main features we are looking to add we also want to start working on obstacles and jumping gaps for the player to have to navigate. This will be a secondary focus however with concept art and ideas for how our game is going to look being the main focus for the coming week. The roles we will be undertaking in week 4 will be myself as the artist, Aymane as the project lead and James as the lead programmer so he can get a good understanding for the code we have already written and add his own ideas into it.

Lastly, next week I hope to upload screen shots and talk about the moodboards that we create for the project. This will include everything from the characters artwork, to the scenery and the menus. See you next week!

[gamedesignanddev-blog]

Game Design and Dev - Week 2

Hi, Welcome back to my blog. Heading into the second week of the module I encountered some unfortunate circumstances regarding my family, that’s the reason for this and the 3rd week blog posts being slightly delayed in their upload times. Everything should now be back to normal and regular blog post can become the norm! To start off this blog post I will briefly recap the lecture from this week.

In the lecture this week we learnt about product pipeline and project management. Firstly, we learnt about a project pipeline, this being described as the concept phase at the beginning of a project where an idea is explored and elaborated on. We looked at things that could help us with this process including moodboards, story boarding and general concept sketching. For more of the structure/ coding side of the pre-production we also looked at things such as flow diagrams and flow charts. We then went ahead and looked at project management, in this presentation we learnt about different methodologies of splitting work into phases so we can better plan out and spread our work load across everything that needs to be completed in order for us to be successful in this module. An example of this would be the Waterfall Methodology, in this you look the requirements, design, implementation and verification in that order and follow that throughout the project to hopefully keep everything on task and help towards a successful project. We then looked at Agile, this methodology looks at an idea of working in a circle until you end up with a polished idea and then you move forward with it. The circle spans from generating ideas, formalizing them, testing them, evaluating them and then deciding if the process is needed again to further refine the idea or not. We then looked at breaking down the entire workload into chunks of time, we were given a few examples of how to do this in the lecture. Finally we looked at risk management, which basically allows us to see what parts we could potentially not do without and which we may be able to get away with leaving if we end up with no time remaining. Overall this lecture helped out team a lot with ideas of how to plan more efficiently and use our time wisely.

Moving into the work we put into the project this week. At the start of the week we set each other tasks and agreed on what we would be working on (at this current moment we still only had two team members). My task would be to work on the movement script for the game, getting a basic movement for the moment as we can finalize our ideas without a full team. My teammate (Aymane) job was to work on the tile generation script. This in turn would add the mechanics we are looking for in our first prototype, as we have been hindered in comparison to other teams up until this point due to the lack of both artists and a 3rd team member we will be trying to complete as much as possible after adding the 3rd team member and moving into week 3. My part of the project this week was to be the main programmer and work on making and refining the movement script. This came relatively easy to me as I had already worked on an endless runner during the summer and used some of the code I had already spent a few months learning before. As we need to show our progression between the different prototypes I went with a really basic movement script at this moment in time. It just simply moves forwards and the user can use the arrow keys on their keyboard to move the player from side to side. I used a character controller to attach the movement to the player object in game. I have attached a commented screenshot of the code that is being used at this time for the movement. I also started playing around with the jumping for the second prototype as you can see by the 'if' statement at the top but this code is currently not being used at all.

To round up week two, we completed the first prototype and showed Garry in the practical session, he was happy with the progress that we had made considering all of the issues we had so far encountered in this module. We also added our 3rd team member and I assigned everyone job roles and tasks for the upcoming week and also what we would need to work on for the 3rd prototype and presentation that comes along with it. I was placed as project lead for the upcoming week, and thus assigned our new member James the main programmer role so he could take a look at some of the code we had already written. Aymane was assigned the designers role which his main aim to come up with some ideas for an art style for our game that fits with the theme. Now we were a complete team we sat down and discussed what direction we would be taking the project. We all agreed on the idea of a tribal character running away from a lava flow was the idea we would be going for and subsequently we started creating a trello board and moodboards based around this idea in the practical session. Moving into week three things are looking good and I will be pleased to showcase not only the code and the second prototype but also the planning that we put in behind the scene's using some of the techniques and methods from the lecture!

[gamedesignanddev-blog]

Game Design and Dev - Week 1

Hello and Welcome to my blog. The purpose of this blog is to document the development of an endless runner game created by myself and two other teammates for a module at University. To introduce this blog, I just want to give a little bit of background on what I understand we are going to be tasked with doing over the course of this module. In the first lecture, we were taken through a few slides outlining what was expected of us and the task that we needed to complete. Within this presentation there were three main points to take away, the first being to analyse a game genre to understand its underlying properties and interactions with endless runners being the genre we would be analyzing in this module. Secondly, we would be assessing the benefits of a disciplined product development and differentiation of roles in the video games industry; with us being split into teams of three these roles were broken down in project manager, programmer, and designer for the assets etc. Lastly, linked in with the second main point we would need to adopt one of these roles in the group while working towards creating a vertical slice of an endless runner video game.

The first stage of the development towards the vertical slice is to create a few prototypes in the first couple of weeks so we can get a feel for the direction we are wanting to go with the project. Alongside this as we get more an idea for what we will be trying to achieve we will being using programs such as Trello to organise all our ideas, source tree to ensure version control and GitHub so all the team members can log what they have contributed and have access to the code for the project whenever they need it.

The first practical followed the lecture and we were put into groups, due to the numbers in the class I was placed into a group of two instead of three. This was purely down to numbers in the class that day and we were ensured that we would be able to add a third member to the team the following week. As we didn’t have a full team for the first practical session we couldn’t work with any of the teams of artists on this project as they were all assigned teams on that first day.

Moving onto the expectations of next week, we were told we would need a working prototype of our game with at least one of the mechanic ideas we had implemented. Myself and my teammate set out doing this and developed a working prototype within hours which I will talk more about in next week’s blog.

Lastly, I just wanted to mention that this blog post was written in a word document at the end of the first week but is only being uploaded now as we weren’t told what blogging platform we would be using until a later date. Now that’s been cleared up I am looking forward to providing regular updates to this blog regarding the development of the game we are working on!