BCT:Multi-purpose Glue

Secret to fun.

I really enjoyed this talk, it highlights the difference between gamifying something and actually making it fun, games aren’t fun because they’re games, they’re fun because they allow for play in a given context. I mentioned near the beginning of the semester one of the talks at NZGDC by Jimmy Baird a lead game designer at Magic Leap  and how he put forward the idea that any ‘game’ that exists, exists in our minds and everything outside of that e.g the board and pieces or the software that’s running can be more thought of as a toy that facilitates play and allows for the game to be made in our mind than the actual game itself. The games are fun because the toys used for them provide a high capacity for play and interaction. i think this is particularly relevant to this talk because of the emphasis on play which revolves around interaction with these ‘toys’. The fun comes from the capacity to play with the toy and the emergent scenarios that result from such. Simply inserting game-like qualities into something that doesn’t already provide capacity for play or failing to provide capacity for play together with the ‘game’ fails to make it anymore engaging than it was before. 

NZGDC Talk Jimmy Baird Broken Toys and Borrowed Dreams

https://www.youtube.com/watch?v=4rdzs4OK4yY&t=0s&list=PLHvYfcRJ9kWyOcdL4GOIUgivYs2OSKpvm&index=19

John Blow’s Prototyping

coming from a more technical side of things i definitely see the value of prototyping around a single mechanical concept, personal experience tells me that when you’re trying to test more than one thing at a time it becomes immediately more difficult to understand how to take holistic player feedback and use it constructively. often a game built around one mechanic polished to a high degree will carry you much further than a game that splits it’s development over a few half baked ideas. 

Play without Pixels 

the section on the mda framework and it’s basis in software development was interesting, i like how everyone agrees on the fact that fun is such a nebulous and vague concept, and i thought the statement that a lot of games these days aren’t trying to directly create ‘fun’ was worth making a note of though i don’t know if the examples of horror games and such were a great example. concerning paper prototyping itself i’ve seen it’s value firsthand in some of the uni projects i’ve worked on and can say that it’s definitely worth going over the rough idea in paper before even touching a computer for game development. 

Cannon Fodder was a neat discussion, you can talk about how it’s hard for games to be taken seriously as political statements but i think that’s true of any media, it’s open in interpretation and as a result open to misinterpretation. People like getting angry, people like fighting, and in my opinion the logical extension is that some people like to get offended, even if only because it provides an opportunity for the former two. 

Perma-death and legacy mechanics are always interesting because of their impact on the fundamental aesthetics of gameplay, toying with a players emotional response to loss in both the sense of losing a game and losing a ‘belonging’. 

the video on how rap artists put their words together was really neat and gave me a little more appreciation for a genre i’m personally not all that fond of. i might endeavor to dabble a bit more in such genres no doubt to the delight of some of my friends. 

the horror score instrument reminds me of a project we did in the first year of creative tech, building an instrument. i have to admit i didn’t fully appreciate the freedom i had in that brief and didn’t really play around as much as i could’ve, alas missed opportunities. 

This semester has proven to be a long lesson in project scoping, quick failure, rapid prototype development. The goals we had for what we worked on this semester were split between fulfilling our Academic Learning Outcomes and developing a polished proof of concept for a commercially viable product. As a result we met with a number of additional complications over the course of development.

Since we returned from inter-semester break we’ve worked through 4 projects before T-minus. Each had serious roadblocks in the way of achieving the goals we had, both academic and commercial. Nonetheless experience and knowledge taken from these failed projects has helped to inform and develop both my practice both personally and within the scope of the team environment.

The first project was conceived before the semester began and never left the concept phase.

The second project ‘Soul Passage’ also started the concept phase prior to the start of Uni and lasted two weeks into the semester. During this time, we experienced a few issues in the group dynamic and as a result group morale was shaken somewhat. I personally feel morale only truly recovered once we got to work on our final project. My work on this project got as far as a prototype/proof of concept for 1 of 4 planned puzzle-dungeon areas and the first version of the playable character. 

