Posted on Leave a comment

The IGDA debuts standards, reporting system to curb bad industry behavior

The International Game Developers Association has announced that it’s launching a new reporting-based initiative to curb bad industry behavior. 

The system comes hand-in-hand with a new set of “standards” for the video game industry, which cover topics such as game crediting, crunch and management abuse, and “event diversity,” which covers representation among speakers at video game events. 

Though this new reporting form marks a proactive step for a long-lived organization, an interview with Gamesindustry.biz notes the inherent limitations of such a reporting system, and that the organization’s goals aren’t exactly to publicly shame companies submitted through the process.

“Rehabilitation is better than punishment, in any context,” stated IGDA executive director Renee Gittins. “It’s less about creating an industry blacklist.”

The IGDA’s reporting plan does include some levers for external transparency. The announcement notes that anonymized versions of submitted reports can be accessed by the public and press about amonth after the IGDA has made an effort to notify the company reported in the form. 

Additionally, Gittins states that the IGDA hopes to create a public database tracking these reports to keep developers aware about the conditions at different companies. 

This isn’t the first time the IGDA has announced a ramp-up in efforts to combat bad industry behavior. In 2016, it came out swinging against top-down instituted crunch under Kate Edwards’ leadership. However, we’ve heard concerns from developers in the last few years that the IGDA still may not be properly equipped to curb bad behavior at these companies. 

After all, by its own insistence, the IGDA is neither a trade union, a guild, or trade organization. It’s a non-profit whose primary purpose is advocating for game developers. Though this announcement is a major new step for the long-lived organization, only time will tell if its reporting system is able to enact change among industry bad actors. 

Posted on Leave a comment

Amazon Games and Bandai Namco are bringing a free Pac-Man game to Twitch

Amazon Games and Bandai Namco have partnered on a brand new Pac-Man experience called Pac-Man Live Studio that will be playable directly through Twitch

The free title will allow fans to play and create Pac-Man levels directly in the Pac-Man Live Studio Twitch channel, and won’t require any downloads. 

The Twitch-centric title has been rolled out to celebrate the famous yellow puck’s 40th birthday, and will feature different modes like Maze Creator, Classic Mode, and Endless Mode. 

Maze creator will let people create and share their own chomping grounds, which can then be played and rated by the Twitch community.

Classic mode is the original 1980s version of the title, expect with a high-score board that comprises the entire Twitch playerbase, and Endless Mode challenges four-player teams to work together to beat a never-ending stream of mazes. 

It’s currently unclear when Pac Man Live Studio will actually launch, with Amazon Games simply explaining the title is “coming soon to Twitch.”

Posted on Leave a comment

Blog: Launch day depression (and why i’m over it)

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


After five years of solo-development, I launched my first commercial release Pinstripe on Steam in 2017. So much mental and emotional energy went into Pinstripe, and I’ve kind of blocked out the turmoil that went into it. You might think I’m exaggerating, but I’m not. I’m trying to be more honest lately and that’s me being honest. 

For my next major release, Neversong, things feel a bit different. Actually, they feel a lot different. My hope in writing this is to give indie game devs perhaps a few pointers, and even some hope, that game development doesn’t have to be a miserable nightmare. 

From securing partnerships to more reasonable revenue expectations, I’ve matured into a level-headed indie game dev, just in time for Neversong’s launch. By the time you’re reading this, it’s hit Steam, and hopefully you’ll give it a shot and enjoy it (it’s 15% off cough cough). As for me, I’m already working on my next project, drinking beer, listening to lofi, and grateful just to be making games, regardless of Neversong’s performance. So, here are three reasons why I’m not a miserable mess this time around:

This is me right now. Promise.

