A Year Gone By at Honeyvale

Wow, it’s been a while! So how about an update, huh?

gif-7

It’s been a pretty good year. It’s been fast paced, which is why a blog post hasn’t come any earlier, but that doesn’t mean things haven’t been happening.

Despite our best efforts, we weren’t able to finish Alchemy Punch before university started back up at the start of the year. And, as it is both our final year of university, we needed to get into a team for our capstone project. We already have quite a nice team here, so we ended up associating our project with Honeyvale!

We started working on Bees Won’t Exist, which as you can probably guess, was inspired tangentially by our team name and yes, has bees. It’s a fast-paced hack n’ slash game, and you are almost certainly going to be hearing about it over the next few weeks. We’re all really excited to show you more stuff about it but for now check out the facebook page! We also have an ‘About’ page set up for it here if you wanted to learn more.

But I want to keep this post as more of a general, “What’s happening with Honeyvale?” post. And one thing that’s very notable is that we have some new crew on board for the capstone project!

I (Dylan) have moved to now Designer, Writer and Character Modeller / Rigger / Skinner / UV mapper. Sometimes I program and have definitely never snuck sassy comments into the code, despite anything the others claim.

Supcher has moved to being an Art Lead and Animator. He also does a lot of textures and is responsible to some amazing art for our meeting white boards as seen here. Oh, and also he does freaky paper puppets which, if I’m being honest, I sort of want to make a trailer for now.

David Baker is here! He did a guest post during the 48 Hour Game Making Challenge last year. He’s our Producer and a programmer, and is also responsible for a lot of the marketing. Once he did 100 hours of work in a single week, without even replacing his ionic capacitor.

Rory Dungan is also back from that same 48 hour competition. He’s the Lead Programmer and Senior Exotic Tea Provider, which comes in handy if we ever end up doing some work at his house.

Harrison Short is the only main developer who hasn’t been related to Honeyvale before. He is the Sound Lead and a programmer, but his primary role is in providing a never-ending stream of friendly sass.

Dante Mccoy isn’t part of the University but a friend of ours who wanted to help out by providing some environment models. Or we blackmailed him. (Can we just double check that we didn’t blackmail him before I press publish on this post?)

So we are the Honeyvale that is working on Bees Won’t Exist. The Alchemy Punch team is still just Supcher and I, and that’s on haitus for another month or so.

If you haven’t seen on our other socials, Bees Won’t Exist got accepted into the GCAP student showcase 2016 which we’re all absolutely thrilled by! The QUT Student Showcase, the university we are graduating from, clashes with this time, so we’re splitting who’s going to what:

Harrison, Baker and I will all be there for the full QUT showcase on the 2nd of November at 5:30 PM – 8:00 PM. Bee there or bee square.

Harrison and I will be at GCAP for the 1st of November only

Supcher and Rory will be at GCAP for both the 1st and the 2nd.

TLDR we’ll be at both, say hi!

Anyways, I think that covers it. Go ahead and leave any comments below if you have questions about anything I may have neglected to cover. Since we’re releasing Bees Won’t Exist very soon, there’ll be a few blog posts coming up about that. Stay tuned!

48 Hour Game Challenge 2015: The First Five Hours

We were set up and ready to go. With an entertaining search for a car parking spot and a much needed snack trip to Woolworths behind us, we sat amongst the buzzing sprawl of tables. Said tables were laden with all manner of game development gear covering all available surfaces as everyone present prepped for the long haul. 48 hours of sleep deprived long haul.

The members of team Honeyvale, excluding our valiant programmer who was set to reinforce us shortly after the start, had already reflected on the previous weeks practice jam. We also had a plan for the first hour or so of what awaited us.

So, after an introduction of the event organisers and general administration stuff, it was time to hear the three words, representing themes, which would guide us for our development adventure.

– Swallow

– Thief

– Collapse

Bam! Time to start.

We raced outside to locate a quieter spot. We had rationed ourselves 30 minutes to establish a high level concept. Our discussion progressed rapidly while covering everything from the exploration of a digestive system to Northern-European mythology being thrown around. At last we settled on a general design.

Our bird-masked “Hero” would be a fearless individual whose one desire was to appease his Swallow Deity (Yes, of the avian variety). He would achieve this by collecting and offering up whatever items the mighty swallow desired. At the same time, the world would collapse around him as the great feathery beast grew restless.