We then came to the decision that we had over-scoped the project and would be unable to achieve our goals in terms of development and polish in the time frame of one semester.

The third project ‘Walrush’ started development in week 3 and marked our decision to focus on the couch co-op/party game style of play and the accompanying demographic. The primary method of play was based on a mod of Grand Theft Auto 5 and, when both the mod was made into an official game mode and the team behind it integrated into Rockstar Games, we felt that the risk of infringing on the IP of a big name like Rockstar significantly decreased the commercial viability of the project. My work on this project got as far as another basic prototype of play, a character, a target and the means to glide across the distance between the two as you try to stick the landing.

The issues that gave cause for cancelling these projects all stemmed from our desire for an outcome that we could continue to develop and commercialize. I took each failure to be a learning experience in preparation for the environment I intend to move from University into. Soul Passage would have been largely driven by strong narrative and visual elements that we had little to no means of showcasing and developing within the timeframe available. If we wanted to be successful we needed a concept that played to the strengths of the team skill-wise and gameplay that could be inferred easily with as little exposition as possible.  This is what led to our decision to attempt a multiplayer/party style game for our next attempt. The issue with Walrush was largely a business one, we didn’t want to step on the toes of a company much bigger than us, we had chosen the mod-derived idea primarily because it had already proven to be a popular method of play amongst GTA players and the quick play nature suited the party nature of what we had decided to do. However pinching other people’s ideas and reworking them to suit our means is never really an optimal solution and if I’m honest I’m a little glad it fell through if only because of my misgivings as to the origin of the idea. It also served as a re-enforcement on the commercial nature and environment we aim to transition towards.

Walrush 2.0 was concepted as a snowboarding/racing game. It was quickly vetoed as I personally felt that within the ever-decreasing span of time we had left snowboarding physics was beyond my capabilities, particularly given the fine tuning that would be needed for at least semi-realistic movement and polished fun control capabilities.

Then came mid semester break, and with it our current project T-Minus. The initial concept came about during the final week preceding the mid-semester break, rather than risk more wasted work on developing a concept that had little potential we decided to paper prototype the rough idea before any computer work took place. Playing the paper prototype didn’t tell us much but it did show some promise in the core ideas behind the game. Over mid semester break we worked to get a proof of concept ready for class. Unfortunately it took me another three weeks to have a basic playable version of the project due to bug-fixing as i implemented the score systems. I personally feel that for this project programming was as much a platform for exploring game design as it was a straight contribution, a consequence of having to test everything you add or change I suppose.

From my perspective as a programmer the project lacks most of the back end framework and architecture that is required for video game and instead serves as a proof of concept for what we plan to develop in the future. With the limited time at our disposal the developing the ‘game’ was higher priority than the ‘program’.

As far as game design goes more play-testing would have been helpful (something true no matter how much play-testing you actually do). We tested two different styles of play, the first of which we developed into its current state as part of the project focused on a mad scramble type of play where the resource items to collect were spawned randomly over the center of the map.

The second which was more exploratory with resources spawning in consistent locations on a larger map was dropped though some elements were assimilated into the project proper such as the pointer above the character that points towards the home base.

Feedback and testing showed that the primary play method was both better suited to our core concept and more enjoyable for players.

Studio IV 

it’s been three weeks and we now have a playable mvp for our latest attempt at our studio project. work has been focused primarily on getting the bare bones playability out the door so that we can actually test the idea. 

the development was delayed largely to a bug i encountered while building the game’s system of progression in which a recipe called for various ingredient items to be put in a pit and one the recipe was complete you’d get to the next stage. the bug was in the method the game used to check if the correct ingredients were in the pit and was caused by an array of boolean values which would continually set themselves back to their default setting of false immediately after being set to true, because i had no way around this, i ended up having to re work my system from the ground up. This cost us presenting at the game dev meetup for the second time in a row and has been no great aid to my efforts to manage my own stress levels.

week 6 

we’ve got our new project idea. 

you must compete with 3 other astronauts over scarce resources to fix your ship and be the first to leave the planet you’re stranded on.