Most indie game devs out there are basically gambling. We spend our time throwing money (remember, time is money) at a project we think miiiiiggghhhhtt be successful, but for many of us, turns out to be a money pit. And it’s addicting too, isn’t it? Dreaming of becoming the next Edmund McMillen, Notch, or Jonathan Blow. In 2014, making and selling indie games was so much easier than it is now. With only 1,771 games released in 2014 on Steam, over 9,000 games were released in 2018. According to Kotaku, the average solo game dev in 2014 made about $11,812. Indie teams faired a bit better with $50,833. I can’t imagine it’s gotten any better 6 years later. In fact, I’m sure it’s become exponentially worse considering the amount of competition.

This is the sad reality.

After Pinstripe’s mediocre release, I knew I needed a reliable source of income, generated almost automatically, if I was to make it through Neversong’s development without going absolutely crazy. I remember putting together a pie chart on my garage office white board, and crossing my fingers that it would work. It has actually.

With a consistent six-figure annual income from various sources, I was able to make Neversong without worrying about whether it’s launch day would save me from losing my studio, my home, and any credibility I had with my little growing family. Keep in mind some of these income sources are things like Kickstarter and publisher advances. I’ve made sure to split these up over more than several years of making Neversong. Also, please keep in mind all of these income streams started popping up after the Neversong Kickstarter campaign launched, as I realized the campaign, honestly, had not raised enough to support the game’s entire development. This is just an estimation, so take it with a grain of salt: 

Note: I can’t show actual numbers here. This would disclose private information from contractual agreements that included NDAs. Regarding Kickstarter, please note the final Kickstarter campaign funds raised were actually split up to a degree among both Serenity Forge, the project publisher and development partner, and I.

If I had not pursued publishing deals, YouTube sponsorship deals for weekly videos on my YouTube channel, a small drip of Patreon support, YouTube ad revenue, and a few small gigs as an advisor and freelancer, I would have been depending solely on the pink: Pinstripe sales. Remember, running a studio is more than just paying your rent and grocery bill. The costs slowly add up, so having reliable income streams can keep you sane. Fortunately, I know that if Neversong under-performs, I’ll be just fine. Mainly because of reliable income streams intentionally pursued and planned. In all honesty, Apple has provided a bit of a cushion for my studio. However, I have not included those numbers in this pie-chart, because, quite frankly, it came about at the tail end of Neversong’s development. Additionally, considering most dev’s won’t be working with Apple, I’m trying to show the various drips of income outside of Apple, and thankfully, my studio will be OK even without an Apple deal.

Revenue Expectations

I’m sane as I write this article not only because I know I’ll be OK financially due to various drips of income, but also because I have a decent idea of what revenue should look like, not only on launch day, but also long term. 

When I launched Pinstripe in 2017, part of me thought I would make a million bucks, but a huge part of me planned on making nothing. With a baby girl on the way, a mortgage, and a wife who was about to quit her job, you can imagine the mounting pressure and worry about whether Pinstripe would be able to provide for my family. On launch day, it became increasingly clear that, after the Steam cut and publisher cut, the revenue would not be enough. After a hefty (yet fair) publisher recoup I was left with less than what was needed for my annual salary.

Basically, after the first month of launch, we had grossed around $50,000 (US). Meaning, Steam took $15,000, leaving $35,000 left over to distribute to me (the developer), and my publisher. 

Wait. 

Not really. 

Remember the publisher fee was to be recouped? So yeah. I made nothing for a couple months. As you can see below the sales slowly flattened, and I was devastated. 

What I didn’t understand is that future Steam sale events were kind of like mini game launches. Various pops of revenue came throughout the year, especially during the Holidays, and we also participated in various bundles (including Humble Bundle), and even a Steam daily deal, which is that giant spike below. That was a great day!

Additionally, I learned that revenue slowly add up from various platforms. It’s amazing how a small drip of revenue can become a waterfall once your game is on pretty much every platform.

Nintendo Switch performed wonderfully when we launched a year later. PS4 and Xbox were not so great, though, but honestly I’m not surprised. So, what I realize now is I should have been at peace during Pinstripe’s launch, I just honestly didn’t know what to expect. 

