Jump to content
Site Stability Read more... ×
  • Advertisement
  • entries
    9
  • comments
    6
  • views
    2096

About this blog

An insight into the game development process of the games title "its a blob"

Entries in this blog

In the Moment: CandySort and CampFire

In the Moment: CandySort and CampFire   In the Moment is our first project for the trimester. For it we had to create a ‘Mindful experience’ for the Oculus Rift & Go.
Some of the requirements for this were: The experience had to have a stable experience on both devices (GO:60FPS, Rift:90FPS) The Rift experience had to include extra functionality. The project had a project lead and everyone else was contracted to the project
  Two projects leads were chosen and thus two separate projects were taken on, the ideas behind these being:

CandySort:
CandySort is a game about creating different sorts of candies in a lab, these can be fed to a little critter or can be placed in beakers and sorted. Wanted a colourful happy vibe.

CampFire:
CampFire is an experience about sitting around a campfire at night, you can interact with elements of your surroundings such as the night sky and fire and roast marshmallows on a stick. Wanted a peaceful vibe.
As a programmer i was contracted to both of the projects, however i did do some designing myself to improve interaction/ feel. What went right with both projects
  1.   Initial Design
Both of the projects had a clear idea and direction from the start, this meant that assets lists, systems and tasks could all be created and allocated quickly. Props have to be given to the project leaders for this great start and this was especially useful for getting in Assets early.
  2.   Assets
As mentioned above because there was a clear design aesthetic choice for both projects, this meant that the required visual assets were very quickly sought or modelled by the designers and thus resulting in the bulk of the assets (around 90% of them) being ready and implemented in the first week.

This was extremely useful for deciding how things would look or act in the designed space and overall was a great effort.   3.   UX and Systems UX/UI
Being VR it gave us the ability to make more interactive and interesting UI that could be integrated into the scene.
This included: The design board in Candy Sort

The fire in CampFire

Both of these came out looking great and added that extra layer to the game. Systems/Mechanics
Because ideas and mechanics were clearly stated early it gave us a decent amount of time to work with them and we were able to create some really interesting mechanics in both experiences some of my favourites include:
Marshmallow on stick

Rotating the sky

Candy Fuser

Bunny What went wrong with both projects
  1.   Accessibility to hardware
This was a pretty big issue we had and it came down to a few separate reasons: No one owned these devices (i’m trying to scrape the money together but full time uni student) Our university has one Rift Our university would not allow us to take the devices off campus to develop on Most computers on campus did not have software for these devices & required IT to install them
   I was lucky enough to borrow a Go off one of the teachers so i could develop at home but this really meant that i was solely doing about 80% programming and development at home. Anything i made for the Rift as well couldn't be tested until class time either.
  Luckily there wasn’t too much differences between the devices, so i could prototype systems at home and then we just used class time to test and bug fix.   2.   Communication
There was multiple forms of failed communication in this project:
  Use of Repo
For both projects there was mismanagement of the repo, separate branches were created in which to develop features however were not used and everything was pushed to Masters.
This resulted in one project destroying the master branch and then using a different one as a main, ignoring master altogether.
  Understanding of hardware UI, model scale and some scripts were designed without understanding how or if it would operate in a virtual setting.
This i believe is less of the fault of the designers and more of the lack of accessibility to the hardware, seeing and playing with how it operates would give them a better understanding.
  Combining of systems Some parts of the builds were created in separate scenes but did not take into account how they would be implemented and limitations of the main scene. This caused issues in both the combination of these components and required in some cases extra time to redesign

  3.   Merging of Systems
As mentioned above in communication, the merging of Assets or systems that hadn’t taken into the account of limitations caused some issues. This was mostly a communication issue both in the sense of them communicating what they were doing and us communicating the limitations.
  What can I learn from this?
  1.   Accessibility to hardware
First off, assess accessibility to hardware and make decisions based off that.
If there is limited access to hardware allocate time to do design /prototyping without the devices and testing when you do have time with the hardware.
Also allocation of the device between individuals so that work can be split up more evenly and reduce the singular workload.   2.   Communication
I think the best thing to do here is to introduce early policies and procedures for the project. I understand that this was a small project but even so there should be a set of guidelines that each developer should be aware of in regards to how they use or display work.
Having a clear set of policies and procedures that everyone will understand will mean that things should move along quickly or at the very least smoothly.  
  3.   Merging of Systems
