DevLog

Game a week tools and resources

Glaxor

Engines:

http://phaser.io/ – A desktop and mobile HTML 5 game framework

 

Sounds:

http://www.bfxr.net/ – For retro style placeholder sounds.

http://www.freesound.org/ – A resource for open source sounds

http://freemusicarchive.org/ – A resource for creative commons music files

 

Image Assets:

http://gaurav.munjal.us/Universal-LPC-Spritesheet-Character-Generator/ – For Character spritesheets with basic action animations

http://junkhunt.net/vx/charachip.shtml – Also for generating character sprites

http://www.famitsu.com/freegame/tool/chibi/index1.html – Another character sprite generator

http://opengameart.org/ – A resource for open source game art

http://www.mapeditor.org/ – A 2d tile map editor

 

I want to get better at making games

Glaxor

I’ve been thinking about the prototypes that I’ve made and that I haven’t really finished anything except that first flash game I made back in 2010. I am having trouble finishing projects. It might be that I feel like I’m not very good at making games, or that I just haven’t hit on an idea that I can maintain passion for long enough to get it done. I don’t know. But I think that taking the game a week challenge as outlined by Rami Ismail will help. It should help me get better at making games, and finishing them. With the project timeline being limited to one week I shouldn’t run out of steam before it’s done. It should also help me to develop a sense of what works in game design for which purpose, and what doesn’t.

I attended a local meeting of the Portland Area Game Developers Interest Group (PAGDIG) back when I first started at WSUV (late 2009 or early 2010) and there I met a man named Charles Berube. He gave me his card, but I didn’t keep in touch, I’m horrible at staying in touch with people. At the time he was in the midst of his own rapid game development challenge, and this was a few years before Rami Ismail’s Gamasutra post so I feel like this process has been circulating in the Indie communities for quite some time. Charles’ games are available at The Wasabi Project. I’ve been going through these games trying to extract the themes he was working from. Each one has an about section on its page, but they don’t explicitly list the themes the games are based on.

Adriel Wallick made a game a week for (almost) every week in 2014. Each game on her MsMinotaur blog is accompanied by a blog post outlining the idea, what went well, what went wrong, and what she learned. I like this approach as it requires the designer to think about the experience of making the game and what was finally produced critically. But reading through her blog I get the impression that she waited for inspiration each week to come up with an idea to start the week’s game. I would rather have a mechanism in place to provide a prompt from which to start a game each week.

In light of my resolve to make games that are focused on exploring the ways in which the medium can expand, amplify, and reflect human experiences I’ve begun to gather themes and prompts that I feel are a good starting point for thinking about the human experience. I plan to collect around 100 of these prompts, well over what is needed for a 52 week game-a-week cycle, and feed them into a hopper that will spit one out at random every week. I will still have to spend time thinking of an idea to fit the prompt, but this way I won’t have any of those “I don’t know what to make a game about” moments.

I want all the games I make for this purpose to run on the web without the need for a plugin, so an HTML5 engine would be ideal. I plan to look in to the Phaser engine over the next few days and make a couple of things in that engine to see if I can begin to work rapidly with it. I will also be looking for ways to generate sound and sprite assets quickly.

When I started writing this post I wasn’t sure if I wanted to start a game-a-week project, or for how long. Writing this post has helped me to solidify the idea and think through the costs and benefits as well as ways to mitigate some of the risks involved. I will spend the time that I have this week working on gathering themes, tools and resources and building a mechanism to deliver those themes weekly. I will also work on formalizing the questions I will ask myself after each project. I should be ready to get started on a game a week starting next Monday, August 24th.

I failed to reach my goal – hard

Glaxor

A little over a year ago I set a goal for myself to have accomplished by August 11th of this year. I completely failed in every way. I did take some of the steps I outlined in my goal statement, but they did not help me to reach the goal I set of making an income from my efforts in procedural media. To date I have made $0 from this website through ads or an affiliate program and I have not released any games, so I have made no money through those channels.

What did I do with the last year? I began by working on a prototype brick breaking game, some of the progress is documented on this blog. I joined a local indie gaming community here in the Portland area and even attended a meeting! I showed one person the prototype I was working on and he was kind with his feedback. Then I promptly lost interest in Super Spectrum Sphere.

I made a couple of prototypes playing around with hexagons and I made a couple of infinite runner prototypes. I worked on each one for a couple of weeks and then put them down. I posted a couple of times on this blog, but lost steam with that after a couple of weeks.

