Skinner Box Games

gonna make the games

[skinnerboxgames-blog]

Click on the images for descriptions.

[skinnerboxgames-blog]

Play Test 2

[skinnerboxgames-blog]

Preparing for Playtest 2

Since playtest 1 was all about getting our gameplay demonstratable. This next playtest will be more focused on a tweaked gameplay experience along with the beginnings of some juice. 

For those who don’t know “juice” is essentially the stuff that makes a game “feel” good.  Its the feedback that lets the game be satisfying and exciting for players.  On the code side of things this includes things like camera shake, and health bars, which gives the player visual feedback for their actions.  On the sound side, it consists of sound effects and music that makes the game exciting and satisfying. Finally, on the art side, it’s the animations and sparkles that really make the game glow.  

A lot of our work these past few weeks have been dedicated to adding this to the game.  I added health bars to enemies, so players get the pleasure of having a visual indicator of the decimation they have caused to their enemies.  I added an activated state to antennas that show that they’ve been pressed. (you’d think this was obvious, but we only just did it).  Screen shake was also an obvious addition that makes attacks feel oh so satisfying.  We used a Perlin noise script that hopefully makes it feel better than just a normal random shake.  These are only a few things that contribute to the juice and hopefully it’ll make our game more satisfying for players.

On another note, we’ve tweaked the gameplay a bit and made the ux a bit more intuitive.  For example, the win condition is now to win 3/5 games. As opposed to before where the objective was to just kill all three players in one room.  

I can’t really think of much else so far.  A lot of it has been tweaking and fixing bugs.  

[skinnerboxgames-blog]

The Nature of Playtesting and Game Balance

When it comes to a game like our Glitch Escape or jut about any game that has stats in it, game balance becomes the predominant issue afterwards. Bugs can make or break a game during a playtest, and we can log them and try to fix them, but nothing is more frustrating than being on the losing side of an extremely one sided, broken game. 

With Glitch Escape, this was our first true playtest with all of our enemies in place, and the majority of our core mechanics and gameplay implemented. The problem was that I had statted all of our units and players based on what seemed balanced, using numbers that represented what we’d want from them (high health for a Tank, the basic minion is weak but costs next to nothing, Archers have high movement and can attack from afar, etc). The issue that came up during our playtest at MICA was that the Programmer (DM player who controlled the minions) was losing 5 out of the 6 times they played. The main issue? Game balance. After a while of playing, the Glitches (Players who worked together) found their dominant strategy of using the Archer to take care of enemies and the Tank to destroy walls. The Archer ended up being much stronger then anticipated. The Programmer on the other hand found that no other unit was really worth using expect for the “Spider” unit that had high damage, high move, and surprisingly high health. It cost a good amount, but the stats were the most economical and had the best chance of killing all the players to lead to a Programmer victory. 

Going forward with more playtesting and tweaking everything, I need to keep in mind a lot of things, as well as making sure that the Programmer can actually win, but not so fast that the players don’t get a chance to play either. Minion scaling alongside Player leveling? Managing the cost of enemies based on how well they can kill players? All of these are very important things that need to be fixed and accounted for as soon as possible in our game. It’s going to be a lot of math, a lot of ballparking, and a lot more playtesting before we have a game that plays exactly how we want it to , and how our players want it to.

-Lead Game Designer- Viditya Voleti

[skinnerboxgames-blog]

Glitch Escape / Playtest 1

Pre-Alpha footage of Glitch Escape Interview with playtesters.

Sotiris here!

So, we had a public playtest the other day and we captured a playthrough of our early alpha, together with an interview of our playtesters.

Enjoy! :D

[skinnerboxgames-blog]

Screenshots of the latest build of the game!

Click on the images for more comments.

[skinnerboxgames-blog]

Mary here,

The project schedule until the end of development can be seen here:

https://docs.google.com/document/d/1h36jlg33k0Dl2vlWeint6nDChoG3uaRuwg0y3hH7OjI/edit?usp=docslist_api

Generally, we're focusing on getting core mechanics done for a first prototype and then we're focusing on enhancing the graphics for the second prototype.

We've chosen a game with ambitious goals, so cutting some items or enemies will have to be expected, but once we get the core mechanicsworking, we should be able to add a variety of enemies, rooms and all sorts of goodies for the DM to wreck the player.

[skinnerboxgames-blog]

Here are some UI concepts

[skinnerboxgames-blog]

Here is a mock up of what the game should look pretty close to in the end.

[skinnerboxgames-blog]

Here is all of the progress for Glitch Escape.

[skinnerboxgames-blog]

Art Update!

Hey there!

ZaC Bolubasz- Art Director here with some Art Updates!