I think this is the same solution as above, having guideline or procedures that developers should be able to refer to or have a previous understanding of what the expectations are will make for a much smoother project.
  Conclusion Overall i’m very happy with the outcome of these projects, everyone worked really hard in an area that they are unfamiliar with great results. Personally VR development is one of my favourite areas (i am a VR developer intern so i may be bias) and i can't wait to work with this more on a personal level in the future.
  Thanks for reading!   Development stats My Twitter: https://twitter.com/Walkiessss Developers: Ben Walker, Brynn Clayton, Rebecka Jansson, Damien Steger, Dan aykroyd, Jamie Bolling, Robert D’antoni Links to Games:  
https://slemhosta.itch.io/candysort 
https://robert-dantoni.itch.io/camp-fire-vr Length of development: 4 weeks Development tools: Unity, visual studio, audacity, blender, photoshop  

Ben Walker

Ben Walker

Home: Shellfish

Home: Shellfish   As part of our final project for Studio 2, we had to create a game based on one thing.   Home.   Home Project This was the second Home Project I was coding for, my creative input in this project was less than Coming and Going. Shellfish is about how it is okay to put your own well-being first, and as a result of that cut off any relationships that do more harm than good. Even if they happen to be family or your best friend.   What went right 1.   Art Design I can take no credit for this, the designer for this project is incredibly talented (at least in my eyes) at creating unique backgrounds and characters. Very quickly all of these was designed and implemented into the project.   2.   Work Mini Game The designer wanted a monotonous work mini game, in which the player had to write out paper work on the computer to earn money. After elaborating on design documents and taking notes of what was needed, I was able to make a system which turned out to be pretty fun. I think part of the charm once again was the great accompanying visual aid.      3.   Pivot In the last week the game took a design pivot, this didn’t alter any of the existing systems that were built but it did make more sense from a goal point of view. Previously a house was filled with items that you purchased, now you work to build a Rocket ship to take you away from your temporary home. Personally, I think this turned out much better, I really am invested in Goldie going to the moon   4.   Audio The audio in this project was well sourced and came together quickly, the designer also made a bunch of their own, including music and sound effects. It adds a certain character to the game, which I think is designer personality in game form, which is something to celebrate.
  What went wrong 1.   Planning As I mentioned previously, my involvement in this project was more of a when I’m needed basis. Which doesn’t mean I wasn’t available, it’s more like, information was trickled down to me over time about what was needed at that exact point. This made planning for this project difficult for me, especially as the designer was also doing some coding bits and pieces in-between points of communication. This wasn’t mine finest work from a coding standard point of view.   2.   Communication Communication in work hours was fine, we would both actively seek each other if we wanted something or needed answers, which was great. However outside of class time, getting a hold of them was an issue which definitely slowed down progress.   What can I learn from this? 1.   Planning While information was sometimes limited, I could have definitely planned out my systems better, especially when modifications were needed for other functionality. Creating solid systems could avoid things becoming hacky in the end.   2.   Communication I’m not really sure what I can learn here, as I mentioned before in class it was fine, outside I made my best efforts to communicate and update the designer what I was doing but it felt like a one-way street. I guess I could have communicated this better in class and come to an agreement or understanding of why this was.   Conclusion This project has had its up and downs, but I certainly think its in a great spot now, the game is a delight. I’m pretty disappointed in my coding standards on this project but I’m taking this as a learning experience and strive to do better. Look forward to working with them again.   Thanks for reading!       Development stats ·        Developers: Jamison Bolling, Ben Walker ·        Link to Game: https://slemhosta.itch.io/shellfish ·        Length of development: 4 weeks ·        Development tools: Unity, visual studio, audacity, 3ds max,  

Ben Walker

Ben Walker

Home: Coming and Going

Home: Coming and Going   As part of our final project for Studio 2, we had to create a game based on one thing.   Home. Home Project So we thought about what home meant to us all individually, in the end we came up with the concept that home can be many places, its about what’s comfortable to us. Home could be family, home could be a bed after a long day. We decided to focus on a family event and how it’s good to be back home but over time you feel less comfortable because its not your home anymore. We wanted to merge 3D environment and 2D art to help create a more pleasing environment, as 3D models can sometimes come across as quite alien by themselves and have no references to actual people being there, leaving that open allows the player to make their own assumptions or put themselves into that position.     What went right 1.   Initial Design Our design process was fast, within two days we had the feel for the game and some of the mini game mechanics planned out. All design documents were started soon after and by the end of the week we had already made a start on systems and building the game. This was possible due to a few reasons; ·   We were all passionate about the project ·   We clearly defined roles and tasks early ·   We communicated often and effectively Considering our time to develop was short, managing our time and creating things quickly was important. It meant we could then see our ideas play out and update anything that didn’t seem like it fit. 2.   Mini games The mini games were planned early as well as the art for them, this gave us time to effectively make the main mechanics and also a large amount of time to polish them. Only the drinking games were designed later, and they went through a couple of stages before making a final decision on what they should look like. Here are some examples of the mini games: Drinking: Dishes: Dinner:

