Jan 9, 2012 by TeeGee
It’s no secret that most of MoaCube’s projects are developed in GameMaker. I’ve been using it for 7 years now. Sometimes simply to play around with ideas, but mostly for commercial projects and some rapid prototyping back during my days at Codeminion.
I’ve developed a certain love-hate relationship with the software. We’ve had some good times together, but there were times when I considered filling divorce papers and turned my head after the younger and sexier Unity. So far, we decided to stay together. For the kids’ sake, you know.
GameMaker is a rather popular tool among amateur and freeware developers, but you rarely see it used to produce commercial-quality games, and there aren’t many publications on how it fares in professional game development.
With YoYo Games trying to attract more serious developers with the release of GM HTML5 and the upcoming GM Studio, I thought it could be interesting to do a little rundown of the good and the bad in the software from the perspective of someone trying to utilize it for commercial work.
The Good:
Fast development: This was always the main advantage of GameMaker and other similar tools for me. You can develop damn fast in it. During the DBC game jams I was able to create working projects in only a couple of hours. Working as in: fully playable, with complete mechanics and already looking somewhat pretty. At Codeminion, I sometimes found it faster to show the programmer what I want using a GameMaker prototype, than to describe it and go through several feedback loops.
Being able to develop fast is crucial when you have to worry about budgets and deadlines. Of course, a skilled C++ programmer can work similarly fast in a good framework. But — well — you need to pay that programmer and spend months on developing the framework first. GM saves a lot of time and money here.
It’s very flexible and pretty capable: Think about any 2D game you like. You could probably do it in GameMaker. It’s a huge advantage over the more focused game creation tools like Ren’Py or RPG Maker. Even custom-built engines are usually done to meet needs of a particular game or genre.
Meanwhile, GM can be used to make arcade shooters, complex RTS, platformers, visual novels or any experimental game you have on your mind. Not having to learn new tools for each project saves a lot of time.
Performance is a-okay: I often hear that GM’s performance is its biggest issue. Well, hardly (as you will see later). It’s more than capable for most 2D projects. Of course, if you want to make something very technically-advanced, you probably would be better off writing your own engine. But let’s be honest — most commercial 2D games don’t need to be cutting-edge. You generally want them to work on older machines, as it’s a big chunk of the indie audience. Nice art is usually more important than pure tech-prowess here.
I consider ArcMagi and Cinders to be relatively pretty games, with plenty of effects, particles, cool transitions and such. They both easily maintain 60fps, even on netbooks or older hardware. I never really felt like I have to cut something cool out to prevent framerate drops.
I think part of the problem is that GM is very simple to use and it’s tempting to be lazy. It’s easy to just include all the art assets within the project, draw them all on the screen with tons of particles and then complain that it slows down and uses too much RAM.
Most of the slowdowns can be solved with simple optimisations and more responsible memory use. Which is something you have to consider in any commercial game, regardless of the engine. I assure you that when I was working on Phantasmat, using a much faster custom-built engine, I still couldn’t slap everything I wanted on the screen without any considerations for the lower-end hardware.
It’s cheap: Just that. It’s cheaper than pretty much any other commercially-viable engine. It doesn’t matter that much when you have budgets in the tens or hundreds of thousands, but for a small indie developer, paying over thousand bucks for Unity and a few plugins, just to try it out, may be a big deal.
It’s easy to learn: GM was designed as a teaching tool and it shows. It’s pretty easy to grasp, syntax rules are very leeway, documentation isn’t written in Klingon and there are many tutorials available. It’s something even an artist without former programming experience can pick up and use. It allows for more participation from your non-techy team members, which is a big advantage in small teams. And let’s not forget that time used to learn new tools is development time as well.
Predictable: Except for a few hurdles I’m going to list in the next section, GameMaker is pretty predictable. It’s been around since quite a while and it uses pretty low-end tech. If it works for you, it’s probably going to work for your clients as well. If it doesn’t, you can assume it’s your and not the engine’s fault with a good degree of certainty. Depending on the complexity of the project, this can shave off a few weeks or months of QA work.
Good multi-platform prospects: HTML5 exporter is already out. iOS, Android and a few others are coming later this year. Many games have been internally ported to iOS by YoYo Games already. Even given that it will likely have some troubles at start, it looks like the tool is going to get even more universal.
Lack of competition: There simply aren’t many alternatives. Coding your own engine can be superior but takes precious development time. Lots of it! Tools like Ren’py or RPG Maker focus only on a certain type of games. Construct, Stencyl and MMF2 all use visual coding that gets very hard to debug and read as the project grows. And using Unity to make a 2D game is like trimming a bonsai tree with a chainsaw.
GameMaker may not be perfect (oh, believe me, it’s so not), but it’s still likely the best rapid 2D game development tool around.
The Bad:
Bad first impression: To get GameMaker, you have to go to the YoYo Games’ website. It looks like poop. Then you download the software, boot it up, and hey — a big shocker — it looks like poop too! Gotta love that Windows95 feel!
It’s superfluous but it scares many developers and makes them waive GM as a kids’ tool. It’s not (at least not exlusively), but it certainly doesn’t make the best first impression.
Mac versions sucks like an atom-powered Dyson: No, really. It’s b-b-bad! First of all, it’s based on the GM7.0 while the Windows one is v8.1. This means that compatibility goes only one way. If you have a project in v8.0+ you can pretty much forget about porting it to the OS X. And it’s not even the biggest issue here.
Initially, it just didn’t work. As in: it was impossible to make a game in it. It crashed on every other function call, it was impossible to load a sprite with transparency, and drawing more than three lines of text was enough to slow the game down to a crawl. To be able to work on Cinders and release Magi on the Mac, we essentially had to do few days worth of QA work for YoYo Games. Got in contact with the developer, filled several bug reports, added better reproduction steps and examples to the bugs reported by other users, and so on.
It became usable eventually, but it still has more flaws than it’s worth to count. The interface falls apart, code editor has a mind of its own, and don’t ever count on error reporting to tell you what caused a crash if one happens. It’s just going to freeze or produce a bogus error message. If you know your way around GM with your eyes closed, you’ll manage. But if your first experience with the tool is on the Mac, I pity you.
It’s worth noting that the upcoming GM Studio will have an option to export to Mac and should be free of these issues. However, it’s going to be Windows only. If you ever tried to debug a game’s port without being able to work on the computer you’re making it for, then you know what that means.
True multi-platform development is said to come with GM9. ETA: chances are that if you look outside of your window when it comes out, you’ll see this.
Issues with fullscreen on Windows7: For some reason, GM gets lazy on Windows7 and doesn’t want to use interpolation for scaled image. It defaults to a basic nearest-pixel algorithm instead. It looks like this.
Why is it important? Because it happens when you run the game in fullscreen and it has to be scaled to fit the screen (you can’t possibly support every existing resolution natively). Most engines produce a slightly blurry, but overall workable image in this case. So does GM, unless the user runs Windows7 (hardly a niche).
Now, imagine you are making a casual game to sell on BigFish Games. Something GM is theoretically perfect for. You finish the game, it gets initially accepted and you receive their tech requirements doc. One of the first points is: “The game has to open and run properly in fullscreen”. Have fun.
Sprite loading issues in GM8.1: Oh, this one! Still sends shivers down my spine. Some of the Cinders pre-order owners probably remember it. Soon after the preview version launch, a large portion of users reported that the game crashes during scene loading. After some investigation, we figured that it happens on older computers, lower-end notebooks and netbooks with integrated video cards. So, about 20%-30% of our userbase. Scary.
We’ve spent two days and nights trying to reproduce and fix the issue. I pretty much haven’t slept for that whole time. After all, folks paid for a game that wasn’t working. Thank goodness it happened during the beta and not the official launch — that would screw us over completely. Eventually, Marius was able to find an old PC that had the error. After another day of testing and desperately trying to find the reason behind the crash, driven by a hunch, I decided to compile the game under GM8.0 instead of GM8.1 and see what happens. It worked!
Turns out that GM8.1 likes to crash on weaker PCs when loading larger textures. Something that probably won’t happen when you are just playing around, but is commonplace in bigger projects. It took a few weeks of bothering Russell Kay (one of GM’s programmers, a very cool and supportive fellow by the way) to get it fixed. Now it doesn’t crash, but instead produces weird graphical glitches and major slowdowns on the affected PCs. Cool, huh?
In the end, I have to use GM8.0 for all my PC releases (good thing that I kept the older version), even though I paid for GM8.1. The problem is that GM8.0 has some issues with font anti-aliasing that were fixed in 8.1 Argh!
Awkward dev schedule: You would think that the above two issues are pretty significant, and should be fixed as soon as possible. After all, loading assets and pixel interpolation can be considered core functionality.
Well, as of now, GM8.1 hasen’t been updated since several months and the programmers are focused on GM Studio and HTML5, both unfortunately based on the broken GM8.1 codebase. The fullscreen issue in particular was waived as something to fix in GM9.
It has to be said that both programmers working on GameMaker seem to be very competent and smart people. But one can’t stop wondering if they aren’t mismanaged. Focusing on new releases, while the core product is still kinda shaky, seems like a weird strategy to attract more serious developers.
Built-in editors are bad: GameMaker utilizes various built in editors for art assets and level design. They are all pretty unwieldy. It never bothered us much, as we just use normal graphics software for the art and our own solutions for level building, but it’s worth mentioning that you can’t expect to make much use of what’s already there. It’s possible to drag some objects around and make a simple game, but a larger commercial project — not so much.
Lack of portability: I said that publicly available exporters for Mac, iOS and Android are coming soon. It means they aren’t available now.
That is unless you want to go through a pretty unfavorable deal with YoYo Games (50% royalties, exclusivity, they are listed as the developer, some negotiations possible) to get your title ported. The fact that the multi-platform GM Studio is going to be based on the faulty GM8.1 also doesn’t bode well for the program’s reliability.
In general, if you consider smartphones to be an important part of your business model, I would say that using GM is too risky. At least for now.
Teamwork on GM is hard: GameMaker uses a single file for its projects. This means that co-operation with several team members and version control are a pain in the ass. GameMaker HTML5 and the upcoming GM Studio are going to store projects as a folder structure (much like Unity) so the issue is temporary.
Uncertain future: Being honest, GM is getting more and more outdated, while tools like Unity or Stencyl are getting progressively better. Latest GM releases also weren’t too reassuring, especially the Mac version. YoYo Games struggles to become profitable and focuses more and more on game publishing. It’s hard to predict what will happen to the software in a few years. It has great potential for sure, but I prefer to be cautiously pessimistic.
Summary:
So is GameMaker worth recommendation? For amateur or more lightweight indie — for sure. It’s fast and easy to use, and the above issues don’t affect smaller games that much.
For commercial projects? Not yet unfortunely, unless you really know what you are doing and can live with the problems. It’s fast, flexible and powerful enough, but you risk that one of its quirks will bite you in the ass at the end of a project, and you can’t really count on it being fixed fast.
Using us as an example, we’re happy that we picked GM for Magi, ArcMagi and Cinders. All three games work as intended without making any sacrifices, look rather pretty, were fast to code and can be easily expanded or altered. We’re especially happy with what we’ve got in Cinders. A pretty flexible visual novel engine, similar to Ren’py, but able to produce much nicer graphics, with the possibility to expand it easily with more gameplay elements. And it took less than three months to code from scratch.
We definitely see ourselves using GM for some of our future projects, especially VNs and the more experimental stuff. However, we recently pitched one of our game ideas to a few friendly companies, to secure MoaCube’s stability undermined by the Cinders delay. A bigger game, requiring at least $100k to make. We strongly considered doing it in GameMaker. It seemed perfect for the job, but we eventually decided that it’s too risky and opted to license an engine from an established game developer.
Let me reiterate: when faced with the responsibility of having to spend actual money that isn’t ours, we concluded that using a completely new engine is less risky than working in software I’ve been using for the past 7 years. It made me think. You should consider it too.
GameMaker is a tool with much promise, and may well become a viable choice eventually, but it needs more time and better handling from YoYo Games. They could probably use some constructive feedback that’s not just straight hate, so if you are a professional indie developer, consider getting in touch with them and let them know what bothers you about the software and what improvements would be crucial for you to consider using it. The guys there really wish well and deserve the chance.
Nov 11, 2011 by TeeGee
Being an indie can get very lonely. It’s my main gripe with it so far. I don’t have problems with motivating myself, work/life balance is hard but not impossible, and money issues and overall uncertainty are balanced out by the benefits of the indie lifestyle. The lack of people to talk to however, it gets to me.
You sit at your home, or in a cafe, coding weird games that the general public doesn’t know or care about. No office mates to talk to, no lunch breaks to share the latest batch of stupid jokes, and no co-workers to go out for a few beers after a hard day of work. And your “normal” friends really don’t want to know how you solved that interface issue that bothered you for the last week.
Living in Poland is a factor, too. Our game dev scene — while quickly growing — is still relatively small and centered. Bigger companies can be counted on fingers of one hand and smaller ones only really started to emerge. “Indies”, in the western sense of the word, are few and far between.
I think partially it’s because of our gaming habits. We weren’t raised with Nintendo (it wasn’t even officially available here), consoles are a relatively new thing, and gaming is still a bit of a nerds’ niche. We’re largely PC gamers, interested mainly in RPGs, and it’s not uncommon to meet hardcore gamers who never played Zelda, Castlevania or Mario (sometimes even heard of it). We’re not rooted to love platformers or simple retro stuff like the USA gamers. We like big, complex games. Preferably with swords, dragons, branching storylines and two pages of character attributes.
And those are not a good fit for an indie team of few bedroom coders and their artist friend.
This makes me look with envy at the indies from the USA, Canada or Sweden. Whenever I see pictures from a gathering like TIGJam, No More Sweden or the IGF, I realize how I miss having a bunch of similarly-minded individuals around here.
Up until now, at least.
Few months ago, Artur Roszczyk, a developer friend, approached me with an interesting idea and asked if I’d be up for it. He wanted to organize bi-weekly game design workshops. Design Boost Camp or just DBC for short. Something like the TIGJam, but not exactly.
The concept was to make it a bit more focused on the educational aspect rather than rapid game development. Instead of having a bunch of seasoned developers come over and code games for fun, he wanted a mix of veterans and promising amateurs who would like to learn game development.
I admit I’m usually pretty sceptic towards such ideas. They always sound cool in theory, but are really difficult to actually pull off. It’s hard to find the right people, and the organizers often lose their interest after a while or find it to be too much work to marry with their normal daily schedules.
Fortunately, I was wrong. We have five DBCs behind us, and the initiative is still alive and kicking. I gotta give props to Artur here. He managed to involve some really cool people, secured a nice place with enough room, wifi and a projector, and works hard on making sure that every meeting feels fresh. And somehow, he’s able to keep at it, despite having a full-time job and other projects.
Each DBC has its own flavor, but generally it always involves discussing various game concepts. Your own, brought by other people or dictated by a set challenge (like: make a game that captures the feel of a certain short film). After that, it’s free for all. You can assemble a team and try to implement your game idea or at least prototype it, help others with their concepts, give a lecture or listen to one, or just play some board games. It’s nerdy, creative fun at its best.
And boy, has it done wonders to get those creative juices of mine flowing! I missed working with other people so much! Just the general dynamic of brainstorming, joking or even arguing with other game makers.
I also really missed the anything-goes experimental game development. One without any deadlines, commercial viability or strict rules to worry about. On the first meeting, our team lacked a graphic artist, so we’ve made the “assets” for our game by photographing play-doh figures. With a laptop. Good times!
I should be able to release the first playable fruit of these meetings soon. A small experimental arcade game with art done using crayons, pencils and scraps of paper (can’t get more indie than that). I talked about it a bit in the news section.
It’s a co-operative arena shooter for two players. You kill some space monsters, score combos and reach for the highscore. Standard fare. The gimmick is that you can’t shoot. Your ships are connected with a stretching stream of energy and the only way to kill foes is to catch them with the beam, which requires co-ordinating your actions with your partner. Who of course does exactly the opposite of what you wanted, making the game more challenging and fun than it should be.
Total development time is probably still under 24 hours, but it’s great to see how a simple and wacky idea can actually make for an entertaining game. Working only on big, high-quality projects for the past few years, I really missed the feeling. It’s going to be freeware, of course, and I plan to make the editable source file (it’s done in GameMaker) available.
I have nothing more to say here, nor do I have any particular point to make. It’s just that the DBC is exactly what the doctor prescribed, and this joy had to be shared. Thanks, guys!
Oct 21, 2011 by TeeGee
I admit that I didn’t care much about player choices up until recently. A strongly directed experience is usually better than a diluted one with few — often meaningless — options to pick. After all, you get to see only one story at a time, so it better be as good as possible. And frankly, most modern games don’t do it very well either, usually limiting themselves to binary moral dilemmas tied to some karma system.
Working on Cinders required me to revise my approach, though. As a visual novel, the game is all about the choices and experiencing a different story each time you play. Without this aspect, you would be better off just reading a book.
It made me think a lot about what makes for a good branching storyline, and how to make player agency as enjoyable as possible. As I wrote before, I’m a competitive beast driven by the ambition to 1-up what’s already there, so I really wanted to get this aspect right.
I started forming a loose list of guidelines we want to follow, based on what worked (or didn’t work) in other games I played and on our own experimentation.
Make all choices viable.
I recently played Deus Ex: Human Revolution. As its predecessors, the game makes big fuss about the player’s freedom. Jensen — the protagonist — can be a ninja, a diplomat, a hacker or a killing machine. You can play however you want. In theory. In reality… not so much.
At first, I wanted to be a common sense Jensen. Stealthy when necessary, but not shying away from direct assault if the odds are in his favor. When I finished the first mission, I had around 4k experience, no level ups, and I was scolded by every NPC around.
I decided to try again with the stealthy approach to see how it changes things. This time I knocked every opponent down silently, checked every hidden vent shaft, and avoided any direct confrontation. It actually ended up being easier (and more tedious) than the first playthrough, as the AI isn’t very bright and your character is pretty fragile in combat.
I ended the first missing with 9k experience, two level ups, and two unlocked small side-quests. Right…
For a game that encourages freedom of choice, it surely made one of the alternatives way more optimal than the other. I want to avoid that in our games.
I’ve set myself a goal to make every choice viable and interesting to pick. Especially as it’s a story-based game. There’s no “strategy” or “challenge” here. You’re just experiencing a certain story and shaping it to your liking. One person’s story should be different than the other’s but not better or worse.
It doesn’t mean we don’t have any “bad” options or ones that may not be the right course of action for the presented circumstances. But we attempt to make them viable by allowing them to create interesting situations or give new insights into some character’s personality. We don’t want the player to ever feel like they just picked the wrong option and should load the game. Whatever they do, it should still make for a good story.
A simple example of this approach is right at the start of the game, when the Stepmother tasks Cinders with some business in town. On her way, Cinders may visit several places, meet some characters and progress few story arcs. Or she may just skip right to her destination and get back.
Clearly, the second option makes the player see less of the game’s content and could be considered sub-optimal. To prevent that, we’ve made it so that if Cinders gets back early, she manages to impress the Stepmother with her efficiency, which can lead to a whole different story arc. So while the player may have sacrificed a part of the content, they are rewarded with some cool scenes that they would otherwise miss.
Allow for flavor choices.
By “flavor”, I mean choices that don’t have much gameplay weight but allow you to add some flavor to your character’s personality. Role playing basically.
One thing I adore in the first two Fallouts (one of my favorite games of all time, even if they didn’t age very gracefully) is that they had a very broad set of dialogue options for almost every conversation. Even when accepting a quest, you could reply in many more ways than a simple “Yes” or “No”. You could be heroic, cynical, a tough mercenary, an annoying wise guy, or you could try to seduce the guy for more info and rewards. It still lead to the same quest, but allowed you to shape your character’s “image” to your liking.
Availability of many of these options depended on your stats and karma. A stupid character could barely make a coherent sentence (playing a total dumbass was a great challenge in itself), a charismatic genius had a broad range of differently flavored responses, while an expert scientist could ask for some advanced technical details.
It went a long way in allowing for some good old roleplaying, and gave the game a huge replayability factor. I played it as a classic Mad Max-like mercenary, as a sleazy female manipulator, as a focused martial artist in vein of Bruce Lee movies, and as a psychotic drug-addicted killer.
AAA games don’t do that anymore. They usually use a much simpler solution, where you have three clear answers to every situation – good, bad and neutral. Often tied to some karma system.
It’s understandable. These games need to keep mass-market appeal, and mass-market doesn’t like to read too much. It would also cost a crazy amount of money to record and animate all these different dialogue options, something that older games didn’t have to worry about as much.
Cinders — and visual novels in general — are not big budget AAA molochs however, and we have way more flexibility here.
I want to give player the option to play any Cinders they want. Differing from other people’s interpretation of Cinders not only in actions but also in the way she thinks and speaks. Besides plot-critical choices, we offer many that are simple roleplaying.
For example: when one of the stepsisters teases Cinders by implying she surely dreamed about a handsome prince or something equally silly, we get the option to either ignore her remark, take offense at it, admit it may be true, or turn it against her. Does it alter the story in any meaningful way? Well, it adds some points to a secret variable storing Cinders’ personality, that is later used to determine the ending, but not much more.
It’s too minor to significantly affect the plot, but it allows player to define Cinders as a romantic dreamer, disillusioned realist or something in between. It doesn’t cost us much to add these few extra lines, but it adds some value for the player.
Leave all important decisions to the player.
I’ve made this rule after playing Bionic Heart. It’s a sci-fi romance VN by our friends at WinterWolves. I went through it as a part of my research when we were just starting out. It was fun overall, but there was one moment that really irked me.
The plot resolves around a mysterious cyborg (who happens to be a beautiful woman, of course) who appears at the protagonist’s door one day. It results in an investigation about the cyborg’s origin and potentially in a somewhat creepy romance.
I was playing for the romance option, trying to please the robot by working to discover as much about her as possible. Pretty far into the game, when I got our “relationship bar” to the max, the cyborg started to behave clearly affectionate towards the protagonist. It seemed like the romance plot was clearly heading for its resolution…
And then suddenly my character stated that he doesn’t find her attractive anymore, now that he knows how she works, and ended the relationship. This wasn’t a choice made by me — the game just told me: “Sorry, bro. You changed your mind”. I was pissed. Why an important decision is made for me, when I was clearly in control of my character up to this point?
I try to be very careful not to make the same mistake by leaving all the important decisions to the player. It’s not easy sometimes. Especially when I want Cinders to be at some place and time in every playthrough, regardless of the chosen option. Some cool scenes actually emerged from moments when I just couldn’t think of anything and had to include the “what if the player doesn’t want to go there” option.
Choices should be clear.
This is a simple one. I hate when I pick an option in a game, thinking this will make my character do A, but he ends up doing B, because the designer’s interpretation of what’s my choice was different from mine. Sometimes it’s even intentional. Supposed to keep the players on their toes or add a bit of realism to the game. It ends up with a short trip to the Load Game menu either way.
Some of those L.A. Noire interrogations are a good example here. Sometimes you clearly think you just caught your witness lying about something, but when you press the “Lie” button, the protagonist suddenly becomes strangely violent and accuses the subject of something completely else, leaving you with a funny WTF impression on your face.
To some extent it’s unavoidable. People think differently and make different connections in their minds. You can’t predict if what seems like a transparent decision for you is going to be as transparent for someone else. But we’ve made a rule to at least try to make it always clear what you are choosing and what the outcome may be.
If you decide to be nice to someone, it will probably have a positive effect on your relationship. If you click “Be seductive” you will do just that. And if choosing a particular option may have significant repercussions, we try to indicate that it’s a possibility through earlier dialogue.
I think it’s important to let the player feel they are in full control of their character’s actions. It’s the visual novel equivalent of making sure that controls in a platformer game are tight.
Acknowledge player’s choices.
Playing games is largely about the rewards. In casual games, every right action is accompanied by a nice effect, pleasant sound cue and an increase in score. In Mario, collecting 100 coins rewards you with a 1-up. In RPGs, you get experience points for killing monsters. And so on.
It makes game more entertaining and — well — rewarding to play. We like our efforts to be appreciated, and it makes us want to come for more.
In story-centric genres, it gets a bit less obvious. Often, the story or the dialogue itself is the reward your actions. A simple and very direct example is an NPC thanking you for saving his village in an RPG.
A more subtle — and often more rewarding — method is to add small acknowledgments of player’s actions and choices to otherwise mundane dialogues.
We keep track of most of the decisions the player makes and add some extra lines depending on them here and there. For example: in one scene, the Prince is talking with the Captain of his guard about his problems with finding the right wife. It’s just a cutscene that goes always in the same way and serves to establish the Prince.
However, if the player chose the course of action in which Cinders meets the Captain of the guard, it makes him add a few lines about an interesting girl he just met. It serves no plot purpose, but it feels nice that the game acknowledges what you did.
It’s like when an old friend suddenly remembers about your birthday and calls you with wishes. A simple gesture that doesn’t cost him much but makes you feel happy nevertheless.
Of course, I don’t want to get all cocky and say that it’s the definite list of what makes the player choices in games good, or that it works for every game out there. We’re still figuring this out ourselves, and there’s certainly a lot to learn yet. I bet that after we release Cinders, we’ll discover a whole world of issues that we haven’t even thought of yet.
Still, I thought it may be worth to share our list. Maybe you guys will find it helpful, or maybe you will have something to add.
Oct 13, 2011 by TeeGee
My life is slowly getting back into balance, and I finally got more time to write. It seems like the right time to revive the blog! Google Analytics also says it’s good for our traffic 
.
With such a long period of silence, I guess I owe you an honest update regarding our recent circumstances.
Cinders:
I bet that a lot of you just want to know how Cinders is going, and are we really working on it as hard as we can. Short answer: yes.
Basically, I’m not doing anything else at this point. Aside from the occasional session of Demon’s Souls in the evening, I spend my working days writing the remaining scene descriptions. A sort of “screenplay” for the game. With each scene, scenario and dialogue line listed and outlined. It looks like this:
These descriptions are then sent to Ayu, who uses them to write actual scene scripts used in-game.
I admit I underestimated the amount of time and effort that goes into writing a good an lengthy story, with multiple choices on top of that. It’s the main reason behind the delay, and I’m terribly sorry for that.
The good news is that I’m starting to realize that Cinders is going to be significantly larger than most indie visual novels. Not only in length, but also in the range of available options and possible outcomes caused by player’s actions. I try to make every single choice and event have some impact on the story. Even if it’s minor.
For example: trying to be nice to one of the stepsisters in the beginning may make her return a small but friendly gesture later on, and will be referenced in casual dialogues between the girls. On the other hand, if you manage to impress the stepmother with your actions (yes, it’s possible), one of the sisters may feel jealous, which is going to affect all further interactions with her. Some conversations can go in up to 20 different ways, depending on the little things you did in the past.
It takes time to write all that, but I’m really happy with the results. After all, visual novels don’t have much going for them in terms of gameplay other than the player choices. I want to make sure that we do that aspect really well.
Personal:
I think that our venture into indie gaming just entered its most stressful stage. I knew it would eventually come, but — well — it doesn’t make it any less stressing .
The game — as per the oldest game development tradition — is delayed. My bank account has almost dried out, and sales of Magi and Cinders pre-orders are unable to keep us afloat for much longer (by the way, many thanks for all the purchases guys; if not you, we would go under a long ago!). The pressure to finally release Cinders is very strong, but at the same time, compromising the quality of the game is out of question. On top of that, I’ve been ill for two weeks now, which certainly doesn’t help.
I also came to the painful realization that I brought too much responsibility and work upon myself. Coding, designing, writing, promotion, updating the website, running the forums, contacting the press and portals, maintaing schedules, giving support to customers, testing the game… I essentially ended up doing everything that’s not art, music or dialogue writing (to some extent). It’s just too many tasks for a single person when you are in a team, and I should be more adamant when it comes to sharing our workload.
Rob and Gracjana are long done with their work, and basically have to wait while I finish the game. It puts a lot of pressure on me, and it’s simply annoying for both sides, too. They have to wait for their money to start coming in, I feel like I’m a one-man studio again.
The original plan for MoaCube was to make it a sort of partnership between me and Gracjana. We make games together and then simply split the profits in half. I liked that — it’s a simple solution, and one that works for people who are also good friends in real life. Unfortunately, it’s clearly not working out as well as we hoped, and I’m not sure what to do about it yet.
Despite all that, I’m not complaining. Yes, indie game development is not all glamour, freedom and pantless Fridays (and groupies!). It has its dark sides. But this was to be expected, and I’m trying to keep a positive attitude.
I know that things are only going to get better from here. The game is close to release, I’m actually really proud of how it’s shaping up, and while we’ve made some mistakes, we are constantly learning from them. Further projects should go much smoother.
And you know what? I still love the lifestyle! Not having to get up early in the morning compensates most any hardships .
I also got involved in a cool game design workshops/jams initiative. Something I never had enough time for, when I was working in the office. It’s fantastic for getting those creative juices flowing and boosting your morale. I intend to write more about it soon, as the idea really deserves a full article.
Future Projects:
Having the artist and the musician idle, we also started thinking about our future projects.
We’ve had a wonderful brainstorming session with Gracjana and her partner (always bring a non-developer to your brainstorming sessions if you can — it does wonders!), and have outlined the design for our next game.
It’s going to be another story-heavy fairytale adaptation, albeit with more traditional gameplay element than Cinders. I think it should appeal both to VN fans and our Magi audience. Not much more I can say about it, other than that I’m very excited about it. Gracjana is working on some concept art right now, so maybe we will have something to show soon.
A game developer friend is also considering doing a visual novel for us with a very interesting premise and art style. It’s all still very uncertain at this point, but I really hope it will work out. I think his idea is great and I love his art. Here’s a nice preliminary concept art for one of the characters:
Like it?
So yeah — we’re working hard, Cinders is steadily progressing, and while we’re experiencing some hardships, I firmly believe the future ahead of us is bright. The weekly blog should be back from now on, too.
Cheers!
Aug 9, 2011 by TeeGee
So yeah, as you can see, I haven’t updated the blog since a few weeks now. And I probably won’t until Cinders‘ release, too.
The reason is as prosaic as it can get — simple lack of time. I used to write the blogs on Saturday mornings or Friday evenings, but it’s Summer now, and I prefer to take at least some advantage of the weekends whenever I can. And on the weekdays, I’m spending almost every waking minute working on the already delayed Cinders. If I would be up for writing something, it’d better be some in-game dialogue.
That said, I very much enjoyed writing the blog, and it felt great to see that it actually gets some readers. I look forward to getting back to it when everything calms down. I have some nice ideas for future articles, and I also plan a full Cinders post-mortem at some point. With sales numbers, production details, what went wrong/right and all that.
Sorry for the silence, and stay tuned.