All that said, for Neversong’s launch, I’m at peace knowing if launch doesn’t go perfectly, the game will still sell plenty of copies with the various Steam sale pops of revenue, and likely match or out-perform on Nintendo Switch. It’s all about the long game, so don’t panic when things don’t play out exactly as you would have hoped on launch day! In the end, Pinstripe has actually grossed a decent amount, and I’m more than proud of it. I know that at the very least, Neversong will likely perform similarly, and that’s comforting.

Partnerships

The stress of launching a game solo is insane. It’s honestly not healthy. Some people are made to do this. Not me. 2017 was one of the hardest years of my life, and I just wasn’t willing to do that again for Neversong. Now, I’ve got a team of developers going to war with me. I’ve partnered with a developer and a publisher, Serenity Forge. In 2017, I pitched them a couple sentences over the phone regarding Neversong, and they immediately loved it. They agreed to publish and also develop Neversong, in exchange for a reasonable rev share. I would be the artist, musician, story-teller, game designer, and lay out the levels, and they would code the game from scratch per my direction. I also hired out several interns, and even worked with an ex-Blizzard artist Peet Cooper, whom the protagonist of Neversong is named after. It’s been an amazing experience, and we’re all friends because of it. It feels amazing knowing Erik, Z, Kevin, Kersti, Hector, Tripp, Phil, Adam, Peet and myself are all in this together, and working hard to see a successful launch.

Peet Cooper’s amazing cut-scene art!

Wait. Hold on. I was about to conclude here, but I forgot something!

Apple came into the development cycle at the eleventh hour, and funded a mobile port, along with 14 languages, and a ton of upgrades and updates to the game. It’s been amazing working with them, and I’m thrilled to see Neversong coming out on so many platforms. Yes, their support makes this launch 100x easier, but I can honestly say my maturing as a game dev has really given me some peace, especially the various dripping income sources outside of Apple.

In conclusion, this launch is heavenly. It just feels totally different, and it’s all because I’ve been resilient enough to build various income streams, wise enough to look at long term data, and humble enough to ask for help from various partners.

If you’re interested in playing Neversong, it’s 15% off on Steam right now! I’d love to hear your thoughts on the game. 

All the best!

Thomas Brush

Posted on Leave a comment

Fortnite is morphing into a movie theater with help from Christopher Nolan

For its next trick, Epic Games battle royale shooter Fortnite will morph into a virtual movie theater to host a showing of an unnamed Christopher Nolan movie. 

The news comes after the latest trailer for Nolan’s upcoming movie Tenet premiered in the popular online title. 

Since launching back in July 2017, Fortnite has evolved into a bona fide social platform. The title has previously played host to massive virtual concerts featuring acts like Marshmello and Travis Scott, while the recent opening of a new combat-free ‘Party Island’ has given the game’s 350 million players a place to kick back and shoot the breeze.

A variety of major movie tie-ins have also brought big-screen characters from the likes of Star Wars and The Avengers to the builder-shooter, but this is the first time players will be able to watch a full-length feature film in-game. 

The film will begin screening in Fortnite later this summer, and will be a completely free to all players. Previous events like the Travis Scott concert pulled in over 27 million unique logins across five scheduled shows, so it’ll be fascinating to see whether the Nolan flick can generate a similar response.

Posted on Leave a comment

ezEngine Free and Open Source 3D Game Engine

ezEngine is an open source 3D game engine with a complete editor written in C++ using the Qt framework.  It is hosted on GitHub and available under the MIT source license.

Details of the ezEngine:

ezEngine is an open source C++ game engine in active development. It is currently mainly developed on Windows, and higher level functionality such as rendering and the tools are only available there, but the core libraries are also available for other platforms such as Mac and Linux.

ez is built in a modular way, enabling users to either use all available functionality, or to pick and choose individual features and build the rest yourself. Larger features are implemented through engine and editor plugins and can therefore be easily removed or replaced. For instance sound (Fmod), physics (PhysX) and particle effects are all provided through runtime plugins.

The ezEditor is a full blown editor used for editing scenes and importing and authoring assets.