3.   Core systems design As mentioned previously, we had great communication about the things we needed. Either things were designed as a group, or the designers would brainstorm ideas externally. I would sit down with both of them later and take a large number of notes of all the functionality and systems that I would need to make. The key here was clarity, sure I can read design documents all day, but somethings can be missed or lost in translation in a document. It’s important to work as closely as you can to make sure things are as intended. This resulted in solid modular main systems that could be used easily and effectively. //activity
  What went wrong 1.   Complexity This came in two forms: System Complexity: After a couple of play tests, further functionality and new systems were wanted. As much as I tried to plan in advance all of the systems, there was things that I could never anticipate. I tried to separate the systems as much as possible but sometimes things had to get a little messy. Saying that though, none of the issues were massive and most just took a little problem solving. The largest issue we had was a Unity bug, which previously worked and then just decided not to. Project Complexity: We had a LOT of assets in this project which as things started piling up could become quite confusing. Objects were separated into their own sections but some of these sections had multiple sub sections of objects depending on what day it was in game and if it was night or not.   2.   Merging of games One the designers implemented one of their previous games into the game, by copy and pasting all of it in...I think it goes without saying but don’t do this. Review and remove all the unnecessary scripts and assets first. It did turn out looking pretty good, it just took a bit to work out all of the kinks.
3.   Collaboration with audio Audio was always going to be a major part of this project, as we don’t have physical people in the world, we have to tell stories through the environment. Unfortunately, none of the audio students wanted to collaborate with the home projects which was disappointing. This just meant we had to source our own audio.   What can I learn from this? 1.   Complexity This is kind of an inevitability, projects will become large and sometimes complex. The best we can do is plan out all systems to be modular and to cut interactions down to less systems. Also organising everything logically and according to a standard decided by the team. Its important everyone is on the same page.     2.   Merging of Games If I have control over this, review and remove all the unnecessary scripts and assets first before putting it into the project otherwise making sure that its understood that large changes need to be discussed before being implemented.   3.   Collaboration with audio This is an unfortunate fact of life, sometimes things don’t go to plan. I think the best steps we can take to avoid this again is to network more with audio students, either talking to this particular cohort that doesn’t want to collaborate with the projects or making new friends in different cohorts.     Conclusion This project has been great, overall, I think Home really portrays the feeling and message we wanted, and the project was well managed and delivered on time. Another reason this has been so great is in part to do with the people I have been working with. Working with talented, passionate, like minded people, makes for easy work and a great working environment. 10/10 would work with them again.     Thanks for reading!     Development stats ·        Developers: Ben Walker, Brynn Clayton, Rebecka Jansson ·        Link to Game:  https://mercworm.itch.io/coming-and-going ·        Length of development: 4 weeks ·        Development tools: Unity, visual studio, audacity, 3ds max,  

Ben Walker

Ben Walker

Post Mortem: CreatureFeature

Creature Feature   As part of our first project for Studio 2, we had to create a creature-based AI. Conditions for this being: Must be able to path find within the world. The pathfinding algorithms must be implemented individually. Built in pathfinding or third-party solutions are not permitted to be used. A procedurally generated map or terrain for the AI operate in. Have individual behaviours where the individual behaviours attempt to achieve some goal (eg. collecting food). Have a higher level AI that decides which behaviours to run.   My Creature Feature Instead of a creature, I decided to use Taxi's in a procedurally generated city fighting over fares. Each taxi will have their own set of Trust logic and Behaviour logic systems with which they will be able to decide on whether they should help their fellow AI or not.     What went right 1.   Design / planning process From the beginning it was important to me to layout everything in a manner I could visualise. This started with just writing down and setting the goals that needed to be achieved over the life time of the project: Node based Movement and generation Procedurally generated cities using Perlin Noise A* pathfinding logic Navigation system Behaviour Logic Trust Logic Then from here working out which I needed to do first and start writing and planning the technical design. Even from early on I was creating images of the process I wanted to achieve, this is important for two reasons; 1: Visualising helps you think about how you want the thing to look and operate 2: Making these in a step by step process helps you find all the bits needed and possible issues early   Remembering as well that none of this is concrete and mostly likely your first plan will be your worst plan. Don’t feel tied to your first process. This was one of the step processes I made for the map generation
  The process I used here changed at least three times (and honestly even this process has changed slightly since release)   2.   A* creation This was my first attempt at A*, it’s not perfect but I’m pretty without it came out. Once again (going to sound like a broken record here) I think I owe the success due to planning. By laying out the process in which you want to complete things it becomes easier to work out how that needs to be done. This was the basis I worked A* off:   Need a list of all the node to process (Open list) ·         If the node has been processed (closed) ·         The cost to a node (G cost) and the estimated cost to a node (H cost) ·         The initial G cost for all nodes should be set to the max possible value The starting nod is added to the open list, its G cost is set to 0 and its H cost is calculated
