I’ve been slowly working in a project for computer and console devices, a puzzle-action game based on a prototype I made for Ludum Dare back in 2013. The idea evolved quite a bit and I’m focused now on more puzzles and action, the idea actually changed a lot but the base is still the same.
Since last year I’ve been writing code for physics, gameplay, etc using OpenFL for this projects and after a while I decided to start working with Unity (I want to release the game for consoles as well and it seemed easier). The game involves big levels now and a lot of level creation, so I wanted to use a tool to create levels easy and simple, this really saves a lot of time when testing and changing features.
First I decided to use Inkscape as a level editor, the tool itself is very good and combined with its possibility of generating XML code from the elements you add to the document (graphically) it’s very handy. I wrote a small parser on Haxe for a small prototype I created last year, also used in the first version of this new project I’m currently working on.
It really worked very well when I was using OpenFL. After deciding to work with Unity, I also tried to do the same thing because I wanted to keep the levels separated from the game engine and also Inkscape itself runs faster and better when I’m focused on creating only levels. I wrote a parser in C# of the XML code that Inkscape generates and it worked well too.
Generally speaking, Inkscape is a really good tool for creating levels, it is lightweight and very flexible. Inkscape was also doing the basic functionality I needed from the editor but there was still work to do to really make it good enough for this project.
Unity and Custom editors
Since I’m still in the process of learning about Unity and all its features, I didn’t know you could customize the editor and include custom scripts to minimize the efforts when doing cumbersome or repetitive tasks.
This week while reviewing some code, I found out that you can actually create your own menus and customize a lot of things. So I decided to play a little bit with that and try to create a very small tile editor for this game.
After struggling a bit about understanding how to make everything work, I was able to put together the most basic functionality for the tile editor I wanted: adding tiles as fast as possible, having a grid that snapped tiles automatically to it, removing and moving tiles.
Having this functionality inside the editor while creating levels and the possibility of adding more stuff like rotation, layering, etc is really a great advantage if you want to save time and avoid doing repetitive tasks. I will keep improving what I have so far, keep posting about it and share it when it’s in a decent state for people to play with it.
Before writing this post I thought about detailed explaining how to write a parser for Inkscape and how to create a custom editor for Unity, however, I’m not really sure if it’s worth it. A lot of people have done this before and probably they explain it better than me.
If someone wants to know details about what I did, I’ll definitely explain everything step by step, meanwhile, you can check out the following links that helped me a lot understanding how to both processes work.
This will be a short post about the result of a game I made for Ludum Dare 38 last weekend. I will basically cover why did I decide to participate and how did I come up with the idea.
Recently I’ve been very busy working on other projects that are planned to be released this year. However, after the theme was unvelied, I decided that if could find something that had a message I could transmit somehow (I want to make a full educational game in the future), I was going to participate.
In this case, I focused the brainstorming in two topics: what’s going on in Venezuela (my country) now and global warming. I decided to go with the first topic because this is how I feel can contribute to what’s going on there, we can all contribute to a cause from different perspectives and my perspective is from the game development side.
The Jam lasts only two days and there was not a lot of time to decide what to do. As always I try to keep things as simple as possible and concentrate on a small idea.
important points for the game
Choose a message
Communicate the message clearly
Make something dynamic
Try as hard as possible make it fun
Polish as much as possible until the Jam is over
As message, I just wanted people to be aware of what’s going on in other countries, make people think about what’s happening in other parts of the world. I wanted people to understand that despite the fact that we have different cultures, live in different places and have different ways of thinking, we all belong to the same planet and should care about each other.
I said earlier that I wanted to focus on what is happening in Venezuela and it’s true, however I also think it’s important to take a look at other countries because people are suffering everywhere.
The message is communicated not only in an explicit way in the end of the game but also the whole mechanics are based on the idea of caring about others, helping and cooperating.
The rules of the game are:
Beat the aliens: To beat the aliens, members have to combine the power of their colors to attack
Stay alive: You need at least one house in your territory to respawn
You can attack any alien
You can give one of your houses away
You can repair your or someone else’s house
The game is made in a way that these rules are not explicitly taught. From the game you know you can move, grab and place houses, you can shoot and you can repair houses, but I don’t tell the player “to beat the aliens you need to cooperate”. The idea was that the player understood the rules by looking at the NPC or just using common sense.
The NPCs have different behaviors:
Attack an alien in my territory
If someone helps me, I’ll help too
Give the player a house if he is out of them
Since I didn’t have enough time to make things smoother, I included a condition to randomly decide to help someone sometimes, so the player could understand easier what to do.
The game is really simple. Since the theme of the jam was a small world, I just decided to make everything in a very small world created from four different parts. To add a fast pace, the aliens attack non-stop in a random way. In addition, all the NPCs work very hard to attack the aliens and try to stay alive too.
The focus here was trying to stay concentrated on the main message and make something enjoyable.
After all the basic elements were complete, I just focus on trying to add things that improved the experience of players.
I think that when time is very limited like in a game jam, one should focus first on adding important feedback after finishing the basic mechanichs of the game. Shooting, receiving damage, reparing a house and subtle details to explain how to play were the core of this part.
Also the planet reacts to what is happening in the game, if it’s attacked, everything shakes and when something good happens (like defeating an alien), it winks.
These things are very small but they improve the experience of the game as a whole. I really wanted to put more efforts here but… not enough time.
This is it, I wanted to make a small post and I feel it’s very long already, so to wrap up, this jam for me was different and interesting for the following reasons:
First time I base everything on communicating a message
First experience using Unity for a game jam
I tried to make simple but pretty graphics with a different palette of what I use to
Programming the NPC was a challenge but really fun
So if you have any questions, let me know.
You can visit the Ludum Dare 38 entry here and play the game online or download it in your computer.
By the way, I’ll still think about the idea for the global warming game, I think it’s an important issue.
In a previous post, I introduced the structure I’m using to create games with OpenFL, also explained about the purpose of the Screen Manager and a brief explanation on how it works. This time I would like to explain the Graphic Manager, which is also a very important part of the small system I’m using.
The Graphic Manager is a unique and centralized system that handles all the operations related to the screen, including coordinates system conversion, bitmap loading, spritesheets loading, etc, they all work as helpers to make recurrent operations easier for the programmer when creating a game.
The repository for this system is located here in case you want to see the code. Please consider that it’s still being improved and needs more documentation.
Fixed width and height
Fixed width and fixed height are base parameters decided by the designer when creating the game. For example, let’s say I’m making a landscape game and the base reference size that I’m using in design is 1280×720, this is the size of the screen I am using to position all the elements, the base size and base positions of all elements.
Once we have the fixed width and height decided, we pass those two values as parameters to the Graphic Manager and the system adjusts all the elements to make them look as in the base design regardless the screen size.
Sprites and backgrounds paths
We also pass as parameters to the Graphic Manager the sprites and backgrounds paths, this way it’s easier and cleaner to deal with sprites in the whole game and screens from the Screen manager.
In order to create 2D animations and make them work, we need spritesheets and a good system to use them. I’m not going to talk about the specific of animations in this post, only an easy way to load spritesheets.
The Graphic Manager system uses a TileLayer extension of OpenFL that can be downloaded here. This subsystem is used to render sprites efficiently on the screen and manage spritesheet elements in a convenient way.
The TileLayer extension includes a Sparrow parser implementation, which needs the spritesheet itself and a data file that helps mapping and indexing all the sprites in the spritesheet.
This is an example of a data file that helps mapping sprites and data:
In the Graphic Manager system there are helpers to create, load and use these spritesheets very easily, the only thing that we need to do is to put spritesheets and data on the same folder with the same file name, with LoadTileLayer we can get all the necessary data to work.
If you are curious about what tool is used to create the spritesheets and data, it’s called Sprite Sheet Packer, you can adjust the data format as you wish, it was adapted to fit the Sparrow format in the Graphic Manager system.
As I mentioned in the beginning of the post, all the elements are adapted depending on the current size of the screen and the fixed size set when instantiating the Graphic Manager system. In order to make all the calculations work, there are a lot of different helpers to convert values to the current size of the screen depending on what we need.
For example, in the previous two images where the base size of the screen is 1280×720 and the current size of the screen is 1024×768, we can see in the following two images how the “Play” button position is converter from one coordinates system to another. To achieve this we use the helper functions that Graphic Manager contains.
The work that the Graphic Manager system does is not complicated at all but is really helpful to save time when coding. The class is a singleton that can be accesed from any part of your code (in any project if you import the extension) without being imported in every class, which saves a lot of headaches and time.
This is basically what I wanted to show today, a very simple way to handle common operations without too much trouble and code.
If you have questions, feel free to ask, I’ll probably talk about Animation in my next post.
Since Ludum Dare is going to happen this weekend, I decided to put together few ideas of things I’ve learnt participating in LD and some other game jams. I believe this could be helpful, specially for people that are participating for the first time.
1. Set a Goal
I think it’s good to set a goal before you start your jam, regardless what you want to do, it helps you stay on track all the time and in the end will be easier to achieve that goal if it’s very clear for you.
By setting a goal I mean what you want to accomplish with the jam and is not necessarily making the game. For example, you could decide to learn a new tool or improve the art of your previous game.
In the global game jam of 2012, learning HTML5 was one of my particular goals of the jam. We managed to create a very simple game: Serpens Ruby. Since we didn’t know how to use HTML5 that well, we struggled a lot but the experience we got those two days helped a lot to create Fluff Eaters in HTML5 later the same year, which turned into a commercial project in the end.
Another example, my last Ludum Dare in 2014, I wanted to improve the art of my games with KIWI, the overall game is not that cool but I managed to accomplish what I wanted, compared to the previous jam, the art was much better.
2. Choose the right tool
If the goal of your game is not learning a new tool then choose the best tool you can use. A lot of people use big engines like Unity, others prefer work without engines, it really doesn’t matter what you use, if the tool you use suits you well, that’s enough. Focus on whatever language or tool that helps you turn your awesome idea into a playable game, something that fits well the idea you want to communicate.
For my first LD I used one of the few tools I knew how to use at that time: XNA, which now I think is not the best tool to work with for a game jam but at that time it helped me create a fully playable game.
Two days is a very short time to create something that is good but it’s possible. Before starting, think about general steps in the process of creating a game, what you have to do in order to start with an idea and end with a fully playable prototype and set time limits for each task. I’ll give you an example of what I usually do:
First eight hours:
Brainstorming – around 3 hours, maybe more –
Proof of concept – 4 hours –
Test – 1hour –
Next fourteen hours:
Programming (focused on the core) – 7.5 hours –
Art (focused on the concept) – 5.5 hours –
Test – 1 hour –
Last fourteen hours:
Programming (use feedback to improve, juice) – 7 hours –
Art (use feedback to improve, add details) – 4 hours –
Sound – 3 hours –
Depending on how you progress following the schedule (which is only a guideline), you’ll be able to evaluate whether you have to make changes to it or not, you’ll iterate depending on how everything goes.
4. From the core to the edge
Identify the core features of your project, what is the most important part of it? usually for most games mechanics are the core. Once you decide what the core of your game is, give priority to the rest of tasks you have to complete.
Focus on the core until it’s working as you expected, after that use the priority list to keep working on each task until you complete all of them or until time is up.
The advantage of working in this way is that if in the end you cannot finish what you expected, you at least will have the most important part of your idea done to show to other people.
The way I usually decide the priority list is described as follows:
Goal (winning condition if there is any)
Challenge (losing condition)
Extra (effects, better graphics, better sounds, etc)
Of course depending on the game, some of the elements in the previous list won’t be necessary or will change, just identify how this strategy works for you and apply it.
5. create for the Web
If you can choose a tool that has a capability to export to web (preferably HTML5), then use that one. The main reason for this is that you want people to play your game, after the two days of hard work, the game you make will be played and rated; the more comments, feedback, rating you get, the better. Not everybody has Windows, not everybody wants to click 3 times to download and play your game, the sooner they get to it, the happier they will be.
After finishing the core idea of your game, when you have a playable prototype that is strong enough to communicate what you wanted to make, you can focus on adding – juice -, which I really believe will make a difference and will make your creation stand out from the rest.
Adding little details that make the game feel better is something that any programmer can do, feedback is a very important part of what makes games feel – right – and you will appreciate it.
If you haven’t watched it yet, take a look at the following talk about juice, it will give you ideas to improve your creation.
Finally, everybody says this but sometimes we forget how important it is. You have to sleep, if your body is not in optimal contidions to work, you’ll very likely make a lot of mistakes, that you’ll have to fix and possibly will lead to failure. If you read tip number 5 you’ll notice that the schedule I showed as an example includes only 34 hours, the other 14 are ideally for resting.
If you have questions, comments, suggestions, whatever you want just let me know on the comments, good luck with the jam and have fun!
From now on, I want to write a post every week so I keep you updated about what we are doing and share some thoughts on different things that have happened since the last post I wrote.
I would like to summarize all the significant things that Fiery Squirrel has been through last months, will try to keep the post short and simple. It will basically cover status about each project the Squirrel has been working on and few tips that might help other developers.
So let’s start with Fluff Eaters, game that I mentioned in a previous post that I was going to take a break and stop working on it for a while.
Last year in October, Fiery Squirrel partnered with a new publisher called Apartment 507 to promote and market the game as it was in order to improve sales, downloads, etc. Our agreement basically said that for one year we were going to work together to improve the game and create a better experience for players. We have tried different things with the game and I would like to mention few of them here.
The first big thing we tried was create a Holidays vesion of the game with new content, new levels, new mechanics, etc. You can check the final update here and very likely we will make it available again this year.
As you might notice, the art style is slightly different, Fiery Squirrel is working with Gabriel Uguet, who is a very good illustrator and graphic designer, I’m also working with him in a completely different project that I probably will talk about later. In addition, the theme of the new world was composed by Stefano Merino, original musician of the game.
With this new update, our players could enjoy new mechanics and also we were able to include new features in the game, a bunch of new players, existent and new players interacting more with the game, etc. In general it was a good experience.
But not everything was easy, we also faced different issues. The cycle of work we had, time constraints and all the work we needed to complete was enough to keep us very busy every day and night for one whole month. From the brainstorming, mechanics design, elements, characters, art, sounds, etc, was a lot of work and the worst part of that, even though we managed to finish everything on time, we didn’t consider that the iOS build was going to have issues when we uploaded to the AppStore, it was seriously something not only unexpected but very weird.
Before uploading the game we tested a lot in different devices, it worked well, we uploaded, Apple said there was an issue with the build, we tested a lot again, didn’t find anything weird, compiled again and upload again and it worked (we still don’t know what happened), the bad part of this was that we missed our deadline (on the marketing and promotion side was very important) but I guess we learned a lot.
Try to include everything related from the brainstorming to the release on the market in your schedule, every possible step that you have to take in order to see the game in the market from your device, whatever it is, PC, mobile, the last step always will take a lot of time too and, if (like us) you are small team, it matters.
Pax South 2016
The second big thing I want to talk about is Pax South 2016. We had the opportunity to be at the event this year, it was a very nice experience, we met other developers there ( including Rami Ismail who talked to us about his experience at Pax and other events), were able to test new features, see how a different group of players reacted to the game, promoted the game with different types of promotional material for the first time, etc.
Fluff Eaters was presented at different events in the past and all of them have been a great and unique experience but Pax South was particularly interesting. The main reason is the type of player that played the game at the event, the core mechanics of Fluff Eaters are based on Jacks, which is a game that a lot of people from the U.S. are familiar with, so many of them understood and seemed to enjoyed it very much. Besides this, the response of people was really amazing, a lot of them downloaded the game and played it.
This is something I’ve said before but going to this type of events is very positive for developers in different ways. You might be interested on a post that Apartment 507 wrote about the details of the event, expenses, promotional material etc, you can read the full article here.
These caps were not part of the promotional material that we gave away but were an amazing present from my brother (also part of the team). Depending on how things go (if people are interested), we might sell them in the future.
I guess I could keep giving details of what we have done with Fluff Eaters so far but I also think I spent a lot talking about this game before. In few months the contract with the publisher will come to an end and we will spend the remaining time to keep testing things and trying to improve as much as we can, if you have specific questions please let us know.
Collow is the second project I want to talk about and I’ll do it in a very short way. This idea started long time ago but has been put on hold some times, however, the project will be released for sure this year, the thing is I haven’t have enough time to finish the code for this. We are also accepting playtesters (this is the next step we are going to take) so you can sign up here if you want.
This is a game made for Venezuela Duel Jam 2015 and was the lastest jam Fiery Squirrel has participated in, you can play it here. I know it’s old information but since didn’t mention it before, I would like to at least show it to you. It started as a very simple idea around the theme and I ended up liking it a lot so it will for sure be fully developed (don’t know when) and released as a mobile game.
With this game I wanted to achieve few things:
Focus on the aesthetics more than usual: In previous game jams aesthetics were not focal point, Chicks does not have awesome graphics but at least they are better than previous games
Simplicity: Easy to understand, easy to grasp, challenging and entertaining
Mobile: Something that could become a commercial title for mobile devices
Complete: A fully playable game
In the end, the game ranked first in the event and more important than that, the feedback from other developers was really good, comments, advices, etc, which will for sure be a key factor when developing the full game.
The last project I’m going to talk about for now. If you follow us on twitter you probably know what this is about. This is the project currently developed by Fiery Squirrel, it’s a very simple and short idea that emerged from the fact that there is a lack of popular and good games that involve the idea of the Sakura (Cherry Blossom) from Japan, in addition to this, I wanted to start getting involved in the artistic part of the games I make and tried to design something aesthetically appealing.
The game is not ready yet. Despite the fact that the idea is very simple, I haven’t had enough time recently, these last months have been busy, however there is significant progress on it and we will playtest it very soon.
The plan is to complete the first chapter of the game which includes 4 different trees, each tree has 4 levels on it, a bonus level and a boss in the end. Depending on how people react to the game, the response we get after playtest and release, it will be decided whether the rest of the chapters (3 more) will be added or not.
This post is longer than I expected, just wanted to summarize what Fiery Squirrel has been doing since the last post. For all of you that are using OpenFL, I still update the repositories in git, I would like to focus more on the implementation of new things and what is there at the moment, there is a lot of uncommented code that might be helpful for someone so, I’ll try to document it as soon as possible and focus future posts on it.
Please feel free to ask questions, if you are a developer, I can talk more about the design or programming of any project you see here, whatever you are curious about just write it on the comments.