ezEngine documentation is available here, while Windows binaries are available for download here.  You can learn more about ezEngine in action in the video below.

GameDev News


Posted on Leave a comment

Blog: Building an MMO screensaver

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


We’re in strange times right now and as a way to help people a good friend and colleague created the Alone Together Jam to give folks a creative outlet. The jam would run for the entire month of April to let folks work at a relaxed pace. As a prompt the jam provided three words: Horizon, Twain and Ambedo. Fortunately they also included links to the words … ambedo was both a completely new one for me and also the cornerstone of my idea.

So what did I make and what am I going to talk about? I made an MMO … an MMO Screensaver. The game, Through my window, doesn’t have any tasks for the player to complete; there isn’t anywhere for them to go or to be; there’s just a street on a rainy night and a window to watch it through. And as for what I’ll be talking about? I’m going to talk through how I came up with the idea and how I designed and built the key systems.

Screenshot of Through my window showing the main view looking out through a window onto a street on a dark and rainy night with another building directly opposite.

Thinking of ideas is never the hard part. The hard part is picking one idea and developing it into an interesting concept that is achievable within the time constraints. The prompt words helped a lot with idea generation particularly ‘ambedo’ and in particular this part of the definition “A kind of melancholic trance in which you become completely absorbed in vivid sensory details—raindrops skittering down a window …”

That description of watching rain drops on the window immediately conjured up for me a memory of one of my favourite things about where I live. My main windows look out onto an intersection. At night, and particularly on a rainy night, it’s incredibly peaceful to lookout and just watch the street through the rain on the window. The drops slowly rolling down the window making all the lights flare when they intersect. With that I had the base of my idea. I knew it would be at night, it would be raining and a core aspect would be looking out the window. What else would you do though?

An animation showing the final result of the rain shader. Drops of water roll down the window leaving trails behind them. The window is slightly fogged except where the rain has been.

I didn’t want the player to leave the apartment and I wanted to keep their eyes largely fixed on the window so whatever they did had to be through that window. I also wanted there to be an interaction with other people. Which gave rise to the idea of maybe … maybe … I could have multiple people be in this world at the same time, each in their own apartment, isolated but also connected. I was familiar enough with databases that I understood how to do that from a technical point of view. And I ran the numbers to work out the worst case bandwidth usage. It all fit. I worked out I could have a shared world with around 200 people in it. I had the core of my idea, a shared world where every player was focussed on their own window onto a rainy street at night. The next step was to make sure the player had a rainy window worthy of their attention.

I knew that I wanted a window with rain running down it and I knew I would need a shader to do it. I also knew that while I can make basic shaders and I knew that given time I can make ones with some complexity I also knew that this was many many levels above anything I had tried to make before. I started some research on it and was very fortunate early on to find these video tutorials from The Art of Code.

In progress animation of the rain shader in a test scene. The fogging on the window is set very high blurring the background substantially. Rain drops roll down the window clearing the fog.

The effect was exactly what I was wanting and the tutorials were excellent. The techniques and solutions used in the tutorials were not ones I could have come to on my own. The gaps in my shader knowledge were simply too large. But after the tutorials it all made sense. I can understand what the code is doing and why. For me that’s the mark of a great tutorial. I learned how to do something I had never done before and I understand how the pieces fit together and how I might use them in future.

I had my rainy window, the next step was to work out what the player could and would do.

As I started detailing out the rest of the game I was very adamant about keeping the interactions simple. Trying to create a game with a shared world for 200 people would be ambitious enough at the best of times. In the midst of a pandemic, while still working full time, and while trying to make sure the trimester closed out smoothly for my students and my team …. I needed to keep them very very simple. Where possible I like to put myself in the player avatar’s shoes to work out what they would do.

If it’s a rainy night how would I try and communicate with someone in the building opposite me that I didn’t know. I can’t call, text or email them. I can’t hold up a sign, no one could read it through the rain. And yelling would be rude. I could turn my lights off and on though. And maybe, just maybe, if both of us knew Morse Code (I don’t) or could at least recognise and find a guide (that I could do) then we could communicate. I had my player verb … my only player verb: toggle lights.