While we still have nodes in the open list: ·         Remove the node with the lowest total cost (F) from the open list. This is the current node ·         If the current node is our destination, then exit ·         Mark the current node as closed ·         Loop over all of the neighbours for the current node                           Calculate the total cost (G) to the neighbour from the current node                          In the new G cost is less than the stored G cost and the node is not closed                                               Set the g cost of the neighbour node to the newly calculated g cost                                               If the neighbour is not in the open list, then add it to the open list                                          Set the current node as the parent of the neighbour   By following this process and taking time to plan out the technical design before touching code made for a much smoother project. This was the results of me path finding from one seed point to another.   
  3.   Map generation   As I mentioned before this went through multiple different design processes to try a create the best results and it showed. The first method used to create the maps and link the roads was actually the gif above. With each seed point connecting itself to every other seed point. However, this came out looking really messy and cluttered. So, after a conversation with a teacher I trailed a new process in which it was all split into sections (kind of like a city grid).
This came out looking pretty good and is the basis for my generation at the moment from here I made tweaks here and there and add new tiles to create more variation.
  4.   UI Considering this was a project exclusively based on coding this wasn’t exactly essential, but I feel like it having these “Creature comforts” (see what I did there?) made the sim feel a lot better while still being interactable.
The only issue that arose from this was involved with the mathematics for  generating the live table data. Which honestly wasn’t that big of a deal. Overall, I feel like the project came out looking the way I intended.     5.   Json Implementation
This was a core component of the project having state that could be saved out and loaded. Considering I’ve used json in the past it wasn’t much time to get this up and running, I just had to work out a few things with regenerating the map.
There were no issues here and it works great, it surprised me how fast it can write 50,000 lines to memory.   What went wrong 1.   Rewriting logic system
This was an interesting case, so previously I had divided up the logic of each taxi into two sections, the behaviour logic and the trust logic. The behaviour logic taking the grunt of the workload by being a giant state machine.
However because I was far ahead of schedule, my teacher suggested I tested myself and rewrite it to a different approach. That approach being GOAP (Goal Oriented Action Planning). I struggled quite a bit with this, new versions were vastly two complicated for my needs and older versions (such as Tyrion) were extremely hard to find information on (can you guess why with a name like that).
With a lack of understanding, I tried implementing a far more complicated system and ended up buggering myself spending much longer than I needed on this.      
     With some planning help from my teacher though and some visualisation I created, I was able to finish it and I have to say its pretty sweet seeing in action.      2.   Debugging logic Oh boy, debugging AI logic, this was and still is (with some current logic bugs I have) a nightmare to deal with. Finding something that only happens at very ambiguous times and only happens on a Sunday (ok, I’m joking about that part) can be super difficult. Breaking up the logic into separate goals and actions for GOAP did help narrow down that process but I spent far too many hours attaching visual studio in debug mode to very little avail.    What can I learn from this? 1.   Rewriting logic system Using expandable and modular systems like GOAP are a great way to improve the quality of a project but it is important before making a start on it to know how complicated of a system is required for your needs and then planning the logic from there.   2.   Debugging logic A couple of things here; ·         Create separate and well defined systems:           So that it is easier to read and track ·         Take breaks from debugging:            Go outside gets some air and give yourself some time to mull things over. This can save a lot of stress in the end ·         Ask for help / get a pair of fresh eyes:           Similar to the above, you can be so focused on a particular thing that I can be hard to narrow something down. Getting another opinion can be really useful     Conclusion For the most part I am super happy with how this project turned out, it has been one of my favourites so far during my time at SAE. Not only have a learned interesting and new practice methods but I also had fun while doing it and that’s the best you can really ask for.       Thanks for reading!         Development stats ·        Developer: Ben Walker ·        Link to project blog: https://blog248708493.wordpress.com/2018/09/27/studio-2-creature-feature/ ·        Link to Sim: https://walkies3.itch.io/creaturefeaturetaxis ·        Length of development: 7 weeks ·        Development tools: Unity, visual studio, MagicaVoxel  

Ben Walker

Ben Walker

O'VERDRIVE Post Mortem

