Category

Development Blog

beta_web

Join the Beta

By | Announcements, Development Blog | No Comments

It’s finally here! We are taking registrations for the closed beta which is just a few short weeks away. Head on over to https://www.frankiesrevenge.com/beta and sign up now! If you’re already on our mailing list, you should still sign up to make sure you get an invite.

web_post_picture_frameThis has been a long time coming but we are finally ready. The beta starts in early March (first or second week, depending on how fast we can squash the remaining bugs) and will be running for a few weeks.

For the past 6 months or so we’ve spent a lot of time building new levels and tuning world mechanics. We also put a ton of work in online support, since our standards were set pretty high. Our goal was to make finding matches & playing online super easy and seamless. I think we nailed it and I even heard someone say that our online matchmaking is more streamlined than PUBGs but.. you know, that’s just hearsay. You can read more about it on our Steam page announcement.

With online implementation out of the way, we’ve been busy squashing bugs, adding more parts and enemies and just generally polishing things. There are two new guns, two new enemies and more on the way before the beta ships! I really can’t tell you how excited the whole team is to finally be here. So register for the Beta, get on Discord and join us for the latest leg of this journey!

-Alex

 

foreman-800x600

Plans for Frankie in 2018.

By | Announcements, Development Blog, Game Development | No Comments

Happy new year!

Time flies when you’re having fun and 2017 totally flew by. I haven’t done a great job at updating this blog but this all changes TODAY. You know, in the spirit of all good new year’s resomolutions.

First things first. What the hell have we been up? Well, since I haven’t posted in a while and I don’t want to make this a behemoth of a post, I’m going to conveniently itemize the most important points.

foreman-800x600

Definitely not hiding behind a vase like this guy.

  • Online multiplayer! This is a pretty big deal and used up most of our programming time. Nearly done now.
  • Finalized the design for inter-mission stuff, including rewards, challenges, cosmetics and progression. It was a hefty design problem and it’s pretty much done. Well… at least insofar as anything is done before you test it with actual users.
  • Levels levels levels! We’ve been experimenting with different mechanics and completed the visual design for the second campaign. Working on a lot of new levels right now.
  • Destructible objects! With things in them! Radu built some awesome utility items that you’ll find in crates dispersed across the world. Smashing!
  • Aliens! More details when the time is right.

Alright enough about that. I promised to talk about 2018 so let’s dig into that. First off, some great news. Radu just started working on Frankie full time! That’s great news because our programming backlog was really starting to go down the drain and Radu’s arrival is not unlike a knight’s timely intervention in regards to damsels and their state of affairs.

Second, we gathered our resources and upgraded our studio to Level 3. Here’s a photo of Dragos working hard while Radu gazes ponderously into his screen:

office-renovation

Boxes have taken residence in the studio and are refusing to leave.

Most importantly though, we’ve done a lot of planning and design work and I’m happy to say that WE HAVE A PLAN! It’s not the first one mind you but what’s new about it is that it stretches out until release. In other words, we’re starting to see a glimmer of the light waiting at the end of the development tunnel, although there’s still some way to go. Here’s our schedule, in a nutshell:

  1. Finish online multiplayer
  2. Run an alpha test and absorb feedback
  3. Release in early access and iterate
  4. Full Steam release
  5. … profit?

Dates, you ask? Don’t be rude! Well ok, I can tell you that this is all happening in 2018 and I hope we can run the alpha sometime in February-March. We’re going to need your help to spread the word so a tip of the hat to you if you’d be so kind to subscribe to our newsletter and help out when the time comes: http://eepurl.com/b0H5v6

To sum up, Team Rikodu is starting 2018 with big plans, lots of energy, and a desire to do better at keeping our community in the loop. And it’s on this point that I’ll make the final announcement: we’re going to start recording and sharing our internal bi-weekly demos. Think of it as a sort of dev diary. We’re going to release these videos on our YouTube channel regularly, starting in a few weeks.

Stay frosty.

-Alex

reboot-article

Creating opportunities – the stuff of great conferences

By | Conferences, Development Blog | No Comments

Reboot Develop 2017 was amazing. Let’s get that out of the way first. It was by far the best conference we’ve attended so far. Looking back at the experience and attempting to answer why I felt that way, I got to thinking about what makes a great conference for an indie dev in general. Read on for some thoughts on what really matters to an indie when going to an industry event.