The first few hours after that were industriously pursued by the team as we set up various systems to structure development, established an art style and smashed through some early code. Once reinforced by our programmer, our productivity increased even further.

We were doing so well in fact that after four hours we realised that we had implemented enough core features that we were actually ready to start level design and create our first playable. Hot Dam!

At this point it was evident that we were all getting hungry and so we took it in shifts to keep marching steadily on whilst the others grabbed whichever of the local options took their fancy (Burger Urge and Nandos won the day) .

50 Shades of Pay – Our take on Free to Play

I can say that one of the most controversial debates between developers is the Free to Play debate. Some will tear down any game using it, others will practically force a player to pay for some in-app purchase to viably complete the game. As with most internet debates, these are only the extremes, and the stance that I believe is worth taking is somewhere in the middle.

I bring up this topic because Honeyvale will inevitably be questioned on it at some point – that’s right, get your pitchforks out ladies and gentlemen, because Glyph Gates is indeed going Free to Play! But it isn’t without reason, and I hope to explain that clearly here.

This is just an opinion piece. If you disagree with me, that doesn’t mean I’m saying you’re wrong and I’m right – debates never evolve with that kind of attitude. Just bring it up in the comments! I’d love to see if there’s something we aren’t clear on – or if there’s a perspective we haven’t taken into account on the issue.

Overall, each monetization strategy will have its own set of goals. Before we dive into Free-to-play, let’s have a look at our recent history with different models.

For the pay-once-and-play model, often the only goal is to make a game good enough to tell others about. A lot of people are a fan of this model because of that reason, and I really can’t argue with them – it makes sure that the money is where the fun is. On the other hand, particularly with new AAA releases, this can lead to inflated prices for otherwise fairly small games – but let’s not get into that here.

Jump back not too long ago, we had the coin-op being the most prevalent monetization model, which usually required players to die – a lot – to earn quarters. But it had to be the kind of frustration that spurs a player on to try again, which led to the difficult-but-fair style of game which still appeals to the Dark Souls and Super Meat Boy fans. However, it wasn’t all gravy, as this opened the door to games which basically required the player to pump quarters into them, like a rigged carnival game. The term ‘artificial difficulty’ could be used a lot here, for games would put in obstacles which were virtually impossible to overcome without dumb luck or already knowing they were there from a previous death – such as an anvil randomly falling out of the sky to hit your character.

However, it was difficult to criticise coin-op as a whole, because not all were based off of a die-lots system, or even abused that system in the first place. Competitive classic arcade games such as Pac Man or Donkey Kong were almost literally impossible to get to the end, but the real difficulty was facing against other human opponents for high scores – which is, often, a very fair difficulty. Arcade fighting games usually require the loser of a head-to-head match to put in another quarter to challenge the victor again. These games don’t really fit into criticisms that others have of the coin-op experience – they don’t have to force the players to die to earn money, they rely on players simply playing it a lot.

I feel this has a lot of comparisons to Free to Play. It is not uncommon for people to say that Free to Play games inherently focus on trying to psychologically barrage you into paying for an in-game service. Just like coin-op, that is something that could be said about a lot of prominent examples – and I’m not going to defend them. But just as context was needed to determine if a coin-op experience was ‘doing it wrong’, I think a lot more context is required before we can really dismiss a free to play game for using the model. Would League of Legends be a better game were it not Free to Play?

What I would define as a dangerous use of Free to Play is when games create an artificial sense of compulsion to play their game, rather than making the game be worth playing for its own sake. Psychological caveats such as Sunk Cost Fallacy or Loss Aversion Theory can be used to punish the players for not playing rather than providing a reward when they are – and this system is at the heart of Game Compulsion. A privy gamer might ask, “Do I want to see games which introduce punishments to my life? Or reward me for a few minutes a day?” The former obviously doesn’t benefit players, and the rammifications of it have already been demonstrated in prominent culture with gambling.

So are there Free to Play games which don’t rely on compulsion rather than entertainment? Of course – there’s nothing about optional payments which force people into these compulsions. I’ve heard the argument that every Free to Play game is trying to break its players, or that, of course companies only want your money, that it’s the only thing to gauge a player’s worth. But I don’t actually believe that a player spending money is the most important thing to a developer. A player which convinces at least one of their friends to play regularly makes your fanbase bigger, and in terms of word of mouth, that’s where your game snowballs into a great financial success.