Post mortem: O’VERDRIVE   In the future, all crimes have been successfully wiped from the streets. Bored, and in fear of losing their careers, the future cops built a time tunnel using the magic of science. Into it, they put all the past crimes. You are Max O’Verdrive, a future cop of the clan O’Verdrive with a passion for justice and a cool car. It’s time to keep the street clean. Of crimes.     This is the introduction to my latest game O’verdrive, now I say latest game but it was technically finished around April this year I just hadn’t made it public yet. First a little backstory of the game.   Backstory For those who haven’t read my blogs before, I’m a student at SAE Qantm, during my spare time last trimester I had a couple of goals: ·         To make an endless runner ·         To make a mobile game So, after some planning I came up with the initial concept, a multi-dimensional endless runner based on 80’s nostalgia. The plan was to have it finished to show at SAE open night which was about 6 weeks away from the start of the project. The initial intent was for it to be made first as a pc game then modified to become an app, however time constraints limited this. Why O’VERDRIVE? I made a pitch to my teachers and after bouncing ideas off each other, the game became more and more ridiculous. Eventually ending in a Scottish future cop.         What went right 1.   Design / planning process In the past I’ve suffered from something I like to refer as “developers’ enthusiasm”, getting caught up in the wonder and idea of the game and just wanting to make that thing a reality, by starting development straight away. With O’VERDRIVE I took the slow approach for once, I spent the first two weeks just planning everything, the game design, the systems design and the aesthetic without laying a hand on unity or visual studio. I then took these ideas to other developers I quickly identified issues before even beginning. Honestly this was the best decision I made with the project and resulted in far less issues than previous projects.   2.   Style I always knew that I wanted 80’s nostalgia but what did that look like? In the planning stage, I spent a heap of time collecting pictures, influences, fonts and color palettes to decide on the style I wanted to portray to my audience. Even creating an attract mode for the introduction to reflect early 80’s arcade machines. Attract Mode Overall, I was very happy with the success of the intended style as it was picked up by most of the players on release.   3.   Release This went off without a hitch, I had a working version by the time of the event (relatively bug free). I had a section with multiple computers set up and monitored for the event and overall the response I got from both the game and the time frame it was built in was very positive. Multiple people commenting on the art direction     What went wrong 1.   Scope The initial intent for the game was to have multiple vehicles with separate abilities that you unlocked in a progressive format, however considering the dead line of this project and the fact I was doing it in my spare time after all my uni working. Things had to be cut for the release date, currently there is only one car (which was intended to be an end game vehicle).   2.   UI This is something I’ve always approached near the end of the project, because this was left as a after thought having correct UI for different screen sizes is something I definitely need to focus on for future projects. I’m making this game for all sorts of different screens and computers and need to take that into consideration.     Conclusion I have mixed feelings about this project, I’m proud of the design process I used to make O’verdrive and it resulted in a working game by the deadline but I can’t help but feel like it could be so much more. I was happy with the feedback too, I think that was by far some of the most important information I could use for future projects.   Should I continue working on this? Let me know in the comments below   Development stats ·        Developer: Ben Walker ·        In Game Music: Brook Wakeham, Jack McBryde & Riley Guerin ·        Release date: April 2018, P ·        Link to game: https://walkies3.itch.io/overdrive ·        Length of development: 5-6 weeks (spare time) ·        Development tools: Unity, Photoshop, visual studio, audacity, MagicaVoxel  

Ben Walker

Ben Walker

Toolin' Around, By Halves

Post Mortem: Toolin’ Around, By Halves   Introduction
As part of our practice to make user friendly tooling at SAE Qantm, we were required to create tools for designers’ projects. For the latest project, the design students have to make a game with the following limitations: In your assigned team, you are to create a fixed-screen game for PC with limited inputs. Your focus will be on mechanics and level iteration. Creative Limitations: Must run on PC Use only the arrow keys for gameplay. Levels are loaded from an ascii map text file Art assets are to be created in Magicavoxel. While we are not involved in the design process of the game, we have to assist each team by providing them with tooling that will help them create their intended games with ease.   What went right 1.      Programmer per team This was a happy accident, by that I mean it was never our initial intent as at the start of the project there was three teams. These teams needed different things, which we both started working separately on. Eventually they became two teams with separate needs and as we were already working on separate components we became the programmer for each team. This meant that we could work on our own systems and be accountable for those.   2.      Communication As mentioned above, because we had an individual programmer per team we were both accountable and accessible to the designers. They were able to give us design documents early and we were able to create systems then based on their needs. Even though we had set up repos where they could leave error messages, most of my communication was through direct messages. Solving issues as they arose.   The way I worked Based off the initially pitched game by the designers, I was able to pitch back to them what I thought they would need, this way any issues they had would be addressed early. Not saying that all issues were fixed early, as the designers only decided that they wanted some functionality on the fly but there were minimum problems.   What went wrong 1.      Separate Workloads While having separate programmers for teams was a blessing, it also meant that you were solely responsible for the work that team needed. While the workload was roughly the same, the difficulty of one workload was more significant than the other. Putting stress on one person.    2.      Helping alternative team This follows up with above, When the other team was having issues with things getting done, it was harder for the other programmer to step in and help. This was for a few reasons; ·         Separate systems, understanding the other programmers’ systems could sometimes be difficult as well as altering their work could sometimes cause frustration. ·         Martyring themselves, sometimes people don’t want to be helped due to whatever reason.    What to do in the future 1.      Scope In the future accessing the scope of work needed to make sure there is an even distribution of workload. If there is disparity between them maybe take a few extra tasks to help the other
  Conclusion
