Jump to content
  • Advertisement

Ben Walker

Member
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

2 Neutral

1 Follower

About Ben Walker

  • Rank
    Newbie

Personal Information

  • Interests
    Design
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 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
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!