I also decided to only allow the player to look around (ie. no movement). I wanted to keep people focused on the window so I anchored them in that spot. I also removed all of the furniture apart from a single rug. Looking back into an almost entirely empty apartment would look quite strange though. I did consider restricting the camera angles but unless I heavily restricted them the player would always be able to see some of the apartment. Instead what I did was setup a custom shader to darken the environment behind the player.

A screenshot showing the visual layout of the Fade to Black shader.

The way the shader works is:

  • The game passes the player’s location and the forward vector (Vforward) of their spawn point (that way it’s consistent) to the shader.
  • For every vertex the shader calculates a vector from the player to the vertex Vp2v
  • The shader calculates the dot product of the vector from the player with the forward vector Projection = Vforward • Vp2v
  • The first thing done with the Projection is to flip the sign of it (so positive values were behind the player and negative in front).
  • The shader then used two distance thresholds: Start and End and converted the Projection into a percentage between them (with the values clamped into a 0 to 1 range).
  • That percentage was then used to scale the normal map strength (from full strength at the start to zero at the end).
  • It was also used to scale the colour from the texture lookup (from full colour at the start to black at the end).

The end result was the apartment behind the player is fully hidden and also looks a bit ominous in contrast to the more inviting view out the window. I now had a player that was locked in position, could look around, toggle the lights and their apartment being empty was largely hidden. Now I just needed a world that felt alive.

If player’s were going to be spending the majority of their time looking out of the window then there needed to be a reason to. Sure, there might be other players but there was no guarantee of numbers and folks might be playing in offline mode. I needed there to be things happening regardless. I also wanted to try and achieve a level of the shared experience even if you were in offline mode. That meant I needed a way to synchronise, as best as possible, everyone playing the game at the same point in time … without the need for any communications.

Using time, in particular UTC time, was a logical starting point. It would, assuming folks had the correct time and timezone setting, mean that multiple people scattered around the world would have the same UTC time. So I had a way to synchronise everyone regardless of where they were or what mode they were playing in. I still wanted there to be variation though. I didn’t want the same thing to always happen at the same time. If you ran the game for an entire week I wanted the world to be changing throughout that time. You might see the same event multiple times but not in the same way. So I still needed randomness, it just needed to be synchronised.

A screenshot of the Unity Inspector showing the configuration for one of the lightshow events and for one of the vehicle events.

The solution was to use different components of the UTC time to seed the random number generator … and … to very carefully control when segments of the code were allowed to use randomness. How this unfolded from an implementation point of view was each variant of an event has:

  • A rigid set of day, hour and minute changes in which it can occur (so that I can permit or inhibit overlapping events).
  • A mix of components of UTC time (day in week and/or hour) as well as additional custom values that are combined to seed the random number generator.
  • A setup pass that when activated seeds the random number generator and performs all random rolls for the event in one go so that I can rely on consistency with the random rolls.

That setup worked out well, the events would activate consistently and the setup made it straightforward to configure a range of ones including:

  • Thunder from different locations (no visible forks of lightning but you do get the preceding flash of light).
  • Cars driving by (different vehicles and tracks).
  • The procedurally controlled buildings will put on a light show occasionally showing an image or text.
  • The lights in the procedurally controlled buildings can also change every hour on the hour.
  • And one final event inspired by someone in my building trying to organise everyone in the building to sing YMCA from their balconies at the same time (it did not get high participation but folks walking by seemed to love it).

There were enough events that every few minutes you should see or hear something and you may get overlapping ones as well. I also wanted the intensity of the rain and wind to vary with time but very smoothly. That was one of the easier problems to solve due to having done similar things in the past. I created an intensity parameter and fed that through to the audio engine (WWise) and set it up to blend between different looping audio based on that parameter. Now I just needed to generate my intensity value (from 0 to 100).

A screenshot showing how the intensity of the wind varies during a single day. There are short and long term variations that occur within the day.

