Exploit: Zero Day - Headless Swarm, the first season

The Majesty of Colors Remastered - Coming early 2017

Tag archives: technology

Unity 5.6.3 Issues with Color Spaces and Texture Formats

Unity 5.6.3 Issues with Color Spaces and Texture Formats

One step in our polish phase of remastering "(I Fell in Love With) The Majesty of Colors" was to make sure all devices are consistently showing the game with the correct colors. If you aren't a developer (or not one of multiplatform games), you might be surprised at how differently devices can display a game. We ran into an interesting issue in that process.

...

Continue reading ⇒

DevOps in Game Dev: ChatOps for Real With Lita and Dialogflow

DevOps in Game Dev: ChatOps for Real With Lita and Dialogflow

This is the fifth part in a series on applying devops principles and practices to game development. You can read the first post in the series, and see the entire series under the devops in game dev tag.

In our post on what the devops philosophy is, we wrote about revisiting workflow annoyances periodically. Sometimes you get more time and/or money. Sometimes you learn of an easy way to solve a problem.

There's something that got a lot easier for us recently: chatops.

"Chatops" is a trendy word for a subset of devops that focuses on streamlining work using extensible chatbots (e.g., Lita, Hubot, and Errbot) in team communication tools (e.g., Slack, HipChat, etc.). We use Lita on Slack, so I'll stick with those as concrete examples.

As a simple-but-nice examples, you might ask Lita to run an automated build for you, and it will connect to Jenkins and run the build you ask for. You don't need to leave Slack open a tab, log into Jenkins, find the job you need, and run it.

Something really important that well-implemented chatops provides is the ability to add context-appropriate information to conversations that are already happening.

...

Continue reading ⇒

DevOps in Game Dev: Project Planning

DevOps in Game Dev: Project Planning

This is the fourth part in a series on applying devops principles and practices to game development. The first post in the series is here, and the entire series can be found under the devops in game dev tag.

In our post on retrospectives, we wrote about taking note of lessons learned (good and bad) after emergencies or breakpoints in your project—after you deliver a feature, or at the end of a sprint or some unit of time. But how do you know what a good breakpoint is? How do you actually incorporate what you've learned in a retrospective into your future work?

Through effective project planning.

...

Continue reading ⇒

DevOps in Game Dev: (Blameless) Retrospectives

DevOps in Game Dev: (Blameless) Retrospectives

(This is part 3 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)

In our post on devops philosophies, we emphasized the continuous process of learning and revising, and said that a good place for that to happen is in retrospective (or post-mortem) meetings.

So what is a retrospective?

...

Continue reading ⇒

DevOps in Game Dev: The Philosophy

DevOps in Game Dev: The Philosophy

(This is part 2 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)

If nothing else about this series proves directly useful to you, take this one thing home:

Don't get stuck in a local maximum.
Michael DeHaan, creator of Ansible

Keep moving and keep improving.

Very often, we find a system for ourselves that works and stick with it. We just get used to things that are initially annoying or rough, even if we know there might be a “fix” for it. As a result, we accept failure in some areas, telling ourselves “that's just how it is.”

We shouldn't just accept those irritants and move on. We should continuously reassess whether those need to continue to be rough spots.

...

Continue reading ⇒

DevOps in Game Dev: The Beginning

DevOps in Game Dev: The Beginning

In early November, I attended and gave a brief talk at DevOpsDays Charlotte 2015, a conference dedicated to exploring ideas around the modern movement of operations informed by and possibly run with development practices.

The typical, most obvious example of devops is the automation of builds and deployments of websites ...

Continue reading ⇒

The Technology of Exploit: Zero Day

The Technology of Exploit: Zero Day

The original Exploit is a game written in ActionScript 3 (Flash) that lives entirely within its Flash container on a web page, whether that be on our site or a Flash portal.

With Exploit: Zero Day, we want to build something browser-based, but more than just puzzles. The puzzles themselves are still in a box on a web page, but that's not the entirety of the game — nor is there any Flash involved.

It's time for Exploit to spread beyond its box and become more complex and social, and that means changing the technology. ...

Continue reading ⇒