Before we talk about what makes for “the best” of anything, let’s add some context. People go to conferences for wildly different reasons so the conclusions I’m about to share are only relevant if you’re in a similar boat as our little studio. For Rikodu, the main reasons to go to conferences right now are:

  1. We are actively looking for publishers and/or investors. This is the #1 priority for Rikodu at the moment and we’re doing our best to find the right people to talk to and pitch our game.
  1. We are also looking for ways to increase our game’s visibility. Any kind of recognition, be it in the form of an award or some article in the press, helps further that goal.

For anybody in a similar situation, Reboot was an awesome conference. I can sum up the reasons in one single word: opportunity. For all its organizational woes (there were a few but these things always take a few editions to iron out) there was an abundance of opportunity to find what we were looking for at Reboot.

The calm before the storm at Reboot Develop

Photo by Sebastian Bularca

So if I were talking to someone who is organizing a conference (Dev-Play 2017 is not that far away) and they would ask me what I would recommend to make the conference attractive to budding indie developers like us, here’s what I’d tell them.

Attract publishers, investors and journalists

Kind of a no brainer but if you’re a developer looking for funds and exposure, these are the people you want to talk to. If I know there are publishers/investors going to a conference, I’m very inclined to attend. At Reboot I talked to no less than 10 publishers, many of them big names, and that’s not even counting Sony and Microsoft.

Having your conference in Dubrovnik certainly helps attract a good crowd. If your conference isn’t in some amazing, world-renowned location you’ll just have to get creative. Good parties? Special events? I don’t know, I just make games man! But as an organizer I hope you’ll find a way.

And hey, since you’re doing all this work to attract the right people, I hope you won’t forget to let us all know that these people will be there. Or maybe even hype up the fact that you’re focused on attracting this crowd and are actively trying to create opportunities for developer-investor meetings.

Have a good, highly visible indie showcase area

By now we’ve been to three indie showcases and a timed indie showcase slot. To explain them briefly, these are dedicated areas where indies can expo their games and anyone can come by to play them.

Putting the indie area on the main foot path is a great idea!

Photo by Sebastian Bularca

Here’s what I liked about all of them:

  • They were free
  • They allowed us to get at least some amount of people to play our game and get feedback
  • Sort of good, if rather random way, of meeting people and making connections

And here’s what I’ve seen go wrong at various conferences or, dare I say it, completely ruin an indie area in one case:

  • Very difficult to access some parts of the area. In one particular case, there were cramped rows of indie tables. To get between two rows, you would literally have to squeeze through both the exhibitors and the unfortunate souls who were already trapped in there. So if you weren’t lucky enough to get a spot in one of the exterior rows, which I’d say only 10% of exhibitors did, you had very few people come over and play the game.
  • Way too little space per exhibitor. I mean, I know it’s free and all, but please give me enough space to have a decent monitor, a couple of controllers and absolutely minimal branding material. I’m not asking for a lot, just a decent 1m wide desk area. Think of the children! And the non-mobile game developers!
  • Entire area hidden away in some dark corner. The indie area is where busy conference goers, speakers and attendees alike, might go in the few and hectic breaks in their conference schedule. They don’t have a lot of time so make sure that the area is in their way where they can see it and easily get off their path for 5 minutes to check it out.

Have a good Indie Award and make it a big deal

I’m being Captain Obvious again but I think this is important. It’s so easy to just throw together an “Indie Award”, announce some winners at the end and call it done. Well, fear not! I’m here to correct the delusion that that’s a job well done and provide some helpful tips!

Here’s my list of 7 things to do if you’re organizing an Indie Award:

  1. Make sure your jury is prestigious but, even more importantly, try to make sure that they actually play the games! Otherwise it’s just a popularity contest or a “who makes the nicest trailer” competition.
  2. Really think about your categories. Wait, you do have categories right?
  3. Make the Awards ceremony a big thing! Plenty of ways to do this but just make sure that lots of people attend and you make a big deal out of awarding the winners and the finalists.
  4. Line up a journalist or two to interview the winners. They might do it on their own but they could also be busy. It would be really cool if you as an organizer talked to attending journalists and made sure they’ve got this booked in their schedule.
  5. Market the crap out of the award both before and after the event. For a fledgling indie studio, it helps to even be on a list of “also ran” at a prestigious conference. And hey, all those back-links might come in handy for you too.
  6. You create content all throughout the year to market your conference, right? So why not follow up and write some articles about winners and participants of the last edition while you’re preparing for the new one?
  7. Prizes are the least important thing! Yeah, it’s cool to win and we really had fun with the Oculus we received for winning the Reboot Pitch but material things aren’t really what I’m after when we’re competing. Unless you’re offering cold hard cash (which is always useful), spend the energy on the other points.