Glyph Gates is Free to Play, but only because we want as many people to play and enjoy it as possible. We’re perhaps erring a little hard on the non-financially viable side of the coin, but to us, its justified – this is a portfolio piece and a bundle of experience. We’re still iterating through the exact execution of monetization, but the core we are building it around assures that it makes the game better, and doesn’t make anyone feel bad for paying or not paying.

However, even if all we cared about was money, having players who never spend money on Free to Play games are still important to have. You need them to tell their friends! Rate your game five stars! Play it on the bus for curious onlookers! If even one other person picks up the game because of a non-payer, then its considered a success in my book. In fact, someone who is amazed by the experience and tells everyone they know about how great this game is will often be a greater boon than the $10 or so they would have spent, max.

I’m not an economist. I haven’t done years of looking at books studying dollar signs. And I think that people who apply that sort of knowledge to games have lost the point. If someone sat down with Flappy Bird and tried to maximise both average user revenue and user retention, I have no doubt they would have ruined it, but it would be the obviously bad game that was blamed. But if you’re getting as many players as Flappy Bird, perhaps you don’t need to squeeze all those nickels and dimes.

How to push the limits of how much you work

A little over a week ago, I heard about the death of Monty Oum, the brilliant mind behind the animated show, RWBY. One of the things I’ve always admired about him is the drive and passion he showed towards animation, and he became famous for pulling 18 hour days of work. Roosterteeth encouraged people to dedicate themselves to creating something in remembrance, which made me resolve to attempt one of these 18 hour days myself.

The rules were simple: I had to work for 18 hours. This included no more than 30 cumulative minutes of breaks for cooking (read: microwaving) food, which I would eat while mashing at a keyboard. I had to work on development – coding which would push the project further to its completion. No marketing, no blog post writing, and no setting up any of the miscellaneous business stuff I have to do every now and again. I always aspired to applying myself to game development as much as possible, and pushing past an 8 hour day seemed to be a good first step.

To spoil the ending, I learnt a lot. I highly recommend it to anyone to try.

My expectations going into it was that this would teach me to be able to work for longer, and focus more, but that wasn’t the main takeaway here. I thought that by the end, every line of code would be a labour to write, but this was the easiest part. In fact, the hard parts were after I completed a feature or fixed a bug. If I could convince myself to push past the need to take a break in these in-between moments, I found within 5 minutes of starting to solve the next problem, I didn’t feel I needed a break at all, even after 17 hours of programming! This made me examine myself: What really was holding me back?

Well, I’ve always been aware of momentum, and the necessity to maintain it. Ostensibly, this is why it’s harder to start fixing a new problem than it is to continue working on the one you’re currently knee deep in. After a feature is finished, you cathartically take in your first vision of the feature as it might be in the final game. It’s a moment to catch your breath. But you lose momentum, and I previously would have recommended that you avoid focusing on this catharsis, so that you lose as little momentum as possible. But in my experience, it’s difficult not to revel in the glory of a well-done chunk of work, and as you rightfully should – it sets up an excellent and natural reward system; and I wouldn’t be the first to say that a reward system may help you out more than you may guess. So the problem isn’t momentum, or not exactly. The problem is urgency.

In an 18 hour day, there is no time for messing around. The moment I woke up at 9:10 am (which may as well be the crack of dawn for me), I knew that even if I started work right away I could only hope to finish at 3:00 am the next morning. So I got to it. There was never a question of what I’d do next, the answer was always: “Exactly as much as I need to do before I get back to making games again.” The situation demanded my attention because it was urgent, as if I didn’t give it my full attention, I would have to work for even longer.

This sense of urgency made fixing this problem of momentum so simple. Whenever I had that moment after finishing a block of work, there wasn’t anything wrong with playtesting and feeling good about myself. But I needed to get back to work – and to do so quickly. In a normal, not 18 hour day, I would recommend taking a ten minute break here, but too often in my normal routine would I get coaxed into taking unnecessarily long breaks instead, ranging 30 minutes to 2 hours, and just working for longer hours to compensate. Each 10-minute video seemed like it wouldn’t cut into development that much. But of course, it turns into a slippery slope. Things needed to be urgent for me to get past that – perhaps things are the same for you.

When I finished that day, I felt sore and tired, but I couldn’t believe how easy it was for me to do when I put my mind to it. It wasn’t climbing Mount Everest, and many people will scoff at my suggestion it was a trial in the first place. And I wouldn’t dream of doing it regularly – there’s just no time for sleep. But if you’re reading this right now thinking, “I couldn’t possibly do that,” try it. It doesn’t have to be every day of your life from here on out, but at least you’ll be able to say you tried. And you might even be able to say you succeeded.