This project was a great test of the newly acquired skills from the last toolin, putting what we had learned into practice. The overall outcome of my teams’ game was pretty successful, this in part was due to the great work ethic they have but also their communication with me whenever they had problems arise. IGN 9/10 would work with them again   Check out their game here: https://slemhosta.itch.io/skimminal  Development stats ·        Developer: Ben Walker, Dan Ackroyd ·        Length of development: 4 weeks ·        Number of developers: 2 ·        Development tools: Visual studio, Unity  
   

Ben Walker

Ben Walker

Toolin' Around, Doom

Post Mortem: Toolin’ Around, Doom   Introduction
As part of our practice to make user friendly tooling at SAE Qantm, we were required us to make a fully modifiable version of doom. Which has got to be one of the better projects to work on (any excuse to play doom and I’m there). This project was a group project The requirements were to recreated doom entirely but in unity, considering User stories (i.e. Things that users of different professions and backgrounds would want to do with or to the tooling) Some examples of this includes: As an AI Developer, I want to be able to make the game run at an accelerated rate so I can more quickly test my AIs for effectiveness. As a Game Modder, I want to be able to change all damage outputs Our main goal apart from making the base version of doom was trying to accommodate as many of these as possible.   What went right 1.      Scheduling and task assigning We were given five weeks to get this done, which sounds longer than it actually is, however from day one we were on the ball, organizing scrum method and channels to communicate on. Tasks were assigned on a weekly basis and split between us. These were followed up by weekly meetings to confirm and assign new work.   2.      Learning new skills Speaking from my personal experience with this project (I’m not so sure about Dan), this was an opportunity to brush up on patterns and learn new skills. This included; ·         The use of Scriptable Objects, both for containing data out of runtime and ease of use for interfacing.  ·         Improving coding patterns, Using the case, commenting and summarizing code ·         Using Events.   3.      User Testing Through hosting successful player testing, we were able to see how are tools were being used and more importantly interfacing issues that they had. Spoiler alert, there was a few issues.. however, players managed to turn our errors into fun. If you have never rode a tornado of enemies while traversing doom, you’re doing it wrong.     The way we worked As mentioned previously, this was a group project, however we really didn’t really treat it that way. We would meet twice and week and would rarely message each other outside of that time. Just focusing on our assigned tasks and then showcasing when we would meet up again. This proved to be problematic     What went wrong 1.      Communication Even though we did have regular meetings weekly, this wasn’t enough to be effect in the timeframe we were given for the project. Sometimes going as long as not talking to each other for three days. This caused issues both with the speed and which things were completed and ultimately the collaboration between our separate systems.   2.      Combining designs Considering our systems were split and created in their own sections, we had many issues trying to get things working together, normally hacking them together in the times we were meeting. This cut into our design time and generally left us with a lot of unresolved issues.   What to do in the future 1.      Communication
Even though we did set up channels to talk to each other, in future using those channels more effectively by working together on technical design, assigning of tasks and completion of tasks in beneficial to the project.
  2.      Technical design By working together and creating shared documentation and diagrams, by having a greater understanding of each other designs, issues can be spotted before they are in production and then addressed.  Having some sort of waterfall method or at least a version similar to that would prevent design and game logic from being changed at a later date. Minimizing the issues related to poor or conflicting design.
    Conclusion
Overall, I had mix feelings about the project, the outcome of it was kind of disappointing. But if I reflect on what the experience taught me instead then it was quite successful. I learned new systems and new skills as both a developer and programmer.    Development stats ·        Developer: Ben Walker, Dan Ackroyd ·        Length of development: 5 weeks ·        Number of developers: 2 ·        Development tools: Photoshop, Magicavoxel, Visual studio, Unity    

Ben Walker

Ben Walker

Post Mortem: CountOut