For that I combined a couple of sine waves based around the UTC seconds in the day (including milliseconds). The first (long period) wave would complete a full cycle over a 24 hour period. I also wanted some short term variation so I layered on a second (90 minute period, low amplitude) wave to modulate the value of the first one. The end result was an intensity parameter that varied continually throughout a 24 hour period with local variations in intensity throughout the day. With all of the pieces in the world finally felt the right level of ‘alive’. Things weren’t happening rapidly but they were happening consistently and regularly enough that a few minutes of watching would result in you seeing an event. Now the ridiculous-for-a-game-jam part … adding multiplayer.

Having multiple people be able to inhabit the same world was one of the design goals I had for Through my window from the very beginning. My previous experience with the multiplayer side of games is very limited. I’ve worked on projects that had multiplayer but I’ve never worked on the networking aspects. What I have done previously is have some of my games communicate with a server to store and retrieve statistics in one case and in another to store and retrieve messages.

For Through my window I felt that I could get away with a similar process so I ran the maths on what the data transfer would be to see if it was feasible:

  • First the amount of data:
    • There were 200 apartments and for each apartment the state was a single boolean (the light). That meant I needed 200 bits (ie. 25 bytes) to convey the entire state.
    • If I went for a simple (but less efficient) method of encoding that data I could transmit it as a hexadecimal string. So my 25 bytes now becomes 50.
    • As a bit of future proofing I also wanted to add in a version number and some padding taking the total number of bytes for the world state to 54 (worst case).
  • Next was looking at the data rate:
    • I wanted any changes from a user to be visible within a few seconds. I decided to go for a conservative limit of 5s.
    • That meant the state would be sent 12 times in a minute or 720 times per hour
  • Combining the information meant (assuming worst case of continuous use) I’d be sending roughly 39 KB an hour per user.
  • Hosts typically give bandwidth limits in per month so looking over the course of a month:
    • Assuming worst case of continuous use I’d be transferring 28 MB per user in a month for sending just the world state.
    • The other communications from the user to and from the server are small and low rate so will be much less than the 28 MB.

Assuming I had 200 users continuously for the month (nice if it happened but unlikely) I’d be looking at 5-6 GB per month which was well within the bandwidth permitted. So bandwidth wise even with a simple encoding the bandwidth requires for myself, and even for end users, were very manageable. To the extent that if needed I could ramp the refresh rate up to every second and still remain comfortably within bandwidth limits. The maths checked out, now came the (genuinely) fun part … making it work.

Seeing how the maths worked out gave me a lot of confidence that I could proceed using a similar setup to previous solutions: a MySQL database with a PHP script as the public interface. Both were tools I was familiar with and I had a reasonable understanding for how I wanted to approach it. There were only a limited number of operations that I needed to do:

  • Request a lease
  • Retrieve the state of all lights
  • Set the state of my light
  • Renew my current lease

Retrieving or setting the light state and renewing a lease were straightforward. They were simple operations (SELECT/UPDATE) and would use a server issued unique ID when requesting the operations. Requesting the least was the trickier one. The operation needed to be atomic (ie. so it can’t lease the same apartment to multiple people); it needed to pick a random apartment; and it needed to provide back the details of the selected apartment. All of which were a bit more complex than things I’d previously worked with.

Fortunately, I managed to find some helpful resources that let me put together a single SQL statement which would pick a random apartment (by ordering by RAND() and limiting to 1 result). The same statement let me retrieve the apartment info (by using a nested SELECT statement into a variable). I wrapped all of that up into a stored procedure giving me a single function that would find a random apartment, lease it, turn on the lights and pass back all of the information. The end result looked like this:

 # find a random apartment in the first free realm # - also sets the lease GUID # - also turns on the lights # - apartment expiry set to 2 minutes from now # - also retrieves the apartment ID and realm ID UPDATE `world` SET lease_expiry_time=DATE_ADD(UTC_TIMESTAMP(), INTERVAL 120 SECOND), light_state=1, [email protected]_unique_id, apartment_id = (SELECT @leased_apartment := apartment_id), realm_id = (SELECT @leased_realm := realm_id) WHERE lease_guid IS NULL ORDER BY realm_id, RAND() LIMIT 1; # populate the apartment ID, lease GUID and realm ID output variables SELECT @leased_apartment INTO leased_apartment; SELECT @lease_unique_id INTO lease_unique_id; SELECT @leased_realm INTO leased_realm; # populate the building name output variables SELECT b1_name, b2_name INTO building1Name, building2Name FROM `realms` WHERE [email protected]_realm;

