Introduction
Initial Interest and Inspiration
The “MageWorks” project is an ongoing study in VR derived from several years of experimentation with the DK1 and DK2 from Oculus. After building a few prototypes with the DK1 (Stereoscopic + Rotational Tracking), and testing out possible ports to VR on the DK2 (VR + Rotation + Positional Tracking) with some of my existing IP, I was excited to grab an HTC Vive in June of 2016 to start studying room scale VR with positional tracking for both the headset and hand movement.
Upon reviewing the library of games on Vive’s initial release, I got my virtual hands wet with with a couple products, but mostly spent time in “The Lab” from Valve. It was a great way to study how different concepts were tackled in VR with regard to player perspective, player translocation, and the choice-making process in a VR environment when objects could now be directly interacted with using one’s real hands represented in virtual reality.
One thing I noticed in the library of games that were released on the market with the Vive was that there weren’t too many fantasy games with a “mage” theme at the time. I was (and still am when I have a rare moment to play) a fan of the Blizzard’s Diablo and Warcraft series, and was hoping to hop into a similar type of environment to see how they tackled various challenges of developing in VR. When attempting to port several types of features/mechanics on some of our existing IP into VR using the DK2, I realized that porting in general was problematic because of our natural limitations/constraints associated with operating software in a virtual reality environment. This process led me into the development of MageWorks.
The Concept / Hypothesis / Story
When starting to build MageWorks, the concept was derived from the questions “How can you play the role of a wizard in VR? And how does the inclusion of motion control (referring to positional tracking of hands in VR) impact the way we game in VR in the context of wizardry?” Looking back at the various studies in Valve’s “The Lab,” among other products, I studied the physical movements a player was required to make when interacting with environments in VR. Unsurprisingly, simpler movements tended to be more effective with environment interaction. While more complex patterns coupled with gesture recognition created some exciting and innovative content, it was still a bit complex for such a new medium of interactive expression (at the time). The motion control we studied looked at various combinations of:
Motion Control + Crafting (Tilt Brush, Quill, Medium, SculptVR)
Motion Control + Combat (Dead & Buried, Unspoken, Space Pirate Trainer, many more…)
Motion Control + Assembly (Waltz of the Wizard, Fantastic Contraption)
Motion Control + Roller Coasters (Roller Coaster VR)
Motion Control + Reading (Nothing really existed yet that we could find)
Concluding the study of existing content, I decided to move forward with the concept of putting the player into the role of a wizard wielding a staff in one hand and a book in the other. At the time of inception, menu systems in VR games were still very much in experimentation mode.
The idea of creating a spellbook was intended to propose a way for a player to choose various spells. This would become the fundamental way the player could unlock pages or gain access to more powerful spells when they progress through the game.
The staff – on the other hand (pun sort of intended in retrospect) – would be a way for the player to cast their chosen spell. And ,of course, if a wizard game has a staff, then true to the nature of it’s genre, there should probably be a way to craft that staff.
Crafting quickly became an important part of the study. Finding a balance between virtual crafting with real-world physical movement – yet avoiding “watching glue dry” mechanics – was part of the focus during development.
Early Development Challenges with Implementation
Given my past in developing content with UDK, I moved forward in creating the MageWorks prototype with Unreal Engine 4. The built in API would expedite the prototype creation process, however, their VR template had not yet been implemented into their binary release. This meant I needed to build a system to handle locomotion/player translation in VR, as well as an interaction system in some rudimentary way.
When considering locomotion in VR, it is also important to consider the scale of the environment. Scale directly impacts navigation in VR, the perception of the fantasy world, and the amount of detail that goes into the environment. With small scales, more of the environment is accessible, but the player could feel constrained. With large scales, the player could feel like they are in a free and open world, but detailing this environment could be time consuming. Plus, navigation could be challenging with teleporting being too frequent or analogue movement being too uncomfortable.
This lead me to an important part of VR design development: market segmentation. I wanted to develop the game catered to the market that appreciates this genre. The problem I ran into was that during my several years of experimentation in early VR development, I found there was a pretty large divide between first-time VR users and more experienced users.
First-time users were still getting acquainted with what VR had to offer, while veteran VR users were ready for more advanced controls. Finding a medium here could be problematic because the medium could be too difficult for beginners, yet too easy for veterans. Additionally, the fantasy/wizard genre market population in VR gaming was somewhat low compared to that of other genres, like first-person shooters.
Pre-Launch / Early Access
Minimum Viable Product (MVP)
The first playable version of MageWorks focused on the combat system. I built mechanics that allowed the player to flip through their spellbook in one hand, and based on whatever spell was open in the book, the player could use their staff to cast their spell. The spells were divided into several classifications: long-range, short-range, area of effect, pet-based, and defensive.
This corresponded with the typical language of spells offered in most popular fantasy-based games. A player could then use their staff to cast their chosen spell. The short-range spell also required the player to include some additional motion to their cast either by raising their staff up in the air,or lowering it to the ground. All shields walls (the defensive spells) were also cast by players touching the ground with their staves and using the action button to raise the shield wall out of the ground.
A “home level” (Mage’s Quarters), as well as five additional levels, were planned, each reflecting the schools of magic players could unlock. However, only three of these were available at launch to test how intuitive map travel was. At the time, map travel was based on selecting a 3D icon located on a map board in the game. This method would quickly change soon after release based on development plans to create an observatory system allowing players to stargaze and look for constellations. The constellations would then be used to travel to a desired level. Constellation shapes reflected the type of magic used in the level they could travel to.
With only a handful of spells available on first release (each representing a type of mechanic that would be built out during development) and a couple levels to test, players could get a general feel for how the game worked and what it could offer in the long term (minus the crafting element, which was included in an update a few versions later). A rudimentary AI system had also been built, which included a basic “skeleton” enemy type with melee combat and ranged combat.
The story behind the game was a parody. The player was in the role of a wizard who just graduated wizard school and would need to fight enemies to collect gold and pay off their wizard school loans (learning a trade skill in the process through staff-crafting tutorials). Quite topical given the news at the time regarding students finishing college with massive debt, yet having a tough time landing a job in their educational focus.
Feeling pretty good about the prototype I had put together, and having been “greenlit” on Steam (Steam Greenlight still existed at the time of development), we released into early access to start building our community.
Community Response
At first I was kind of surprised this didn’t receive more positive feedback because, when testing with folks locally, people were pretty excited about it. As I read and responded to various comments, I began to see why the reviews were what they were. First, I released into a market where consumers were getting frustrated with VR concepts and wanted to see more finished products. Second, the prototype systems I developed thus far worked well when testing because I was talking directly to the testers (which were composed of family, friends, and locals) but ultimately were difficult to understand by new users without any guide or tutorial to help them.
Prior to release, the VR consumer community was beginning to express their concerns about VR having a lack of finished content. The cause of this from a developer or business standpoint made sense. Some of the bigger names in game dev were hesitant to invest a lot of time and money into VR because the market size didn’t justify that kind of commitment. This meant that the first round of high-end products was really an investment designed to drive market adoption of VR. A lot of people at the time were asking “Is VR here to stay?” In short, the answer would be a definitive yes, but market segmentation made it difficult to determine how it would be adopted, especially beyond gaming. MageWorks was a self-funded side project at its inception, so development was expected to be slow on my end of things.
Developer Reaction
Based on community reaction, and the quickly evolving VR tech, several of the prototype systems I developed ended up being scrapped. By the time I had finished a few of the systems for integration into the game, the VR tech scene had already advanced. New and better hardware was on the horizon, VR templates were now integrated into middleware, and we started to see somewhat of a standard interface and interaction system across multiple genres of VR games and applications.
The VR templates tackled player movement in VR in a different way, which we found to be much more effective (and cross platform compatible). While the player would still be teleporting from point to point, under the hood, the system that controlled this was overhauled on my end of things. We also saw menu systems were more prevalent in VR products now. We had initially tried to integrate the menu into the environment but found that there was too much discontinuity in the environment to make this an effective solution. So I began to migrate the menu system into a stand-alone traditional menu.
For combat in MageWorks, I saw that players loved spell casting but didn’t really enjoy flipping through a book when under pressure to cast a spell, so I knew that I needed to change the system to be more accessible. With a crafting system on the horizon for the game, I also needed to scrap the current staff/stave feature in preparation for the crafting element that would be introduced. Instead of a single stave, players would have a staff with interchangeable parts.
Refining Development Locally
Meetups
From the onset of using the Oculus DK1, DK2, and eventually the Rift, I had participated in a variety of festivals and meetups to present and share some of my IP with the local community. I developed a nice network of colleagues who became somewhat of the VR “usuals” at our meetups. We were all in relatively similar positions as we looked to see how VR could be integrated in our various creative life pursuits. These meetups became a great way to get user feedback from both seasoned developers as well as new users. I eventually started presenting MageWorks at the meetups, which helped guide some early development.
Iterative Design
With lessons learned from a “too-early access” launch and feedback from local users, I was able to release regular updates either monthly or bi-monthly with improved usability, and the eventual build-out of the remaining levels. It was challenging to build a game that was both “festival-friendly” and online friendly.
So throughout the feedback and development cycles, I developed ways that allowed players to instantly engage with the world (eventually known as the “quickplay” areas), or explore larger levels to discover new spells. This seemed to work pretty well. I had finally integrated the map travel system through the use of the observatory. I had built flexibility into the map navigation system by allowing players to teleport where needed, or they could summon a hover-drone of sorts for analogue movement. We now had five different exploration levels, three quickplay levels, a quick-casting spell-book system, a tutorial guide in the form of a spirit bird, and, last but not least, the crafting system, which would end up disrupting my own development.
The Crafting System
Since the staves in the game were made of interchangeable parts, the crafting system directly related to each part. Players could collect resources in the environment that included wood, crystals, and flowers to use as their materials. Therefore, the crafting system included a wood shop, crystal shop and ink shop. Additionally, I wanted players to be able to 3D print their staff designs, so part of our system included a way to export staff designs for players to collect and share with friends in reality.
The wood shop focused on creating shaped pieces of wood for the upper and lower parts of the staff. The lower part of the staff required players to collect wood, chop the ends off with a hand saw, remove the bark with a mini lumber mill, and then lathe their desired shape into the remains. The top of the staff was drawn onto a drafting table/drawing board of sorts, after which they operated a virtual CNC machine that “carved” out their design from a slab of wood.
The crystal shop required players to collect crystals and break them open to get to a core. Then, using tongs, players would grind away pieces of their core crystal to create a desired shape. After polishing their crystal in the tumbler, they could affix their new part to their staff.
The ink shop required players to collect flowers, cut the blooms off of the stem, crush in a mortar bowl, mix with an admixture, and scoop up with a bottle for storage on a shelf. At the time of this feature implementation, ink was used to draw designs for staffs, but the purpose of ink would later change due to the overwhelming complexity of what was required in craft in this VR experience.
I built the system in a way that could be exported for 3D printing fairly easily and created a small “export kiosk” in the VR world where players could go to save their designs on their computer for 3D printing.
Another critical part of development that should have been a part of the “too-early access” release was a tutorial system. With the complexity of the crafting system I created, it was important to create a guiding system to help players learn the game’s way of handling crafting. This feature manifested itself in the form of a spirit bird that would follow the player around, telling them how to use the different tools to assemble a staff.
As I tested these features over the course of many meetups, I had conversations with folks in the education world who would show up to the VR meetups. Consequently, I was invited to demo the project at a couple of different schools and libraries. Given the interest with this market sector, I also reached out to a few local makerspaces, education groups, and entrepreneur meetups to see if there was any market viability here for a stand-alone crafting and assembly platform.
Educational Interest
Schools & Libraries
The somewhat informal entry of MageWorks into the educational world began with a talk and demonstration at a local private school. After a 15-minute presentation to students about VR and AR (which somehow ended up instead being a talk more about evolution of computers to VR and limitations with physics), students then had a chance to hop into MageWorks and test out the various features I had built. They had a lot of fun and reinforced this concept that a standalone crafting platform may be worth building out as a virtual makerspace.
After the talk and demonstration with the local private school, local libraries contacted me as well to see if I could demo the project. I jumped at the chance to do so, and brought the VR rig to the different libraries. Students and library patrons loved using the virtual makerspace and even had the chance to 3D print their designs to share with friends. This response led to the desire for a standalone virtual reality makerspace for educational use.
Crafting Workshop
And so was born the MageWorks workshop. Given at this point I was still developing solo, I didn’t have the budget or time to stop work on MageWorks and focus solely on the workshop. There was a market demand for it, but it wasn’t clear how that market demand might help fund the feature request and development. Furthermore, the study of the ed-tech market was new to me, and I wasn’t aware of the politics involved, since this market crossed into the public sector with schools and libraries. Building a software product for the ed-tech market was also much different then the gaming market because the purpose of the software is much different in each case. Edutainment is still entertainment, but it needs to be validated from a very different review group (teachers, education leaders, politicians, etc).
To mitigate the differences between markets, I chose to build the crafting workshop as a feature in MageWorks, which was basically an option a player could choose if they only wanted to craft. This way, schools and libraries could just stick with the same game but would always have an option to dive right into the crafting workshop without any additional requirements that may have been implemented in the exploration game.
In retrospect, this was probably not the greatest approach. As I continued to update the product in the marketplace, MageWorks began to run into an identity crisis of sorts. There was no clear direction on what a player was supposed to do since time was divided between crafting and combat. So much time had been put into the crafting and tutorial system, that I sort of lost focus on the combat mechanics that still needed tweaking and adjustments.
VR MakerSpaces
With the creation of the crafting workshop integrated into the core of the game and rise in interest of the product for educational use, I began to spend more time focusing on learning the ins and outs of raising money to potentially build a platform around this concept. I continued to spend time visiting entrepreneur meetups, local education groups, and makerspaces that tied directly into the ed-tech world.
I eventually built a pitch that abstracted the VR crafting workshop into an educational platform that would give users access to a wizard-themed woodshop, a gearhead-themed metal shop for learning about engine assembly, and a sci-fi or steampunk-themed drone shop to teach/learn about electronics and drone construction. This led to an interesting and unexpected leap into the investment world.
How Game Became Platform
Investor Interest
I was sitting in a workshop over at a business incubator, listening to the various programs they had to offer about startups, and asked about any programs that teach how to write business plans. The instructor of the workshop then said to me something along the lines of “No, they don’t, but if that’s of interest, then you might want to talk to the individual sitting two seats down from you,” and pointed. After the workshop, I had a conversation with the person I was referred to. He was interested in getting into VR investment space, and the demo I described (video recording of a MageWorks game session presented via phone) piqued his interest enough to set up a time to meet and discuss further.
On the investor side of things, his group was setting up an investment vehicle designed to be a concierge-style business advisory group. This sounded like it could be in line with what I was looking for to help build a business around this VR MakerSpace concept. The catch was that I needed to form a C-Corporation and issue some equity to the investor in exchange for his time. Another caveat was that his group invested primarily in business that was deemed “virtuous” per generally accepted definition of the word. He felt this concept was virtuous in that the work I had already done at this point brought technology education using VR into the public education realm.
Lean Startup
With investor interest, and prior to signing any agreements, he recommended that I read about lean startup theory from Eric Reis, as well as review various excerpts from Business Model Generation to see if this was really something I wanted to get into. In the process of reading this content and many references found within that content, I continued to study market trends and chat with lawyers to learn about any legal implications or obligations with this sort of investment relationship. I also continued to refine the pitch per various examples online that showed the past pitches of some pretty famous companies. Surveys were also a part of my research, the result of which made commitment to the idea somewhat of a risky endeavor. From what I read in the business community, most failing businesses enter into the market with an idea rather than an answer for a market demand. If the business of a VR MakerSpace was to take off, we would need scalability, a good understanding of market segmentation, IP protection with an understanding of the competitive landscape, and strategic partnerships to help pioneer the way to success. The answers to these studies would ultimately determine if this was a fundable project, and if so, what kind of investment mechanism or business model would be appropriate for this development.
Verticals
Research on the VR MakerSpace concept identified three possible verticals to engage in. Gaming, from which the concept originated, was the largest market at the time but was more of a gamble in investors’ eyes. (Gamers are famously fickle about what makes a game good or not.) Education is a massive industry, but getting into the ed-tech world requires building partnerships with incumbents in many cases and depends heavily on grant money for market adoption. And the third vertical was Training and Simulation. This market segment deviated from the business to consumer (B2C) plan and instead required a business to business (B2B) approach.
My pitch then addressed these research issues and verticals in the form of about 10 or 11 slides. There was a market demand that justified development, I had a minimum viable product that was used in schools and libraries, and I was attempting to build strategic partnerships with education groups, local library jurisdictions, and local makerspaces.
Strategic Partnerships
The Warehouse
One of the partnerships I sought out was with an ed-tech school that focused on STEM education, or in their case, STEAM (Science, Technology, Engineering, Art, and Math). As a startup themselves, they had hosted an IGDA meeting (International Game Developers Association) to spread the word that they existed. Part of the event included a tour of their facility and offering innovation space in their warehouse for independent developers. They specifically taught STEAM through classes rooted in Robotics, Drones, Game Development, and 3D Printing. This was right in line with some aspects of my VR MakerSpace, so I made a handshake agreement to teach game dev classes using Unreal Engine in exchange for use of the innovation space where I could set up a desk and a large room-scale virtual reality rig that pushed the room-scale sensor range to its limits at that time.
This education group also hosted various business community events that brought businesses to their venue for networking opportunities. After pitching my product/services to various members of the business community during these events at the warehouse, I did land a few contracts in the B2B world with a couple different Fortune 500 companies. In the interest of growing the business, I had finally hired my first employee so our team of two could tackle the contract work. This meant I began working on contract jobs and had to delay working on MageWorks in the interest of building out my VR MakerSpace platform. I also continued to negotiate agreement terms with the original folks I had met back at the incubator, as we had not yet come to an agreement on the investment terms.
One Step Forward, Two Steps Back
Throughout the various meetups and entrepreneurial studies, I had the opportunity to pitch for an event that would then select a handful of the pitches to present in front of a panel of investors. The theme was about bringing technology in manufacturing and training to rural areas. We were a great candidate for this final presentation because we had already built a product that trained students and library patrons how to use heavy machinery to an extent (be it in a fantasy environment for edutainment flavor), and one of the library locations we ran events at was in a more rural area. A few months after this event, we found out that we were one of eight groups selected to pitch in front of the panel of investors.
The pitch was a disaster. While my original pitch to get included in the finals seemed to go pretty well, my pitch in the finalist group was pretty terrible. I focused too much on the history of development, and didn’t really dive into the nuts and bolts of the business proposition in true elevator speech fashion. I also found that trying to find strategic partners to build a team was a difficult and fragile process, given that someone could perceive the concept as competition and decide to compete rather than partner.
Failure to Launch
The negotiations with the investor from the incubator eventually fell through as well. The legal advice I continued to receive cautioned against getting into this type of investor relationship. The agreement was very specific about how equity would be issued to the investor over the course of our relationship but was not clear about what I would be getting in return. The agreement lacked clarity with regard to the type of advisory services I would receive from the investor and/or how much time that investor was willing to contribute to the business (considering he was already in this type of agreement with several other startups). He also wasn’t willing to provide any initial capital. To mitigate risk here, I added equity buyback provisions into the agreement that included diminishing returns of the buyback in proportion to the amount of time that passed after the execution of the contract. This would give me the out I needed if the investor didn’t put enough (or any) time into the business – or if the advisory services weren’t up to par with expectations. The investor was (and still is) a talented and ambitious entrepreneur, but I didn’t really want my first delve into the investment world to be a leap of faith. The investor wasn’t willing to sign into this for fear that when additional VC folks got involved, his shares could be bought out. He also felt this type of statement implied a lack of trust, which was a critical part of establishing a foundation with an investment group. In this case, I preferred the philosophy of “trust, but verify” rather than just “trust”. So ultimately, the deal fell through.
With my hands full completing the contract work, converting an instance of MageWorks into more of a universal platform in the form of a VR MakerSpace, and running around to various events demonstrating our now stagnating game, I was also being approached by an increased number of people in the B2B world who were interested in chatting with me regarding our contract work. The B2B world was going through a pretty aggressive pivot into VR integration. It was great to finally see this because VR had been a pretty tough sell in prior years. On the other hand, it also made things more difficult because the folks that were pivoting into VR content creation already had some pretty serious financial backing.
There was a pretty big difference between developing a game for the gaming market, and building a platform for the educational and/or training & sim market, the two of which have vastly different purchasing methods. Developing a game fulfilled that desire for a creative rush of joy rooted in the excitement of building something entertaining on a new platform. I could focus on the study of the impact of motion control in game design and how that influenced the gameplay. While a lot of our art was initially off the shelf for prototyping purposes, it was nice to dive in and start tearing it apart to customize it and give the game a unique look as we established new IP.
Developing a platform (as opposed to a game) turned into swimming with sharks. The library system offered a tremendous amount of support in the form of developer residencies for my team, production studios for some of our mixed reality work, and even partnerships to speak at national conferences regarding how to integrate VR MakerSpaces into the library system. Other educational groups also invited us to their locations/venues as the program continued to grow. But with the usual budgetary constraints, grant processes, and purchasing cycles in the education world, we didn’t receive the financial support we would have needed to continue building the program in a sustainable way purely for the ed-tech market.
The B2B world provided us with some fantastic contracts we completed, but the cost structure and project approach was vastly different. Marketing was challenging because we weren’t authorized to demonstrate any of our contract work (or if we were, it was in a very limited way) due to confidentiality agreements and NDAs.
Lastly, the competitive landscape was changing quickly due to more competitive company pivots, ease of access to consumers, and increased technology adoption as large companies began to strategize how best to integrate VR into production pipelines. It was exciting to be a part of the VR/AR integration process at several companies. Watching how it directly transformed production pipelines was eye-opening.
Less Is More
Regrounding
Over the course of the two years of development, the VR gaming consumer landscape had also evolved quite a bit. A lot of great games were being released that helped establish more of a standard in VR UX design, hardware had improved quite a bit with better tracking, there was great middleware integration that was practically seamless, and VR storefronts were turning into VR homes for consumers to hop into as a launch point for additional content. A lot of what was developed in MageWorks two years prior was no longer relevant in its current form and really needed a makeover that removed outdated or unnecessary content given the standards that had evolved in VR content. MageWorks was turning into “bit-rot,” and it was time to look back at the past couple years and evaluate what to do with the early-access project. I needed to figure out the best approach to formally launch the game – if there was to be a launch. During all of this “platform” development, I had landed a Title License Agreement (TLA) with Sony to get MageWorks onto PSVR. This was a great idea at the time we submitted the design doc for consideration, but given the time that had passed during the business development shift, the console market was nearing the end of its life cycle until next-generation hardware was released.
Strategic Vision
Looking back at MageWorks with a fresh perspective after studying market segmentation and demand has been fulfilling. While it’s “too-early access” release didn’t provide the financial incentive to keep developing (primarily due to my own mistakes in the early-access program), it led to an unexpected journey in entrepreneurship, business development, and networking. I met (and continue to meet) great folks in the education, manufacturing, and energy businesses who are just as excited about what VR/AR has to offer. But it seems like a lot of folks diving into VR are still scrambling to figure out how to make it profitable as a business model. Having attended Oculus Connect 4 & 5, the Facebook Technology team gave an informative presentation that highlighted the current industry obstacles, expectations, and future hardware developments that will have an impact on market segmentation.
In a recent interview, someone asked me “When will VR be mainstream?” I’ve been working on VR projects since the Oculus kickstarter back in 2012/2013, so in many ways, VR has already become a mainstream part of my life, just as it has for the other folks who also took that pioneering step to develop content as independents. But in the grand scheme of things, VR is still young, so there is no rush to complete MageWorks. Listening to the words of the VR greats at various conferences, the key components to creating mainstream VR ecosystems depend heavily on reducing friction for use, the fidelity of the experience, and allowing VR to be a contender in the world of computing productivity and content creation.
So what does this mean for the strategic vision of MageWorks? 20/20 hindsight, MageWorks was an academic endeavor and coincidentally became a game (and almost a platform) about the irony of the cost of education which can be mitigated with the use virtual reality thereby making education affordable and accessible. Being new to the business entrepreneurial scene, I deviated quite a bit from the original concept of MageWorks and was pulled in many directions partly due to my own naivete, but more so with a driving curiosity for what VR can be. Therefore, staying true to the original vision of MageWorks and creating a piece of VR intellectual property that gamers can enjoy is the direction this project is going when time permits.
Next Steps & More Lessons Learned
One of the workshops I attended while at Oculus Connect 5 talked about how to launch a game. One of the key points they made was that launching into early-access was considered a launch. Period. Hearing this, I realized I had no idea that I had launched. My previous education and experience in architecture and software development services had taught me that developing was a process rather than a product. What I didn’t realize was that releasing a game into the sea of content was really the launch of a product, but the minimum viable product in this case had to be pretty polished (not counting minor bug fixing or DLC).
The workshop also talked about strategic approaches into reaching the right market for the product and understanding what the right kind of success metric would be. In my case, while my “too-early access” release didn’t yield financial incentives to carry on the project, the demonstrations of the minimum viable product showed an enormous potential and led to contract work. In hindsight, I believe MageWorks to be a pretty successful product in that light.
So what’s next? I aim to do the hardest thing there is to do in game development: finish the game. I’ll be looking at simplifying everything as much as possible. Improving the combat system, cleaning up code, improving UX, integration of new voiceover audio and tutorials, upgrading the placeholder off-the-shelf art with more intrinsic IP, rounding out the marketing strategy, and preparing to exit out of early access.