As you can see from the photos, I got an (ugly but functional) in-game chat system up and running today. You can type in your username and it’ll appear next to your chat string in the chat window. In the future, this username sign in info will be stored on some database when you sign up. I also ported over the networking code to C# and commented it out for future reference. Once I fully grasp it, I can bend it to my will!
We’ve gotten a lot of experience out of making Shaped, and now, three months after release, we’ve received practically all the sales we’re likely to make through it. So here it is – play Shaped for Free in your browser or on your mobile device of choice.
Thanks for playing. Please rate the game if you enjoy it.
As you can see from Eric’s post we’ve decided as a company to return to Drift as our main project. But I’m still interested in working on Summit as a platformer, and will continue working on it as a Send More People side project. Perhaps it’ll turn into a full game, perhaps it’ll just help me to continue fleshing out my C# skills, but for the moment it has value in being incredibly fun to work on and make strides in.
As you can see above, I’ve created a character controller and have gotten him to climb around a course. Today’s achievement was getting an animations array working, so that the animation automatically updates depending on the player status. Now comes the hard part – drawing the actual animation key frames. I’ll be spending a lot of time thinking of Eedward Muybridge in the days to come.
Oh, and I got a little hand-drawn animation working here as well. It’s hard to tell which is jankier… my hand-drawn animation or my 3d.
Like ocean tides that recede yet inevitably return, Drift, our overly ambitious multiplayer space adventure, has once more drifted back into our weekend dev sessions. Poor poetics aside, it has been an interesting and often frustrating experience watching this phenomenon play out. Derek aptly described this as being attracted to “whatever is the brightest light.” We seemed to be in an oblong orbit around the star called Drift. We get pulled in by our passion so closely we get burned out. Then we are slingshotted away to explore another, smaller planetary body (read: game project) for which our passion burns a bit less brightly. The gravitational attraction of our super ambitious multiplayer space adventure game is the same force that repels us. The question is, how do we orbit around one project long enough to finish it?
If you flex a rubber band enough times, eventually it becomes brittle and breaks. Jumping from project to project is like that. We have both felt that friction, the increasing discouragement, and it has often made us rethink our decision to make games for a living, rather than as just a hobby. Have you ever tried jumping back into old code? Sucks. Now imagine doing that every few months and you can imagine our demoralization and frustration. A malaise had hung over us for a few months and we were getting impatient. We faced a choice: A) shift to a purely hobbyist approach to game development, or B) figure out how to shift our trajectory to a far more sustainable orbit. While neither of us wanted to ditch Send More People, it was hard to see it as the reasonable next step towards an actual future in the gaming industry.
Coincidentally, it was about that time that I randomly decided it was time to finally figure out what the hell ‘Agile’ and ‘Scrum’ were all about. Turns out, they both combine to form a pretty damn good cure to our indie game dev woes. By breaking up our game dreams into small, strongly prioritized chunks, and then tackling the development of those chunks in two-week ‘sprints,’ we are able to hold back the overwhelming wave of “How the hell are we going to implement all that?”
Instead, starting with the absolute-most-boiled-down core of our game idea, we focus on small, short term projects, each one building a layer upon the layer that came before it. It’s like building an onion from the inside out. At the end of every sprint, we have, for all intents and purposes, a finished onion. How big that onion gets in the end is always ‘to be determined’ and at any point in the game’s…err, onion’s development it is ready for consumption.
Todd Howard says, “Great games are played, not made.” By having a ‘finished’ game every two weeks, it’s always playable. This is great when it comes to play-testing, as it allows us to design as we go, finding out what works, what doesn’t, and what needs to be next. Because it is prioritized, we can change course if we need to without nullifying all the months of work that came before it.
In addition, the satisfaction of completion, which is what draws us away from Drift toward smaller projects, is felt on a bi-weekly basis, as each new layer of functionality is implemented. That itch is scratched. That release serves to keep us confident and encouraged. It keeps the ball rolling.
Lastly, and perhaps most importantly for indies deving on separate coasts in their rare spare hours, we can always just hang out and have fun in the Drift universe without feeling guilty about it. There’s always an outlet, a place to kick it, without feeling like you’re not doing ‘work.’ As Notch says, if you find that you’re losing yourself in your game for an hour or more then the game is fun. So you should probably check that is…frequently. In the end, entire development process is far more enjoyable and effective, and thus our passion for the project is more easily sustained.
We’re only in our second sprint right now, and we’re already seeing the benefits of this new methodology. Our orbit is starting to equalize. While we’ll still flirt with smaller satellites, like Summit, it is finally looking like Drift is going to get the attention and execution it deserves. Wish us luck!
Now to go work on my poetry skills…
So we’ve gotten a lot done on Summit, in the past few days.
I’m delighted that Eric made the discovery of the Unity asset, E2D. Our use of Uni2D to generate terrain was meeting with some snags – namely, that the editor crawled any time we tried to drag an object with the Uni2D script attached. For the quick generation of player terrain, E2D is much simpler. You just drag and drop nodes, and voila – a new piece of terrain in seconds. I learned how to use the software and generated the environment above in about 2 hours of work – the bare bones of a level, which I can now fill in with environmental details.
We also have a new model for our dude guy. At first glance he doesn’t look much better – where are his clothes? – but if you look under that pasty pale skin you might see a humanoid Mecanim rig as opposed to the one that Eric valiantly set up way back when. The benefit of this rig is that there are premade animations for it, which we hope to take in, learn from and perhaps modify to work on a 2D plane. Incidentally I recommend that Unity 3d users look into Space Robot Kyle - he comes with a great animation tutorial.
Eric has proposed that we employ something called Agile development, which is apparently all the rage (my mother, working at a software company, works using Agile). Essentially our system is to set 2-week “sprints” and break up our goals into achievable blocks. I’m down. Thinking about what I can accomplish in two weeks helps keep ambition in check. If I learned anything from my solo Ludum Dare 25 experience is that you need to keep your goals – short term at least – as simple as possible. Get too ambitious, and your interest starts flagging as you toil without any discernable success.
We’re also switching up the control scheme. More on that later.
Honestly, folks, I’ve felt very motivated about the project in the past few days. A gleam of the final result is starting to peer through.
Seriously, 2d indie developers! Check out E2D.