i’ve gotten to work on building the MVP, to be prepared by September 6th for the game devs meetup. as it stands we have a 4-player top-down “game” where you can pick things up and drop them. further implementation due before the deadline to allow for play testing is a system that keeps track of resources on the field and controls the spawning of additional resources, the system that tracks player progression towards finishing their rocket and also the method of progressing i.e a dumping zone that when it’s filled with the correct objects, furthers the completion of the rocket itself.

it’s the end of week 5 and as it stands we’re back to stage 1.5, issues with the commercial viability of our initial Walrush concept have pulled the brakes on that particular game mode, Rockstar games have made the GTA 5 mod that we took as inspiration for the gliding walrus game an official mod/game mode, making a matter of IP another hoop to jump through on the path to building a commercial product.  

The first iteration of the movement system for Walrush! is done,including basic glide physics and ground level locomotion. i feel like this has taken too much time for something that in theory should’ve been so simple. attempting to use Unreal Engines pre-built character class had a great deal to do with it, rather than work within the limitations either the class or my understanding of the class provided i found it much simpler to use the physics engine with a custom Pawn class, this means that without further research into C++ programming for Networking, multiplayer games will be limited to local single machine matches. this isn’t a huge setback considering the primary intended play experience for our audience is local couch based multiplayer but it does inhibit future development for networked multiplayer should it be a viable or necessary step. 

Our initial project proposal ‘Soul Passage’ has been laid to rest. there are several reasons for it but the primary issue is the scale of what we hoped to achieve given the amount of time we have, an amount that grows smaller by the second. 

Our second ‘project’ is being split into two smaller ideally more manageable endeavors, though management itself is growing more and more convoluted it seems. As a group we have 2 projects, the workload/pipeline for these projects is split between presenting a meaningful and polished experience for the BCT Showcase, and having a complete commercially viable product for release early next year. this is further complicated by the fact that our papers are split differently across these two projects for each of the members in our group. In my case i’m doing both projects for two papers as well as another paper unrelated to either of them. approximately 6 learning outcomes to be fulfilled over two projects which are to be polished and demo-ready for the Showcase. it’s doable, just confusing to think about. 

As for the projects themselves i must admit they interest me a deal less than Soul Passage did, personal preference mostly, i was having a pretty good time putting that laser light puzzle together. it was sad to see it disappear but that’s what happens. 

the first project is a paper-plane gliding experience, focusing on casual gaming as a form of stress relief and inducing calmness, while also exploring alternative methods of control than a standard gamepad. 

the second is a multiplayer party game where walruses send themselves flying onto tiny targets for honour, glory and the biggest score at the end of the game. this one is based more on commercial viability than university learning but i hope to learn a bit more about couch-based multiplayer gaming though the course of it, ideally this project becomes part of a collection of these games for commercial release. 

 The multiplayer back end set up for our game is now semi-functional. It was a hefty work-load that consisted of creating all the scripts that hold player information and tell the computers on the network (both server and client) how to handle the information they send to each other during play.  It also meant programming some basic user interfaces for players to set up games and the like, always tedious work but necessary nonetheless.

Given that our game is based around multiplayer PVP play this is not a small deal in terms of the project itself, which I feel validates the three weeks or so I’ve spent on it. With both multiplayer and basic gameplay in their functional states we can now begin technical playtesting.

 Personal reflection

The process so far has been a lot of work and I must admit comparatively little ‘thought’ per say. As my work largely consists of teaching myself whatever it is that needs to be done, as I do it. Primarily through finding then following a video tutorial for whatever mechanic or task I’ve been set with then tweaking it later to fit the context of our project. It opens a discussion on how much of the programming so far is ‘my work’ as much as it is ‘the internet’s work’. One could argue that my primary task in this project isn’t so much ‘programming’ as it is ‘compiling’ with a side of learning programming for future use, and could further beg the question of where the intellectual properties lie. I admit I’m not terribly concerned with waking up to a dozen copyright claims from various amateur and professional Youtube programmers claiming their stakes in Orbital Drift, the indie game dev scene around using Unreal Engine in particular has a very strong ‘community learning’ aspect to it, you essentially learn by asking how to do things or finding a response to somebody who already has and Youtube tutorials are just another part of that dynamic.