We are a couple weeks in and I’ve been hard at work producing sprites to fill our environments with lots of flavor.  Right now I have all 4 of the player character sprites conceptualized and I already have some of their actions planned out.  They should have an idle, move, attack, damage/death and special action animation.  On top of that I have a couple of enemies planned out and some boss concepts in the work.  We plan to implement a boss fight at the end of the game so finding the right boss for this moment has been tricky.  

During the process of filling in one of the dummy levels to present a potential look for the game I realized the colors I chose may be too monochromatic for what we need in the background.  I may go in and rework some of the colors or work with the rest of the team to add some filters that will add a few extra colors in a gradient to make the levels seem less flat.  

I’m excited to see how these all turn out and I am very much looking forward to spending hours working on these animations and making them look nice and Snappy!

Below Ill post the progress I’ve made on the art and the mockup I designed using the level preset Vidi designed.

[skinnerboxgames-blog]

Assets (Boat Game)

As the Art Director at Skinner Box Games testing and playing with different UI is something that is a challenge for me.  In addition to creating art assets for our game I took the challenge to create a simple UI for our turnbased territory game.  As the Art Director its my job to steer the game towards the right aesthetic goals.  By communicating with the Lead Designer and Programmers I become the middle man that takes these great ideas and puts them through the Mechanics Dynamics and Aesthetics test to ensure that the players experience the desired effect with each mechanic communicating well with the aesthetics of the game to create a dynamic playground of our design.

Working on this latest project has opened my eyes to lots of different ideas, for the first time working on a turn based tablet game a lot of the art direction will come from the UI and how each element ties into the theme of the game.  Our theme this week is fishing and establishing territory over fishing spots by casting nets.  with the given restrictions and time allotted I was able to create simple and effective assets that will communicate the games theme.

[skinnerboxgames-blog]

Djikstras, Fire Emblem, Weird Bugs

Alec here,

This week I spent almost all of my time implementing a graph and its corresponding algorithms into the game.  Several dozens of hours later we have something that somewhat works. 

Let me explain. 

Our game map is tile based, and we want to allow the player to select a unit and then see where he can move/attack with said unit.  Now if we just wanted to do this, it wouldn’t be too hard.  After all, we could just calculate up and down the tiles however we liked in a simple matrix.  But no, we wanted something a little more complicated.  We were considering events where certain paths could be blocked or certain tiles would provide adverse affect to those who stepped on them. Essentially making a tile that would normally only require one step to traverse take two or three instead.  This means we would need some sort of pathfinding algorithm to enable us to take these tiles into account.  However, that’s not all, we also wanted to make sure that the player could see all of his options.  This is where Djikstras comes in.  For those who don’t know, Djikstras algorithm  finds the shortest paths between nodes. A common variant allows one to fix a node as a source and then calculate the shortest paths to all the other nodes in the graph.  

This means its perfect for us.  We want to find all the possible tiles that a unit can move to within a bound, the move limit. Naturally, I took it upon myself to implement it.  

Thing is, it’s not very easy.  C# does not provide a nice graph algorithm built into the collections api.  So i rolled my own, and implemented a bounded djikstras along with it.  Not only that but I also create a coordinate to position and system that associated a coordinate with the game objects that were on top of it for easy access.  

Do you guys follow?  I’m writing this at 1:30AM so I may just be rambling.  

Anyways that took me about 3 days to get working.  I’m still not 100% happy though.  Djikstra’s is supposed to use a MinHeap for ultimate efficiency.  I couldn’t get it working in time, so I just used a set.  Which is pretty bad. Also, I could use memoization to make it even faster by storing previous results so that calculations in the future take less time.  

If you guys haven’t caught on yet, this type of thing is exactly how Fire Emblem implements their movement system.  At least, to the best of my knowledge.  Here’s a picture to drive it home even better. xD

Yup, fir emblem alright.  I swear our game isn’t a straight up copy though.  We are planning on putting our own spins on it, and make it multiplayer.  Don’t worry!

So in summary, we managed to get a workable movement and combat system working, with health, attack damage etc.  However we do have one bug we can’t figure out.

For some strange, unknown reason, you can only select tiles on the top diagonal half of the board, stretching from the bottom left diagonally across to the top right.  It makes absolutely no sense.  The game shows that it is possible to move to the locations below that diagonal line, but won’t let the player pick any of those tiles to move to.  The top half works fine though.  

It

Doesnt

Make

Sense

From what we’ve tested, it seems that the grass tile game objects that we have set up to represent the floor tiles are above the movement tiles that we use to move the player.  The question is, why are they above them? On the top half the tiles work fine, and the grass tiles are below the marks, so that you can touch the marks to tell the unit to move there.  We can’t figure out why this happens, and it’s going to keep bugging us.  If anyone has an answer or possible solution, don’t hestitate to let us know! We’ll also probably update this once we find an answer, which I will make sure we find. I’m stubborn like that.  

