Thoughts on DevX

The time for talking back to devs that use Game DevX.

I know, so why didn’t we talk about it earlier?

Well, maybe for two reasons:

We did not know anything about Game DevX.

I thought we would talk about it if they made a decent effort to explain the process, but it looks like nothing like that.

They make an exception to their game DevX policy, and then try to change it for us, to make the conversation even more hostile.

First impressions

I am on Team Winxor, a very awesome indie developer that has a fantastic team of great testers, an awesome game in progress, and just a game that everybody really loved.

When we first showed off our game, it went down like a ton of bricks so we just stuck to the plan.

At first, we had to write our way through a lot of technical stuff.

For example, when you write a test, it’s like making a movie for your friends. They get it, they like it, then they go to the theater and see it anyway. Your test is going to have a long list of people, so you need to know what things they can understand to enjoy it. It’s a lot of tedious learning to get to the point where you’re able to write to the screen, and it takes time.

And that’s where the game code comes in.

You write all the game code for your game. That game code is then shared with other teams (who also have the code), and everyone uses that as a starting point when writing your code, because you’re writing code for everyone. It’s like a code library that’s completely isolated from everyone else, meaning you can control everyone’s tests. There are actually very powerful test frameworks like Jasmine, which I recommend as you start to learn the ropes of how to approach game development, so it’s great tool to start with.

So when someone wants to write a good game, which we all do, it’s pretty easy to write it.

That’s good for a number of reasons, in different areas:

It makes your lives easier. The other team will already have the code for you, so there’s no need to dig through their codebase to make sure that nobody can just rip to save an hour of development time.

It’s fun. You can start out with simple, yet powerful code, then build up from there, learning more about the systems that you’re writing within the game.

But why should we keep it so simple?

We’re building a game for all audiences.