One thing you’ll notice in the code above is the mention of realms. Although it was unlikely I had to consider the possibility of if the game took off and more than 200 people tried to play it at the same time. I had designed the game side to quietly fall back to offline mode so worst case that would work. However, I wanted to go all in on this and decided to setup multiple realms.

I was surprised at how little needed to be changed when adding in realm support.

  • On the leasing side it sorts first by realm index and then by the random value to avoid players being fragmented across the realms.
  • No changes were needed for setting lights as those already work on the unique ID issued for the lease.
  • Retrieving the lights did need to change.
    • At first it was sending through every light … for every realm and was making the game very unhappy (plus sending a lot of unnecessary data).
    • That was easily fixed by the light request command sending through the player’s realm ID which returned the data transfer to the normal levels.
  • Creation of the realms was handled by stored procedure so that if I needed to add or remove a realm it was doable in seconds with a single command.

The server side was now fully up and running and able to scale up if the demand was there. Not only that but I had a really solid set of infrastructure worked out that I could use for future games.

The Alone Together Jam for May is running now and I had considered joining in again. Once again the prompt words evoked a lot of interesting ideas. I needed to take a break and finish some other projects though. Which is fortunate because my idea was going to be a VR art gallery …. that was also massively multiplayer. It’s probably for the best that I’m not doing that 🙂

I do plan to re-use and expand the infrastructure that I’ve put together. At the moment it is very tailored to the game. I’d like to redesign it so that it can be used in a more generic way and so that it is easier to add commands. The end goal being an infrastructure where from the Unity side it is no different to calling a function and supplying a delegate for handling the response. That might need to wait till the next MMO I make 🙂

If you want to check out Through my window it’s available here.

Posted on Leave a comment

The Pascal’s Wager giveaway is now over

May 22, 2020 The giveaway has now ended and we’ve dispatched the free code to the lucky winners. Check your email inbox to see if it’s you!

Pascal’s Wager achieved what we all thought was impossible: making Dark Souls or Bloodborne work on mobile. And it achieved it with aplomb, providing a visually-stunning portable experience that’s absolutely dripping with darkness. The enemies are tough, the environments encourage you to explore, and the combat is just the right level of tricky and fun to encourage you to keep pushing on.

We absolutely loved the RPG, which you can tell from reading our Pascal’s Wager review. We called it “A bravely ambitious game. Worth playing if you are not easily frustrated and prepared to use a separate controller.” Slight control hiccups aside, you should forgive your friends for mistaking it for Bloodborne on your phone.

To celebrate our love for Pascal’s Wager, we gave it away for free to our lucky readers. We had 25 iOS codes up for grabs, and we invited you to fill in a simple form below to get in with a chance of winning. Android folk: Pascal’s Wager isn’t out just yet on your platform, but it is coming. Sorry you miss out on this particular giveaway; we’ll make it up to you.

The giveaway is now closed, and we’ve sent the iOS codes out to the lucky winners via the email address you shared when you filled out the form. Please check your inbox to see if it was you!

If you were unlucky this time, you can go ahead and grab Pascal’s Wager from the App Store right now.

Posted on Leave a comment

You could be a beta tester for Warhammer Quest: Silver Tower

