Reality is a Game

Game thinking from Adam Clare

Tag: codePage 1 of 2

On Game Making Resolutions for 2014 And Learning To Code

by

On 06/01/2014

In Events, Video Games

It’s 2014 and if you’re into making games you may have made one of those resolution things related to making more games- I know I did!

I want to push myself and have thus opted to engage in the One Game a Month Challenge. The challenge is to release a game a month – not to create a brand new game every month. In this regard it’s different from the game jam model of starting fresh. So if you have games that are half finished (like me) then you can complete them and have that count. One of the nifty things about the challenge is that it’s like a game itself in which you can earn XP. Presently, I’m at level 4 for just filling out my profile.

One thing that I particularly like about the game a month challenge is that it’s not focussed on only video games. You can make board games (pro tip: Board Game Jam!) or games set in playgrounds! Whatever your heart desires.

It looks like many on Twitter have also thought that entering the self-imposed challenge is a good idea too. It’s never too late to join!

For those of you who are debating making games yourself, I implore you to take a look at the easy to use resources I’ve listed which include things from art to code to sound to more!

If all goes according to plan you too can be a indie game developer by the end of 2014! When in doubt, be sure to read how to be a happy indie game developer. Stay positive and remember that even a little time spent on making your game brings it that much closer to completion.

At the very least, you can help make 2014 not copy an awful year for technology that 2013 was.

Coding technology is complex

Speaking of technology, it obviously relies on code. Part of me wanting to attempt a game a month is to up my abilities in the obscure world of coding.

Coding is obviously something that needs to be learned and there are many place online to learn it. What I’m interested in is what people had to say about the process of learning.

Late last year Cecily Carver of DMG fame posted Things I Wish Someone Had Told Me When I Was Learning How to Code and it’s excellent! Here’s just one of many great points in the essay:

I’ve found that a big difference between new coders and experienced coders is faith: faith that things are going wrong for a logical and discoverable reason, faith that problems are fixable, faith that there is a way to accomplish the goal. The path from “not working” to “working” might not be obvious, but with patience you can usually find it.

In /r/LearnProgramming one person asked how self-taught developers learned how to code. The best response is applicable to anyone learning anything new:

You’re going to be frustrated, feel like you’re stupid, and get completely overwhelmed many times. The only difference between that person with that app/game on the store and you is that they didn’t give up.

Coding is (socially) complex!

It’s so often said in the tech community that coding will solve all problems and guarantee you a job. This is not the case! Indeed, over at Wired they have an article Pushing People to Code Will Widen the Gap Between Rich and Poor which further complicates this technopostivist worldview.

All that compiles is not gold. Coding is only a panacea in a world where merit is all it takes to succeed. In other words, a starkly different world from the one we actually live in where social structures, systemic biases, and luck may matter more.

On this “code solves all” ideology all I can really say about it is that it’s important to understand the core logic behind programming. For now, I’m going to continue to learn and make more games.

This turned from a short post into a long one that really should divided into multiple post for clarity. Oh well.

Time to go make games!

Meaningful Gameplay and Separating it From Code

by

On 10/09/2012

In Design, Video Games

Designing a game and coding a game often get tossed together when talking about games. I often run into people outside the game world who don’t believe that one can design a game without knowing how to code. Even to those in the gaming community the distinction between designing and coding can be hard to discern.

Over at Gamasutra there are two articles related to both that I want to mention. One article is focused on the technical process of making a game while the other is focused on designing meaningful gameplay.

Meaningful play is a concept that can be interpreted to mean that the player is playing the game for a meaning (purpose) outside of the game itself like learning how to code or acquiring a new skill. The term can also be applied within the game itself, as in the choices that a player makes has to have meaning within the framework of the game.

Evaluating game mechanics for depth looks at the concept of meaning in a game but does so in a way that I feel is still lacking. It’s a good step on a path towards a more thoughtful debate on assessing meaning in a game; however I would have taken a different approach: instead of working from a game-focused approach towards a concept of meaning I would of looked at what meaning means then take a fitting philosophical approach from there and apply it to gaming.

To me, it describes a sweet spot — that point during a game where the player can repeatedly display his mastery of a game mechanic. Challenges never stay the same long enough to be boring and yet they also don’t change so fast that the player can’t enjoy his mastery over the game.

Clearly this “depth” is something we want to achieve in many of our mechanics, but it’s often less clear how to obtain it.

In my experience, in order for a game mechanic to be deep it needs two very important things:

It needs clear objectives, so the player knows what he has to do to succeed. Confusion and obfuscation tend to make players feel like a mechanic is LESS deep once they find themselves needing to experiment randomly to win.
It needs a variety of Meaningful Skills that you, as a game designer, can use to create good challenges for the player and that the player in turn can use to achieve mastery over the game.

So once we have gameplay figured out, it’s time to code right? Not really. More likely designing and coding would be happening at the same time with the two influencing one another. Bane Games’ Alistair Doulin wrote a good article on how to keep gameplay technology agnostic and it’s worth a read even if you don’t program. Obviously it’s not possible to keep code fully separate from gameplay as some systems require it and in some cases the game mechanics have to change fundamentally based on the control options the player has.

I’ve worked on three different game engines and all have had gameplay and engine intertwined throughout the source code. In Unity, all game objects inherit from, MonoBehaviour giving them full access to the power of Unity (and forming a hard link between game and engine).

Recently, I’ve moved away from this approach to a better “separation of concerns”. I completely separate out the gameplay making it engine agnostic. This has worked well and I plan to use this approach for most of the games I create in the future.

Today I discuss this separation of gameplay and why I recommend others make the switch.

Page 1 of 2

Next

Powered by WordPress & Theme by Anders Norén