I have read a lot of blogs and articles on game development and game design. I’ve re-read some of the books listed in the bookshelf section on this website. I have also watched a lot of YouTube videos of talks from indie game developers like Jonathan Blow and Rami Ismail. But I have not been actively participating in any community in any way.

In light of my complete failure to generate revenue from my efforts I’ve been thinking a lot lately about why I even want to make games. I came up with the following statement:

I believe that procedural media possess distinctive properties that make them uniquely suited to communicate complicated relationships in a way that no other medium within human experience can, facilitating a deeper understanding of sophisticated systems.

Every game that I make is focused on exploring the ways in which video games can expand, amplify and mirror the human experience. My ultimate goal is not to explore the medium of video games, but to explore the human experience using video games as a tool.

I will likely continue to revise this statement as I’m not sure it communicates how I feel in exactly the way I want, but it will do for now. I will continue to look back on this statement as I move on, making things, and hopefully – this year – actually release something.

Super Spectrum Sphere: Week 2

Glaxor

I spent most of my development time this week working on getting the cannon to work the way I want it to. As I was drawing up a sprite to use for the cannon I had the idea to make it look more like a mechanical arm. I like the idea of the arm acting as a sphere generation and containment unit that releases when the player taps.

In my post from the first week I listed three things I needed to do now that I had the bricks and balls interacting the way I wanted them.

  • Auto oscillating cannon that changes color automatically.
  • Ball vector based on cannon position.
  • Ball color based on cannon color.

I spent about 12 (non-consecutive) hours writing a lot of really bad code trying to get those first two done. Eventually after learning something about SKActions and converting a radian angle value into a vector I came up with a simpler solution. I deleted all the unnecessary code I had written over three days and replaced it with one method and a handful of lines of code.

Because I was using a mechanical arm/containment device to hold on to the spheres before they shoot out into the playing field I decided that it wasn’t necessary for the cannon to change colors. The ball itself, sitting in the clutch of the mechanical arm, was enough to indicate to the player what color they were working with. To make the action of releasing and reloading the spheres more interesting I added a scaling action to the incoming sphere. Now when you shoot a ball, the next ball appears in the claw of the mechanical arm at a scale value of 0.1 and scales up to full size over the course of a half second. I find the effect visually satisfying.

I’ve thought of other little details I can add to this setup to make the game more squishy, like animating the claw when the spheres are released or animations for brick hits. I’d also like to add a color trail to the ball to help provide feedback to the user. Sometimes when the ball hits a brick close to the wall it actually contacts the wall first and changes color for a brief instant before it hits the brick. This can cause confusion sometimes because the color change is imperceptible and it can look like a red ball hit a red brick, but the brick didn’t break. I think the color trail behind the ball would help alleviate confusion there.

But for the coming week I think I should work on nailing down a scoring system and the basic structure of the software piece. I think I should at least add a home screen and a game over or level progression screen.

I have committed myself to attending the P.I.G. Squad (Portland Indie Game) art and code night this Monday the 25th. I hope to share what I have so far and get some feedback from the folks I meet there.

First steps with Super Spectrum Sphere

Glaxor

I spent some time in the last couple of days reviewing some tutorials on Sprite Kit development for iOS and working toward the functionality I outlined in my preliminary sketch of Super Spectrum Sphere. This Vine shows where I’m at and I also posted it on twitter with the #screenshotsaturday tag.

So here’s a list of what works and what I still need to implement.

Working:

  • Tapping “shoots” a new ball.
  • Balls change color when they bounce off the walls.
  • Balls “break” bricks of the same color.
  • Balls “break” when they hit a brick of a different color.
  • The boundaries of the play area are based on the center of the screen.
  • The play area is uniform across the two current phone screen sizes.

Still to be done:

  • Auto oscillating cannon that changes color automatically.
  • Ball vector based on cannon position.
  • Ball color based on cannon color.

And that’s just for the first iteration. Looking back through the code I’ve been writing just to get this far, it’s obvious I’m going to have to re think a lot of it to make it more robust. But for now I’m mostly concerned with making a playable prototype.

As I’ve been working I’ve had ideas on how I can make levels more complicated and interesting, but I’ve been trying not to think about that yet. For now, I need to focus on getting the core mechanics functioning so I’ve just been writing down my ideas and trying to forget about them for now.

Focus!