radu-award_small

Reboot got a lot of these things very right. They could go a mile further by increasing the exposure of their award winners but overall I think they understand that this has to be a big deal for it to matter.

Don’t forget the pitching session

Maybe it’s just me but I like pitching sessions a lot. I mean, we did win two of the three we attended and we were runner up for the other so the results definitely influence my memory of the events, but I really think pitching sessions are great for all participants.

First off, as an indie dev, you’re guaranteed to get the attention of people who can really help you out. Pitch judges might be exactly the connections you’re looking for or they might be able to introduce you to other people you want to talk to. It’s a limited time but the stage is yours and it’s easy to approach attendees after the pitching session.

To top it off, it’s also a great opportunity to receive feedback from people who know the industry well. It’s a unique perspective, that of the seasoned judge who has seen many pitches and loads of games in various stages of development, and it’s something any aspiring dev should take advantage of.

Pitches are a great way to give developers a short window of undivided attention

Photo by Sebastian Bularca

Reboot had not one but two pitches, with one organized by Nordic Games Conference. Both had really great judges and I definitely took advantage of the opportunity to talk to most of them.

Making the most of it

Ultimately, no matter how good a conference is, it’s still just an opportunity. It’s up to us developers to make the most of it. That’s a topic for another article but suffice it to say that shyness is not an option. Most devs aren’t really prepared to act as salesmen but that’s exactly what you gotta do when you go there. I’ll let Alec Baldwin close for me.

-Alex

loops

Getting ready for Reboot Develop. Meanwhile speaking at CodeCamp in Cluj.

By | Announcements, Development Blog, Game Design, Game Development | No Comments

Nope, we’re not dead. We just have to pick our battles and make hard decisions about where to spend our time. This blog doesn’t win that contest very often so follow our Facebook page if you’re hungry for regular updates. Still, we’re committed to posting major updates and interesting stuff here even if the frequency is lower than we’d like.

So here’s the deal. We’ve been super, duper busy since Casual Connect adding the next big system: robot customization and player progression. Now, I know this may not sound like much but it is in fact a HUGE addition. It’s basically the part of the game that will form… *drumroll*… THE OUTER LOOOOOP! If you’re not a game designer you may not have heard about this so let me explain with a quick diagram:

loops

Until February we’ve focused entirely on the “Core Loop”. It defines the sequence of actions that the players will keep doing over and over, most of the time that they’re in the game. It’s what makes a game enjoyable at a micro-level. As the name implies, it’s really important to get the Core Loop right, lest you risk getting into a mode I fondly call “polishing the turd”. That’s when you add a bunch of sprinkles and other pretty things on top of a ‘meh’ core. And that’s just sad.

Post-Casual Connect we evaluated all the feedback and we think we’ve got the core loop right! The minute to minute combat is enjoyable; players like the world, the characters, the way the controls feel and they find the combat satisfying. Job well done! Let’s pop the champagne and wait for the money to start flowing in! As you might have guessed by now, we’re not quite there yet. See, while the minute to minute experience is interesting, there’s not enough in the game to get players wanting to come back. So here we are, working hard on the Outer Loop to give players long-term goals and keep them interested after playing.

This is more of a teaser but I’m going to write up a longer article talking about how we tackle these things after we’re back from Reboot.