It is now week 4 and this is only my first blog post, oops.

That being said i haven’t spent this time twiddling my thumbs and loafing about, i’ve been doing work.

When we finalized the direction for our project and our group dynamic had settled i got to work on the set of programming tasks that compose the functionality of our game. Below is a checklist of my tasks and progress so far.

Laser Cannon- Complete Rockets - Complete

6DOF- Work In Progress. Camera/HMD- Work In Progress. LAN  - Work In Progress.

Reticle Aiming - Work In Progress. Rocket Lockon - Work In Progress. Health - Work In Progress.

Boost - Incomplete Scoreboard - Incomplete Menu - Incomplete Death - Incomplete Spawn - Incomplete Ship Select - Incomplete Splash Screen - Incomplete Quick reset - Incomplete In layman's terms, i have a mechanically functional ship that can be flown around, it will respond to controller input, it has two weapons, a standard straight shooting machine gun, and a missile that after locking onto a target can be fired and will orient itself to fly towards said target. These weapons can deal damage to other objects.

Anything under Incomplete is something that i haven’t started work on, primarily things relating to how the game manages itself.

Anything under Work In Progress is something that is functionally operational but requires further tuning.

6 degrees of freedom.

The capability of a player’s ship to move and maneuver through space. The 6 degrees refer to translation along the 3 spatial axis (x,y,z), and the three rotational axis (roll, pitch, yaw).

Initially i ran into a problem called Gimbal Lock, which is a feature of the method that the Unreal Game engine uses to handle rotations (Euler Angles). Gimbal lock occurs when two of the rotational axis are aligned in such a way as to restrict movement along the third.

Here’s a gif of it i found on the wikipedia page.

This issue has been solved through some alternative logic and now the work i’m doing on movement is primarily in regards to tuning the acceleration and friction for both angular and linear movement.

Camera/HMD - Reticle aiming

You can currently wear a headset and “play” the game, because i don’t have a ship with a modelled cockpit yet you instead follow behind the ship, the machine gun fire and missle lock on trace will aim towards wherever the player is aiming. However other than always being the center of the screen there isn’t much to tell you where exactly you are aiming, no visual reticle. I also need to limit the possible rotations for the weapons as they should only be capable of aiming within the field of view that the cockpit window allows for.

Health

I’ve practiced with implementation but have yet to fully apply to the ship itself.

Rocket Lock-On

I can set a locked-on target for missiles to follow, if there is no target the missile destroys itself as it is created, when events like explosions happen on it’s destruction i’ll need to re-visit that aspect. Rockets also immediately face their targets, this will be changed so that they re-orient themselves over time after firing with a set initial orientation.

LAN

I haven’t looked too much into this yet. Aldo has as said that the Unreal Engine handles most of the work on it’s own so it’s a low priority for me right now, coming after making the game playable on one computer.

Reflections

I’m pretty happy with my current level of productivity, i think working in a larger group dynamic is proving to be a boon with regards to my work ethic and attitude towards the project. Progress is steady and i am ahead of schedule. I’m glad that my relative lack of experience with the Unreal Engine and the BluePrint visual scripting system itself isn’t proving to hold me back all too much. Though i have some compunctions with using visual scripting, it does prove to have it’s advantages. The issue i had with gimbal locking is a pretty good example where what i was doing made sense to me, but because i had used a similar though different drag-drop command to what i really needed and as a result Unreal spazzed out when i tried it out, the issue was a simple fix in the end but it took me a while to figure out where i had gone wrong exactly. I suppose that could just be programming in general though.

Time management on my part could still use some work, i do after all have other papers.

i’ve been trying to create a means of changing the size of the 3-d models inside the application but have had no luck so far, as it stands my current prototype isn’t too much to look at, i’ve used some of the insect/bug models that Auckland Museum have placed on sketchfab and they currently are capable of showing their names and a piece of trivia about them, at this point i’m running low on time so what i can further implement is limited.