Perchang has announced that it is on the lookout for beta testers for the upcoming strategy game, Warhammer Quest: Silver Tower. Based on the popular Games Workshop board game of the same name, Silver Tower doesn’t take place in the classic Warhammer Fantasy setting, but instead uses the Mortal Realms of Age of Sigmar. In a similar vein to other Warhammer games like Vermintide or Chaosbane, Silver Tower revolves around a band of heroes from a variety of different races who make their home in the world.

Each of these heroes has a particular combat focus, so it’s safe to say that the Fyreslayer – the axe wielding Dwarf we see in the trailer – is a melee blender, whereas the armoured and shielded Stormcast will more likely trend towards tankiness.

The campaign sees you and your heroes face off against monsters from throughout the realms, as the Gaunt Summoner – who we guess is that guy with all the eyes – challenges you to a number of trials. Silver Tower will launch with over 100 stages to play, so you’ll have no problem finding foes to crush.

Warhammer Quest: Silver Tower has ten upgradable heroes, but we’re really excited to see how a Warhammer game using Age of Sigmar as a setting might change up the usual Warhammer hero roster of elf, human, wizard, and dwarf.

[embedded content]

Alongside the trials set by that Tzeentch-y looking dude with the eyes, there are challenges and trials to complete, and even full-on solo trials for those of you who actually want to punish yourselves – hey, who are we to judge?

If that all sounds good, you can register interest for the beta by popping an email over to [email protected] A member of the team will then get back to you providing beta details, then fingers crossed, you’ll be a Sigmarine stomping on daemon spawn in no time. Praise the emper- I mean Sigmar.

Posted on Leave a comment

Don’t Miss: A classic game postmortem of Westwood Studios’ Command & Conquer

Four of the minds behind Westwood Studios’ 1995 release Command & Conquer sat down at GDC 2019 to share an hour-long deep dive into the creation of the influential real-time strategy game. 

In that talk, Westwood Studios co-founder Louis Castle, along with the game’s lead designer Erik Yeo, composer Frank Klepacki, and VP of product development Steve Wetherill walk through the early days of the studio and how the landmark strategy game came together.

It’s a conversation that runs through the conception, development, and design of Command & Conquer, all while offering insights and anecdotes that may be helpful to fellow game developers. 

In addition to this presentation, the GDC Vault and its accompanying YouTube channel offers numerous other free videos, audio recordings, and slides from many of the recent Game Developers Conference events, and the service offers even more members-only content for GDC Vault subscribers.

Those who purchased All Access passes to recent events like GDC or VRDC already have full access to GDC Vault, and interested parties can apply for the individual subscription via a GDC Vault subscription page. Group subscriptions are also available: game-related schools and development studios who sign up for GDC Vault Studio Subscriptions can receive access for their entire office or company by contacting staff via the GDC Vault group subscription page. Finally, current subscribers with access issues can contact GDC Vault technical support.

Posted on Leave a comment

An extensive look at Maxis’ short stint in serious simulation games

“Almost nothing they developed was ever released to the public. But their software raises questions about the role we want games to play in society.”

– Phil Salvador shares the story of Maxis Business Simulations, built from his own years of interviews and research

If you’ve got time for a long read about a beloved game maker’s foray into for-hire simulation games for the likes of Chevron and the EPA, The Obscuritory has you covered. 

Game history researcher and librarian Phil Salvador has published his incredibly in-depth report on Maxis Business Simulations, a SimCity-encouraged endeavor in which Maxis took aim at developing simulations for business use rather than entertainment.

Those games were, largely, built on the same framework as SimCity, but aimed to take a less fun-focused approach toward simulation. The first was SimRefinery, a game commissioned by Chevron to model and teach how different systems in an oil refinery interacted with one another. That initial project opened the door to other simulations, often with lofty goals, pitched to model things like the impact of pollution or the complexities of the health care system to varying degrees of success.

Salvador’s report in its entirety combines snippets of old digital artifacts with his own interviews with those involved collected over the span of several years. By doing so, he captures examples of games like SimEnergy, SimEnvironment, and SimSite that never truly saw the light of day or had their physical copies outright destroyed and otherwise erased from history.