Team Positions

The ‘About Us’ section doesn’t really have the full picture about our roles, so I figured this might be a good time to take a moment to explain our rationality behind our choices, and possible guide someone else who might be in a similar position.

When I started work on Glyph Gates, I just wanted to see if the core mechanics were fun, and tested it as much as possible, starting off as a designer and a programmer. After a lot of testing, the original idea was pretty different to what I ended up with. One by one, incremental tweaks would move the original ‘Elemental Match-3′ concept to a framework which accommodated it. When I approached Supcher, looking for an artist, around 40% of the programming framework was where it needed to be.

An very early screenshot of the prototype which evolved into Glyph Gates

A very early screenshot of the prototype which evolved into Glyph Gates

We identified early on that our main chokepoint in the project would be in art assets. Glyph Gates doesn’t have any features which demanded a lot of programming work, but art assets on a mobile platform need to be very polished – and we had more animated assets than is usual for a game of our scale. Because of this, Supcher took on a purely art-focused role, as we were expecting to not be releasing until he’s done all of his work, wheras I had a lot of expected down time.

Because of that, I essentially took up the role of ‘Not Art’. My goal is to have the project go as smoothly as possible without having to distract Supcher from game assets. I do all of the programming, and I lead the design direction which Supcher is also a part in as well. I also handle testing, and do the assortment of jobs which fall under the nebulous realm of a producer: setting milestones, seeking advice from peers and forums, and setting up MailChimp accounts (it’ll happen one day I swear).

And as you are experiencing right now, I’m the lovely that talks to the community, and tries to make our marketing effort a little more significant than the $0 we have to spend on it. I make blog posts, manage social media accounts, and try to make my face known on online forums such as Reddit’s /r/gamedev so that I’m not a new face when I tell everyone about the game I released. But really, this might be a bit misleading, so an example might be in order to illustrate my point.

While setting up this website, we started off having Supcher do all of the art assets, but realized very quickly that this was expected to halt our in game art development by over a week. Because game art will be the only thing keeping us from release, we need as many man-hours to be put into it as possible – and marketing art is the weird kind of ‘throwaway’ art which is never really finished or final. So we decided that I should implement feedback and continue tinkering with the aesthetic of the website so that Supcher could keep working, even though my role is technically ‘Not Art’.

If you’re looking for a takeaway from our process, the best I can say is this: Find what fits your team best, not what fits your roles best. I’m studying graphic design, so I’m less daunted by a task such as setting up the art assets for a website. But for someone in my position who isn’t confident in art, what might be best for the team actually is what strictly fits their role.

What do you think of the roles that we have set up? Do you know of a game development team which has an interesting method of distributing tasks? Write in the comments below, or write to contact@honeyvalegames.com to let us know!

Setting up MailChimp

At the moment, we have the functionality which allows you to subscribe to our newsletter. However, with both of us working remotely from home, we don’t actually have a physical address, and so because of some anti-spam laws, Mailchimp doesn’t want us using their service.

We are working on either getting a PO box, or using a friend’s company, which will allow us to actually make use of this subscription service. If you subscribe now, we should have the system working pretty soon.

Sorry to any stalkers out there who got their hopes up when they saw that box pop up. Don’t worry big guy, we’ll slip up somewhere else, just keep looking. : )

Well met, traveller

Hello and welcome to the very first post that we’re writing on this blog! If you’re reading this, you’ve either reached the end of all the posts we have available – sorry! – or this is in our early days where we are but a budding wordpress site. The site will probably look nothing like it looks like as I’m writing this, because we’ll have plastered art from our game everywhere after I fly off the handle and see bee-related art whenever I close my eyes. Weird!

Anyways, we are Honeyvale Games. Unless I’m finally assassinated after writing this post, you can read more about us in the ‘About Us’ section. But here’s just a taste: We are Honeyvale Games, a pair of friends who love making games – so much that we decided to brave that intimidating gap between ‘hobby’ and ‘profession’.

In this blog, we’ll be posting about what we’re doing in the games we make. Sometimes that’ll be art, or an explanation of mechanics. But we also post developer insights, articles written by us which we want to give to people who want an idea of how we do things, but also other developers by providing any tips on processes that we find lacking.

We hope to see you along the way!