Post mortem: CountOut
https://walkies3.itch.io/count-out- CountOut is a game based on requirements of a game jam, we were each given Atari’s “Breakout” as a base and then assigned an individual artist, my artist was Sally Sheinman an American installation artist. However, we did have creative limitations, these included; ·         Must closely resemble the layout of the original game. ·         Must closely resemble the mechanics present in the original game. ·         Must closely emulate the behaviour of player and nonplayer characters/entities. ·         Must resemble and embody the style and tone of the assigned artist.
This project was a solo endeavor by me, I am a student of SAE Quantm based in Brisbane, Australia. With experience in game development and majoring in programming I wanted to create a game that would both showcase the installation style and also provide the same sense of easy fun that Sally intended with her art work. Most of all I wanted the game to stop becoming a game at some point and more a kinetic piece of art.   What went right 1.     Planning and scheduling As this was a solo effort, planning and scheduling was achieved easily. I knew how much time I had and when I was available, not having to be concerned about whether work would be completed by others on time. Each week I used a scrum method, making a list of priorities that needed completing through HacknPlan and attacking one at a time in order. Through this method I was able to keep a track of the work that was done and what needed doing and thus how much time I would need to allocate to it.    2.     Design & Style From the beginning I had a very clear idea of the style and theme of CountOut should be, whether it was intended or not Sally’s work often imitates playable spaces. This made it very easy for me to envision a playable environment from one of Sally’s work in particular “Artkacina”. Looking very similar to a layout for a table top game with blocks to hit in the center. Her creations of many shapes and textures was easily reproducible in a game sense too   3.     Feature finding As the game developed, issues arose with the core design and while this isn’t a positive thing the ingenuity in fixing these problems within a time period were. It also shed light on to new and interesting game mechanics that would eventually be reworked from bugs into features. Alternative solutions to these bugs were theorized and tested to make sure the new feature functionality was correct, overall these were still achieved in a reasonable time frame and didn’t affect the scheduling.   The way I worked This was an interesting task, being a university student, time was restricted on the project. However due to effective planning and scheduling through HacknPlan, time was efficiently used as mentioned previously a scrum method was applied, by keeping track of tasks that needed to be completed within that week and updated frequently. There was never a point where I wasn’t sure what to do next. Also, any problems that arose were swiftly sorted and if the problem was outside of my expertise I looked externally for answers.    What went wrong 1.     Not planning ahead While I had an idea of what I wanted and needed in the game through the given individual specifications, the first couple of weeks of development my ideas changed, which in turn means there was less time planning the overall design of the game. Which lead to problems later in the project which included; core mechanics being changed, interactions being changed and more. Ultimately these were worked around or solved but if a clearer design was decided earlier than much time and frustration could have been avoided.   2.     Self-Management
This is something I feel is often overlooked, especially in our industry. Even though my schedule and time management were well planned, my well being was put second. Often working many extra hours to achieve goals. Even though I enjoy this development process at the end of the day its still work. Making sure that you have sufficient breaks and time to clear your mind is just as important to the projects health as yours.      What to do in the future 1.     Not planning ahead This is something that I’m normally guilty of, starting development before final decisions are made. While it could be avoided by changing my work method from a scrum to a waterfall. The most obvious solution is improved documentation, by effectively sorting these out before the project is started, issues are addressed and understood in the pre-production process.   2.     Self-Management
Now these are going to sound a bit ridiculous, but you would be surprised how often this is overlooked; ·        Take a half hour break every three hours, have a stretch, get a snack ·        Make time in your day for “play” ·        Stay hydrated ·        Get at least thirty minutes of exercise a day, even if it’s just a walk Looking after yourself is not only crucial to you and those around you but the life of the project as well. Time to reflect and recoup can help bring clarity to project which ultimately can save time and stress.   Conclusion
Overall, I’m really happy with how CountOut turned out, I learnt new programs and achieved things that were previously unobtainable. However, there is always lessons to learn and take away from experiences, this project being no different. In future projects I will keep in mind to create more detailed documentation and not to start a project before final considerations. Finally, to not take for granted health and self-management as the management of these affects the productive output of both the person and project. 
Find the game at:
https://walkies3.itch.io/count-out- Development stats ·        Developer: Ben Walker ·        Length of development: 4 weeks ·        Number of developers: 1 ·        Development tools: Unity, Blender, Audacity, Photoshop, Visual studio ·        Sleepless nights: 2
   

Ben Walker

Ben Walker

 

Postmortem