[skinnerboxgames-blog]

Some more info on the progress of our prototype.

After hours of tweaking  and bug-resolving we finally have a our tile map software and movement mechanics figured out! :D

The gist of our workflow is relatively simple.  The map starts out as an idea that  we then draw out.  We do this on a tile map editor called Tiled. (Tiled provided by http://www.mapeditor.org/).  The advantages of using Tiled are many. It allows us freedom to focus on creating maps rather than struggling with unity’s own not-so-built-in tile editor. It allows us to give tiles different properties which can then be used to define special behaviors. Finally, it lets us create rooms of a standard size with standard tilesets.  

After we finish the map we import it into Unity with a handy dandy plugin called Tiled2Unity provided by Sean Barton. This tool will automatically turn a map made in Tiled to a fully functioning map prefab in unity.  You can define special behaviors on tiles in Tiled and use custom importer scripts to apply those behaviors onto your map right when it gets imported.  This is great be cause we can define obstacles and add colliders while in Tiled and have them automatically ported to Unity without any extra work.  We can also create certain tiles that can have special affects later on. I love it.

The movement mechanics entails tapping on the player to enable movement and then drag your player to the new location. The tile that is currently selected is instantiated by painting it red. The red automatically snaps to the hovered tile as well the object.  Making all movement essentially based. 

We also made it possible to create new rooms.  Simply tap on one of the four exit tiles on the sides of the map and it will auto create a new room attached in that direction and move the camera there.  Eventually, we hope to allow the DM to choose what type of room to add. 

[skinnerboxgames-blog]

Project Manager Mary here (Going to do my best to not make the post sound salty, just listing our work here)

On the bright side, we did better than last week since we had more meetings and met earlier.

On the dark(?)side we didn’t follow the schedule that I planned (but I didn’t expect us to follow it honestly I can’t expect the group to change quickly and life is not perfect). Below is a simplified version:

(4/17) Wednes: Rough game idea

Thurs: critique rough idea & refine.

Friday: Meet in person and discuss prototype to be completed by Sunday

Saturday: Program/create assets/work on presentation

Sunday:  Program/create assets/ work on presentation

Monday: Debug/critique

Tuesday: Run through presentation

Here’s a more detailed version

For next week, I plan to have the programmers meet on Thursdays and more regularly. The main difficulty we have is that we all have problems adhering to deadlines. As a result, I plan to have more meetings to motivate everyone to stay on the same page.

[skinnerboxgames-blog]

Mechanics

I’m the Lead Game Designer Viditya! I came up with the main mechanics our is trying to achieve, as well as the structure of how it is going to be played. 

Basically I pitch ideas, get really into it, we all create a really ambitious concept, and then I have to strip it down so that it’s both possible to code and is still fun.

This week, we’re attempting to make a turn based game, similar to Splatoon, where 4 players try and cover the board with their color and after 4 turns, the player with the majority of the space over wins. Alec went into a little more detail as to how this could be achieved and works code-wise.

When coming up with the idea for making a turn based game, we immediately gravitated towards a Zone Control type game, whether it be grid based or free roaming. The other thing we really wanted was the ability to generate resources that players could gather either during their turn or while waiting for their turn. The culmination of those ideas ended up with the product we’re currently making. 

A challenge we have to face in creating the core game mechanics was creating a system where, even when it’s not your turn, you’re either doing something or actively watching the screen. We didn’t want down time where, between turns, someone would pick up their phone and check Facebook or something, and that during your turn you’re not taking so much time that the others are bored and lose interest.

Our solution to this was the mechanic of having players generate resources, by tapping buttons and rotating stuff, off-turn. And, when it is your turn, you want to finish it quickly so that you’re not allowing the other players more time to generate more resources. Hopefully this creates a constant stream of action in a turn based environment, and will have players strategizing and re-strategizing constantly.

Another thing we want to play with is using the computer tablet more as a part of our medium, and less like a screen. Something that can really only be achieved with a touch screen this big. The way we’re doing movement is by drawing out the path that your ship will follow, and we’re hoping that players actively bend over the screen, make broad gestures utilizing the large space, and have fun literally drawing their color around the screen.

If all things go according to plan, we’ll have a fun, hectic, turn based game to show off!

[skinnerboxgames-blog]

The management for this project needs to be more organized, and here are some possible ideas for change:

Meetings should have an itinerary (project manager will create)

we will have a set plan for what we need to do before the next meeting before the meeting ends.

Each person's tasks and deadlines will be documented for references

Finalized game play will be documented in a google doc, which programmers will reference from.

Project manager will periodically remind others of tasks and check up on progress.

Regular Working hours will be put into play

Meeting regularly on Saturday (by person or Skype)

Members must be available for reference

Hopefully enough of this will be put in play to keep us sane,

Mary