Speaking of which, here’s what’s happening next for us:

  • Tomorrow, we’ll be at Codecamp (http://cluj.codecamp.ro/), the largest tech conference in Cluj-Napoca. Radu will start the Gaming track at 10:00 with a 45 minute session about how we’re planning to build multiplayer for Second Hand. Then I’ll take over the mic at 11:00 to ramble about what it’s like to start an indie studio and how that’s different from regular tech startups. Come join us if you’re in Cluj.
  • In less than two weeks we’ll be at Reboot Develop (http://www.rebootdevelop.hr/) in Dubrovnik. It’s going to be an awesome conference and we’ll be showcasing Second Hand there at the Indie Area as well as participating in the Indie Awards. Definitely come visit if you’re around.

That is all. Enjoy the finicky spring weather.

-Alex

casual-connect

Frankie seeks revenge at Casual Connect in Berlin

By | Development Blog | No Comments

Only two weeks until Casual Connect Berlin! We’re super excited to participate in the Indie Prize and hope to get a lot of feedback from the show. We’ll be at booth 1014 so come by to check out the latest build and say hi if you’re attending.

Radu and I will both be there, shuffling between our booth and various meetings. We’re not just there to take part in the competition – we’re also looking to connect to publishers, investors and press.

Most importantly though, we’re looking for feedback. We’ve put a lot of work since Indiecade to expand the game. We’ve added two brand new systems in place which should add tactical depth to our combat system and give players more things to do (you know… other than smashing bad robots to bits). I can’t wait to see how people react to them and if they’re as fun as we think they are.

Hallo Berlin! Wir sind froh dich kennenzulernen!

 

 

ai

Implementing robust AI for SecondHand: Enemy Positioning

By | Development Blog | No Comments

This is part one of a series of posts I’m going to do about SecondHand’s AI, check out the intro here.

Problem Definition:

Since SecondHand has heavy emphasis on melee combat, for the enemies to be challenging and dangerous they need to be able to reach a position where they can attack. This is especially challenging given the twin-stick nature of the game combined with high physicality. The problem is compounded by the high number of enemies and the multiplayer aspect.

Simply put, the problem we’re trying to solve is: what is the best position for an enemy agent to be at any time?

Challenges:

  • different enemies have different preferred locations depending on range and personality (some prefer to flank, others prefer to attack head on)
  • lots of enemy agents at the same time
  • multiple targets
  • a varied environment
  • chaotic & physical combat
  • needs to be easy to set up

But what I consider one of the most important aspects is that it needs to be robust. Why? Because AI robustness goes hand in hand with good level design and balancing.

Our 3-step solution:

Step 1: sample positions around the player

Step 2: score those positions (make this part easily extended and parametric)

Step 3: pick one to use based on the scores. 

This is how the end result looks like, pay attention to how the enemies bunch up around the players:

Let’s cover the steps into more detail.

Step 1: Sample generation and filtering

The player is the target, so we’re going to sample positions around the player’s position. Since multiple enemies are attacking the player, we want that “being surrounded” flavour to the action so we’ll start out by generating concentric rings of positions. We update these positions every frame.

Architecturally speaking, we abstract the generation into a SamplePositionGenerator that provides points to the positioning module. So we can have any number of generators that generate any number of points.
Here’s our radial positions generator doing its thing:

So now we have some points, but obviously some are invalid due to them being off navmesh. We need to filter those out. Let’s build a Filter that takes a point, that does a nav-mesh line of sight check towards the center. No use going to that position if the enemy can’t see the player, right?

Ok, so we have some candidate positions at this point. Onward to scoring!

Step 2: Sample scoring

Everything that happens from this point forward is enemy centric. Each enemy agent will have its own scoring stack and parameters (for those worrying about performance, I’ll talk about that later).

Each position needs to be evaluated and given a score, and we want the scoring to parametric. This is why we create multiple scoring stages that we can stack and form a final score.

In diagram form, the process looks something like this:

In the diagram above, we construct scoring stages that have a score calculator (evaluates and scores a position) and a modulator (modulates normalized scores). We feed in positions, score them, normalize the scores into 0 – 1 range, and then apply things like falloff, inversion and weight. You can follow the flow of data based on the numbered stars.

What’s the payload you might be asking. The payload contains data needed by some calculators, such as the positions of the other enemies or the parent of the position being evaluated. The position itself is contained in the payload but for the sake of clarity, the diagram shows it as separate.

Modulation is separate because it needs normalized scores to function. It also biases the results based on the stages weight. So when combining results, if distance to the target is more important the distance stage will have more weight in the stack. The types of modulation available are Inverse, Power with custom exponent, Inverse-Square.

I’m going to show you how a stack looks and behaves in practice. Let’s start with a simple distance to target. Each enemy has a preferred distance to its target. A parametric distance stage result will look like this:

Remember, it’s important that the scoring function should be something really simple like distance, dot product, average distance to other agents, etc. Also, if the function is parametric it becomes reusable and a very good tool in creating personality with the same building blocks.

Note that in the distance example, the preferred distance is the parameter that varies.

Here’s the preferred_distance parameter changing at runtime.

In the distance example, you can see modulation at work.Inverse being applied, but also the pow function with a varying exponent to make the “habitable” zone thinner or wider.

Here’s another example with dot product between A (enemy pos, position) and B (position, target pos). Functionally, we’re telling the enemy he prefers points between the player and himself. We’re messing with the pow exponent to create wider or narrower cones.

Now lets combine the two and have an enemy follow the best point.

Let’s try a fun one. We don’t want the enemies to get trapped in corners, we want them to stay away from walls. Let’s create a stage that scores point distance to the edge of the navmesh.

The multi-agent problem

At this point we’re ready to tackle the problem of multiple enemies competing for positions. When adding two enemies, it’s very much imaginable that they can choose the same point. How do we prevent that?

First idea: score the distance to other enemies, and invert the result. That will cause the points close to others to have a lower scores and the best points to be the ones farther away. Alas, this doesn’t work well in practice, because everyone is moving and influencing everyone else! What happens is oscillation, the agents will continuously change their minds and run around aimlessly.

A better idea: score point distance to the other enemies intended position. This provides a stable solution and solves the decision oscillation.

Did I mention we implemented priorities? Damn right we did — lower prio enemies get out of the way of higher prio ones. Here’s how it looks (red guy has lower priority):

Here’s some emergent order from using these really simple functions. Notice how the agents make room for a higher priority peer (the green guy that pops up):

Step 3: Choosing the final result

This is the final step and is a straightforward one. The simplest approach is to simply choose the best scoring position, but there are some alternatives that include choosing a random sample in the top x% scores.
Its also worth mentioning that you can implement decision inertia at this point. For example, keep using the same point if its score doesn’t drop below a certain threshold, or only change if the score has dropped %x percent in the last y timeframe.

Even though the system works with any number of players providing positions, we are currently using a different method to select the target player, to prevent decision oscillations where the enemy agent keeps changing its mind about its target.

Caveats & Opportunities

The scoring method described is very powerful and straightforward, but it can be very hard to debug when dealing with a lot of scoring stages. Why? Because nonlinearities get added up and form non intuitive results. A way to mitigate this is to keep stage stacks small and swap between them based on the situation( for example have one stack the the enemy is far away, and another one if it is close).

Our implementation is currently unoptimized and it currently runs fine. But that’s not to say that it couldn’t cause problems in the future. Let’s look at some numbers, say we have 10 enemy agents on screen and 2 players. If each player generates 90 points, we’re looking at 10 x 2 x 90 nav-mesh queries per frame, yikes! There’s plenty of ways to mitigate this and this topic deserves its own blogpost, but generally spreading out computation across frames is a good approach.

That’s it for this episode from the trenches. Ping me on twitter @Radu_Septimiu if you’d like to discuss this stuff or have any questions.

Radu out.

ai2

Implementing robust AI for SecondHand: An Introduction

By | Development Blog | No Comments

Things have been busy at Rikodu, but I finally decided to bite the bullet and post some technical write-ups about the systems we’re building for SecondHand. And what better place to start than AI, my favorite part of game development?

SecondHand’s Ai philosophy

When it comes to AI, all games have their own special blend of requirements and challenges that make each implementation as unique as the design itself. A good definition of what good AI is is still elusive but this quote is as close as it gets:

“To be enjoyable, an AI must put up a good fight but lose more often than win.
It must make the player feel clever, sly, cunning, and powerful.
It must make the player jump from his seat shouting,
“Take that, you little shit!”

Mat Buckland, Programming Game AI by Example

How does that translate to a fast paced action game, like SecondHand? Here’s a list of things we want the AI to handle:

  • Enemy positioning
  • Dramatic pacing
  • Difficulty scaling
  • World-building through unique behaviors
  • Level specific behaviors

Project history

Our approach was an iterative one. We started out with having a very simple state machine for the enemy agents. After it became apparent that we need the enemy agents to be well coordinated, we built an Ai Director that handled the rate at which they attacked. The spawning was handled by heavy level centric behaviors that included lots of trigger boxes and spawning waves.

At this point it was clear we were having issues in this specific areas. The enemies were unable to consistently pose a threat to the player due to positioning and coordination problems. Level difficulty was close to impossible to control. The pacing of the game was chaotic. Extending enemy behavior became really difficult due to the constraints of the state machine decision making

The current iteration

A new iteration was imminent, that brought us to where we are today, Namely:

  • use an influence map/utility system for enemy agent positioning
  • have an Ai Director to control game pacing (spawning, intensity) similar to what the guys at Valve did with Left 4 Dead (check out Mike Booth’s presentation here)
  • move decision making into Behavior Trees
  • create sufficient debug tools & visualization to be able to tweak & debug everything

Here’s how everything came together at the end of November:

I’m going to aim for a three part discussion: Enemy Positioning, Pacing and Decision MakingStay tuned!

the-prize

Is your baby ugly? We took ours out to find out.

By | Development Blog, Game Design, Game Development | No Comments

Showing your game to strangers for the first time can be a little nerve wracking. After months of toiling in a secluded attic, the last weeks of which were particularly grueling, we finally took Second Hand to its first public showings: first to Dev-Play in Bucharest and shortly thereafter to Clujotronic in our very own Cluj. It was scary, thrilling, amazing and… we won the Dev-Play Indie Pitch!

Alex and Ovi receiving the Indie Prize at Dev-Play

kids-playing

Kids had fun with Second Hand at Clujotronic

In addition to winning this awesome prize (Casual Connect Berlin, here we come!), we found out that our baby is kind of ok looking as far as babies go and learned a ton of things about how to make it better. Read on to get the insights and the words of wisdom.

Before we get into the details though, I’d like to start with a round of virtual applause for the real rock stars, the guys and gal of Team Rikodu who made it all possible.

  • Ovidiu Mantoc – Level Design, 3D Art
  • Gabriel Tanko – Concept and 2D Art
  • Cosmin Coroiu – 3D Art
  • Carmen Palade – Animation
  • Radu Cristea – Programming
  • Stefan Dinca – User Interface
  • Dragos Geomolean – Additional 3D Art
  • Nikolaos Chatzigeorgiadis – Marketing

Nearly everyone does this in their spare time, so it was no small effort to get this thing out the door. I’ll spare you more praise and flattery because I honestly suck at it but I will say this: Guys, you rock!

What we learned about the game

The feedback about the game was better than we could have hoped. Everyone was very positive and I was stoked that many of the people who played our game at Dev-Play – mostly industry peers – said that they saw a lot of potential. Color me excited!

People liked the game but there was also useful feedback (and observation) of where we can improve. In no particular order:

1. Still too much clicking required

Yeah, we kinda knew this one already but it was even more evident as people played. The game still requires constant clicking, even more than Diablo, and this is something we’ll have to solve.

2. We got the pacing and distribution of the enemy waves completely wrong

It was funny when I saw this for the first time. Here’s the scenario: the player enters a new “zone” but doesn’t really know that because there’s no clear indicator. This triggers enemies to start spawning at a predefined rate and in a predefined sequence. Everything would work out as designed if the player started fighting in the new area but of course players will surprise you.

gamers-gaming

This dapper fellow thinks there’s too much clicking.

Many players backed away after seeing the first enemy, luring him away and then killing him. They would try to draw and kill enemies one by one with surprising consequences. The predefined spawning sequence would run in the background and enemies would just keep spawning in the room that was now out of view. This ensured that by the time the player got back from killing 1-2 enemies, there would be an entire horde chasing her down.

Fun stuff, needs fixing.

 3. Some things need a tutorial no matter how hard you try

The “service stations” where you enter to recharge your health and get a new Frankie configuration are very important. They’re a temporary solution until we implement actual customization but we really wanted players to see and use them. We saw players zooming past them early on (before Dev-Play) and we tried a bunch of things: make them a different color, put a huge neon sign that says ENTER, add a light to draw the eye. At some point we even had them painted in bright fuchsia.

You’d be wondering if it worked if I hadn’t already spoiled the answer. Yeah… no luck. Players were still happily zooming past and we had to constantly point them out. Teaching is in order.

4. Balancing the difficulty for a wide range of players will be a bitch

Some people finished the demo level in 4-5 minutes. Or, in the case of Josh Naylor from Unity, he did an almost flawless run in roughly 3 minutes on his third try. That’s better than most of the devs who worked on it! On the other end of the spectrum, some people took 3-4 tries just to finish it or couldn’t finish it at all.

Did I mention the aiming? Oh god, the aiming! It was excruciating to see some people just not aim at all and stick to using the attack controls. Turns out that if you’re not a hardcore gamer, it’s pretty challenging to move, aim and shoot independently.

Yeah, this is gonna be fun!

What we learned about showcasing

Both Dev-Play and Clujotronic were just amazing because we got to see people play our game. At Clujotronic we were even a part of this crazy, live gaming thing where an electronic band (Crowd Control) played live music while Ovidiu played the game and had it projected on the walls. Very trippy stuff!

So really the main lesson is old and tired: show your game! Show it early to strangers, don’t be afraid they’ll say it’s ugly. You’ll learn so much and it will be better as a result.

But there are a few more lessons for the would-be conference trekker.

1. Meeting other indie devs is really cool. You connect with like-minded people and get a ton of great ideas. Totally worth it just for this. Here’s a photo of Disco Dave and Second Hand: Frankie’s Revenge representing Cluj and being all gangsta. Except for Ovi; he can’t pull gangsta.

cluj-represent

2. Moving from full-on development to showcasing your game is a huge shift. You’re working in a bubble for 12 hours a day to get that last build ready for the demo and then suddenly: BOOM! You’re talking to people, seeing others play it, watching talks, participating in workshops, maybe even giving some yourself. Not really a lesson just more of a “be prepared” kind of thing.

3. If you’re setting up a booth, always have a spare extender (thanks Eni). Seriously, I would not have thought this could be a problem but it was. Tape also helps and a spare laptop doesn’t hurt. The desktop that was intended for the showcase almost gave its dying breath when we set it up.

What’s next?

The dust has settled and our energy bars are maxed out. SH:FR is now entering a new phase!

For one, we will be heading to Casual Connect in Berlin to take part in the Indie Prize. That’s due in February though so there’s plenty to do until then. For the game itself, here’s what’s coming up:

  • Multiplayer! The biggest feature request by far, we really want to add cooperative multiplayer into the mix and test it out as soon as possible.
  • Fix the problems we identified during the playtest.
  • Make the demo bigger and better. This means adding a couple of more enemy types, improving some of the existing parts and adding ranged weapons!
  • Paint a picture of the final game. The demo achieved its goal by proving that combat is fun and people like it. While combat is central to the game, we need to design and think about all the other details. How many levels? Where do they take place? What’s the overall story? Many questions will be answered as we try to design the complete experience.

I’m pretty sure we’ll be doing some more playtests in the near future. And yeah, we might even attend a conference or two before Casual Connect, strictly as attendees this time.  Meanwhile, here’s a photo of the trippy live gaming gig:

live-gaming-at-clujotronic

Thanks Dev-Play, thanks Clujotronic. Hope to be there again next year!

Sailing on the netherplanes,

~Alex

The Mood is Set in Frankie’s Scrapyard - Cover

The Mood is Set in Frankie’s Scrapyard

By | Development Blog | No Comments

This picture sums up the mood and art direction we’re going for. It defines the silhouettes, the color palette, the lighting and the type of material we’re going to build for the game. But this piece of concept is not just for tone setting, it’s going to be an actual part of the demo level. It will definitely take some time to create all the assets but it’s an essential part of having a compelling demo. The trailer we’re going to put together is meant to get gamers excited about Second Hand and paint a clear picture of how we see the final game. Visuals are obviously a big part of that so we really want to communicate where we’re heading on that front.

Read More
Doing it in Style - Cover

Devlog Update: Doing it in Style

By | Development Blog, Game Development | No Comments

Radu and I were planning to write a series of tech articles on some specific physics problems we’ve encountered and how we solved them. Second Hand is physically driven and we spent quite a bit of time in the last month solving the problems that derive from this physicality. Tech articles take a while to write though and we’ve still got loads to do for the prototype so you’ll have to wait a bit more to see how we solved all of the physics in Unity!

Read More