Post mortem: Infinity game’s It’s a blob It’s a blob is a top down puzzle platformer with a cute pixel art style to the game. Currently only available on itchio.  In the game you play as the character Blob (very creative I know), Blob is part of a solitary alien race; their influence is spread over many galaxies however they are destined to spend their lives alone. But Blob is different, he doesn’t want to be alone, so it’s his goal to reunite his people. Blob spends many of centuries (blobs live for a real long time) searching for some old alien technology that linked all his kind together. Pretty much the equivalent of Blob interdimensional Facebook and that’s where the players story begins. Blob actually found it! And now it is his mission to seek out and reunite his blobs once again.

We’re a very early indie games studio made up of students from SAE Quantm based in Brisbane, Australia. With varying backgrounds that make a well-rounded team.       Our team wanted to create a game that would be filled with the same fun and experiences as other games had been in our childhoods. Overall, we weren’t looking for any financial gain from this project but instead knowledge and experience that we could take to future projects.    What went right 1.      Ideas stage Through brainstorming sessions and generally just bouncing ideas off each other we were able to come up with a concept fairly quickly for the project. Being able to get this information in a visual form and voting on what ideas we would use was an integral part of our process.   2.      Scope As this project had a deadline of 12 weeks, it was very important that we didn’t over shoot with what we were capable of producing in that time period. In fact, we under shot this quite a bit. While all the mechanics were in place, the amount of levels we had to explore those were so few we had to expand them by double. This wasn’t an issue though as we had plenty of time to alter and improve on the project.   3.      Style From the beginning we had a clear direction for the art style, wanting a fun and classic looking game, in the form of pixel art. Which was both easy to produce and visually pleasing to consume. The style remained mostly the same through out the project getting a visual tweak in the polishing stages, this was done for both visual clarity and especially if animations were involved.          4.      Testing The game was play tested thoroughly as new mechanics were added to the game and in the final stages, which picked up on majority of our bugs and problems. We also conducted a closed group alpha testing which provide to be invaluable for our game, by recording their feedback and gameplay we were able to analyze why the game wasn’t being played as we intended.
Apart from a few in game bugs we hadn’t picked on, the main issue was giving the player to much freedom in tutorials and as a result they were not doing them or completing them in the wrong linear order which hindered their overall experience within the game.     The way we worked This was an interesting task, being university students, we did have time in class to do some work but most of our time was apart. We assigned a project manager to the group who split tasks and generally kept a track of the work needing to be done. Although a scrum method was applied, it was a loose method. Mostly just addressing issue that arose and applying things in order as we needed it (art assets being left until later). Meetings were held every Monday afternoon on our own discord channel for several hours, as previous work was verified, and new work was assigned from that point. Further contact was kept through a Facebook page, so we could upload and share content on a more frequent basis.   What went wrong 1.      Puzzle refinement As mentioned in the testing section, level designs concepts that we thought were obvious as developers were not obvious to players, resulting in a poor player experience in our initial alpha testing. By changing the layout of the (portal room) and altering the intended path of the player (forcing them to complete levels in a certain order) we were able to fix this. However, it required more time and effort than was necessary than if we considered this at an early stage.   2.      Not planning ahead This was a big one, while we had an idea what we wanted and incorporated that into the game this changed throughout the project, with new ideas being tested and trialed on the fly. Sometimes working and sometimes causing more issues. These included: ·         Changing camera perspective through game development (many hours changing and recoding)   ·         Changing level design ·         Recoding the interactions between player and objects ·         Change of assets ·         UI However, the results of this undeniably improved our game, but by planning ahead and coming up with a conclusive design, we could have mitigated these risks and saved ourselves a lot of time. 3.      Management
This was something that was a bit all over the place, initially task were delegated as they were needed to the people appropriate... great, however as the project went on and the focus was more on coding, tasks were being split unnecessarily for the sake of feeling included in that point in time. This resulted in a mess of trying to collaborate work, double ups of some work and sometimes things just not being done at all. In the end it reverted to the old method of only being given to the appropriate people.
Some delegated tasks were not being completed as well, forcing others to pick up slack to make sure the project was on time.      Conclusion
Overall this was a great experience for us as early developers, even though it had its ups and downs. It gave us an insight into many of the aspects of both team work and the development of a game. We learned a lot through out the process too and im sure we will all be taking these lessons on to future projects. It’s a blob was never meant to be anything more than an educational project but to me it become so much more than that. I’m proud of it
  Development stats ·        Developer: Infinity Games ·        Release date: Dec 2017, PC & Mac ·        Link to game: https://lazareth13.itch.io/its-a-blob ·        Length of development: 12 weeks ·        Number of developers: 5, (4 at a later point) ·        Development tools: Unity, photoshop, visual studio, monodevelop, ·        Budget: N/A ·        Sleepless nights: 2

 

Ben Walker

Ben Walker

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!