[Cross posted from my blog over here: http://www.sampotasz.com/blog/clickreleasedesign/]

In the spirit of making a game in only 48 hours, I’m giving myself 30 whole minutes to write this postmortem. Make more things, deadlines spur action, yadda yadda yadda.

I’m really pleased with and proud of how my game turned out. There are a few things that I’d change if I had the chance to do it over again, but they are far outweighed in my mind by what actually went right! And in a game-jam-first for me, these positives are not just “Hey, I made something and it’s finished and you can play it w/out it crashing!” Artistically, I actually like what I made

So, before focusing too much on the product, I want to look a little bit at the process that got me there. As you may know, the theme for the competition was “Minimalism.” I was excited by this theme because it was abstract and didn’t seem too limiting. Immediately after the theme was announced I did some quick googling for inspiration. MoMa and this page had some good information and a few things stuck out for me. I loved the phrase, “the Minimalists attempted to avoid metaphorical associations, symbolism, and suggestions of spiritual transcendence.” To me, this had echoes of Eric Zimmerman’s “Let the games be games” mentality, and I liked that idea. I wanted to make a game that wasn’t about anything per se, but rather had the feel of minimalism.

To this end, I looked for minimalist art that I liked, and was immediately drawn to Donald Judd, Sol Lewitt, and Carl Andre. I looked and tried to pay attention to how I felt while looking at their pieces (Ed Note: Ugh. Too ushy gushy). I loved the way they drew me in – I wasn’t exactly sure what was going on and I wanted to explore them. I was a little confused, and definitely intrigued. I felt some hidden logic guiding the pieces, but was unsure about its exact rules.

To me, this was all great fodder for a game. I immediately had in my head some interactive piece that is somehow very exploratory. I wanted the user to not be quite sure what was going on when the game started but be drawn in to look further. I wanted a feeling of slight perplexity while playing.

My first idea was for the play to take place on a field of hidden “magnetic” forces. You would be able to see how they pushed and pulled you, but you would not be able to see them directly. The game would not present itself to you – you had to go out and find it. However, when built out, the invisibility turned out to be completely too obtuse for my liking. I made the fields somewhat visible and the game felt a million times better.

On the non-feelings side of things, I also wanted to mirror the repetition that I loved in a lot of the pieces. Variations on a theme. This is where the multiple rooms in the game come into play. Each one introduces a slightly different take on the basic click, release mechanic while still staying very much the same. Additionally, with each variation, I think it enhances the “what exactly is going on?” feeling that I was striving for.

I feel happy with how I captured the mood that I was going for. I think the exploratory aspect of the game works really well, and I’m extremely pleased to see that the game that it is having its desired effect on players. One commenter summed it up rather perfectly for me:

“I don’t really understand purpose, meaning and what you really wanted to express. Nonetheless, the experience was engaging.
I must confess I did not finish the game but I played it for quite a while. There were times I got myself just playing around with the sounds.
Cool!”

And now, I urge you to go experience it for yourself!

Silly question: when rating a game, it says:

If you can’t run this entry, please leave a comment saying so and explaining why. Do not score unrunnable entries.

So, if I cannot run a game, am I supposed to:

1. Leave the scores blank and explain why I could not run the game in the Comments (non-anonymous) box right under the ratings table
2. Or leave a comment in the Comments section at the bottom of the page?

There are 2 comments boxes in the same page and I don’t think the instructions are very clear…

I doubt people really care but since my video is related to my Ludum Dare entry, I’ll just post a link here.

So yeah, I recorded me playing my game “Jumper” which I coded in 7 hours and made a gameplay video. 😛 This is a newer version of my game where I added more levels, tweaked them and made somewhat better graphics but nothing in the code dramatically  changed.

You can also download my game from my website.

http://ghostid.net/games.php

If you want the older version *The Ludum Dare release*, you can get it from here

http://ghostid.net/news.php?post=4.php

Finally got around to compiling the timelapse for my compo entry Pyramid. Time spent watching the Dreamhack Open Starcraft action not included >_>

Tags: timelapse

Reviews of my game were mostly favorable, but everyone complained that the game was too hard. Jellycakes played it on his LiveStream and after 200 deaths couldn’t finish it (I can in about 10 though 😀 ).

In the comments, the main complaint was that the player doesn’t move while standing on moving platforms, so I decided to upload a post-compo version with this changed, and also eliminated the running button (it now runs by default), which should make the game much easier. Other than that, everything is the same.

If you haven’t played my game, it’s a top-down platformer centered about jumping and interaction with different blocks, here’s a video of it:

LD entry:  ahttp://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=22060

This is totally happening, 20th-27th May (that’s this month!) Go here if you’re interested! 😀

Follow @FishingJam if you want to be kept updated!

This was my first Ludum Dare, and I was thrilled to not only finish my game, but actually kind of like it a lot! First things first, big thanks to everyone involved in hosting and running LD, thanks to everyone reviewing games, and a big thanks and congratulations to everyone (all 2437 of you) who finished a game!

I Dream of a Beam ScreenShot

Minimal Design

I spent about three hours Friday night watching videos of other games. I had come up with several game ideas for most of the top themes from the early rounds of voting, but I distinctly remember thinking there was no way “minimalism” would win… Shows how much I know.  I ended up coming up with an idea for a simple shooter with no actual shooting; just a bunch of things that can be cleared with horizontal and vertical lines so that you can position yourself to maximize the number of things cleared with each shot while ‘minimizing’ the number of shots you need to take. I think this idea came through cleanly and it allowed me to finish the main player mechanics quickly and add more depth by adding different types of enemies. Finally, the theme let me save a lot of time on art by using solid colored rectangles for everything.

Audio – A Risk Rewarded

Things were going smoothly on Saturday, I had player movement, particle explosions, basic enemy types and some simple sounds all done. Then, after dinner, I had this mental conversation:

Idealist Me: “This game would be a lot better with dynamic music and sound effects that sync with the music!”

Realist Me: “I’ve never done that… How am I supposed to do that..”

Actual Me: “Oh well, no time to think about it, time to get it done!”

So, over the next 5 hours, I programmed an audio controller that counts the time to play sounds on beat, made some music on iNudge and recorded it track by track, had the controller randomly add and remove tracks during gameplay, then finally sent all audio effects through the controller to sync them with the music. I also got to bust out some math / music theory to figure out the frequency ratio  needed to scale the sound effects by 5ths for more dynamic sound.

Somehow, it all worked, and was really awesome. The music isn’t all that good, but it’s passable and syncing the effects with it is a great subtle effect. I have been getting a lot of positive feedback on the sound, and I think it really adds a great extra dimension to the game.

Finish Early, then Polish!

This was the approach I took to making the game. After the audio controller was finished late Saturday night (and I got some sleep), I had a basically playable game. I spent the early part of Sunday throwing in a scoring system, then adding as much polish as I could. First was XBox controller support. I think these types of game are better with a controller, and Slick has the option, so why not? Then I added a simple menu, controls screen, and credits screen. These don’t take that much time, but it makes the finished product look much better. Finally, when all of that was done, I worked on making the game more fun by adding more enemy types. I had horizontal, vertical, and diagonal movers, and, realistically, they should never kill you. So, I added the orange following enemies and added a little bit of random behavior in them so they wouldn’t just stack on top of each other. Then the light blue enemies… They were supposed to be sinusoidal, but they’re also at a random diagonal, so they are actually pretty hard to follow (for me at least). Finally, I added a system to spawn enemies at the end of every 4 musical measures (to sync with the music) and I was out of time!

Uh Oh

Room for Improvement

First, I had sketches for at least four additional types of enemies that did not make it into the game. Oh well.

I have also received some feedback about the player stopping movement while shooting. This was actually not a bug , but a conscious decision. Before I made that change, you could stay alive forever by constantly moving around and spamming shots. You can probably still do that, but this makes it a little harder at least, and I think it looks nicer.

Sometimes the enemies spawn on top of you. There, I said it. OK, well, I did write in a system to make them not spawn on you, but they can still spawn VERY close to you and moving in your direction, so that could be better. I had plans to have a spawning animation so that you can see where they’ll be and plan ahead, but I didn’t have time for that.

Right Tool for the Job?

The other major complaint that I have received is that sometimes the game doesn’t run! Which is bad!!! Particularly, it seems like it doesn’t work at all on OS/X and the applet does not work on Linux (the executable JAR works on Linux, though). I chose Java and Slick largely because I like the idea of code and compile once to get full cross platform support. I want to make it easy for people to play my games. However, something apparently went wrong with bundling and linking OS natives, and I haven’t been able to figure out the problem yet. (I haven’t tried all that hard, sorry).

So, I think I need to switch languages / engine. Right now the plan is javascript and html5. That way compatibility is up to the user and their browser. I am tentatively set on using melonJS, does anyone have other options I should consider?

Submission

Thanks for reading! You can play and rate “I Dream of a Beam” here:

http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=20933

Pink Haze is the minimalist third-person cover-based shooter I created for LD26.  This was my second Ludum Dare, and I feel I created a much better game this time around.

The goal was to do everything required for the genre (shoot things, hide behind cover to not get shot) and nothing more.  Your interactions are limited to moving around, firing your gun, and most importantly NOT moving or firing your gun.  When standing still your character automatically ducks, letting you hide behind cover and out of the enemies’ line of fire.  You’ll also recharge your health and ammo after standing still for a few seconds.  Aiming is handled automatically as well; you’ll always target the nearest enemy with direct line of sight.

The second room of Pink Haze, complete with navigation graph.

What Went Right

Being agile: The first part of this is to get the bare minimum game up and playing as soon as humanly possible.  In the case of Pink Haze I had movement, ducking, shooting, and very basic enemies done within a couple hours.  After actually playing my game, I reassessed what needed to be done and it wasn’t what I predicted it would be.

For example, my original plan didn’t have auto aiming but instead both you and the enemies shot straight ahead while moving around to aim.  This wasn’t much fun because it was extremely easy to avoid shots (why duck behind cover when no one can shoot you?) but extremely difficult to shoot anything (If you can hit them, you’re already in the line of fire).  Being able to play my game very early let me fix many of the troublesome spots I hadn’t thought of.  The reloading/healing mechanism, the status indicator on your back, and the character design all came from addressing problems as they came up rather than from initial design decisions.

Knowing my tools: I had a much easier time getting things done this time than I did during LD24.  This was due in large part to being more familiar with Unity.  It took me just a few minutes to add particle systems, sound effects, etc instead of spending hours trying to learn how to do it on the fly.  I also created a quick game for the Warmup Weekend, which made sure all of this was fresh in my mind.

Designing around my abilities: There are some aspects of game development that I’m very good at, and some that I’m just not.  Personally, I think I’m a very capable programmer, and I can do some simple 3d modelling, but I’m not terribly artistic in general.  From the very beginning I ruled out texturing/2d art, making my own musix/sfx, and having a story-driven game.  These kinds of guidelines kept me from trying to tackle something I’d have no chance of completing, and probably wouldn’t be happy with if I did.

Using content generators: SFXR and Autotracker are simply amazing!  As stated above, creating sound effects or music aren’t in my range of talents so these tools are the only reason my game has music and sound effects.

What Went Wrong

Creating the player character in Wings3D

Working harder instead of reassessing the situation: My original plan for the characters was blocky (Minecraft-like) humanoid characters instead of the floating ones that ended up in the game.  I spent over two hours failing at creating a run animation before giving up and designing something simpler.  In the end my replacement approach only to 30 minutes, and actually works better with the theme, but I still wasted a few precious hours struggling at a task that could easily be worked around.

Last minute additions: Up until an hour before the competition ended, the game had 6 rooms that randomly repeated until you died.  This was a bit repetitive, but entirely sufficient.  Instead of leaving things well enough alone, I decided to add a final room and an ‘ending’.  Unfortunately, after creating the final room I had no time to create an ending, and it simply fades back to the title screen.  The never-ending rooms would have been much better than such a crappy conclusion.

Not explaining things well enough: It was pretty clear from some of the comments I received that players weren’t always sure how to play the game, and the blame rests on how poorly I explained it.  The mechanics of my game aren’t as self-apparent and easy to understand as they seemed after working on it all weekend.  Standing still isn’t something you commonly do in shooters, so players were just running around instead of taking cover and not getting very far.  I added more descriptive instructions to the game’s entry page and haven’t heard complaints about it being confusing since.

Conculsions

Overall I’m extremely pleased with my Ludum Dare entry this year.  I accomplished almost everything I hoped to while designing it and I feel it was a huge improvement over my entry for LD24.

If you haven’t tried Pink Haze yet, you can do so right here.  Enjoy!

It is my first Ludum dare participation ! Really appreciate that !

Here the result in video. If you like it, please test and vote my game !

And for next time, if you have some advises … Feel free !

I was planning to use today to do a minimal (hoho) upgrade on my GUI from hell.

BUT

Without the deadline of the compo (Jam) I totally lost myself in distractions and feature creep. SO I don’t have a post-compo version yet, but a whole lot of ideas to make my GUI 200% better (from “What the hell?” to “What?”).

And to show you my time wasn’t totally wasted:

Before:

Now:

you could of course play my game, but you might as well  wait for the playable post-compo

I had this idea  after the LD26 …
“I ask myself if anyone did download the sources of the game to learn, mod it and have fun…”

So i came up with this, a proposition for all who want to join this Dare. A Ludum MOD Dare.

What is it?, simple.

After decided a theme for the Dare (and put a date), anyone who want to participate must.

1-Select a game with Sources published for the LAST LD (LD26).

2-Mod the game to match the new theme.

3- Post it! (and give credits to the original author to).

The Mod will be evaluated with this terms.
– Affinity to the new theme
– Closeness to the original game (more similar to the original, better)

Tags: Ludum Dare 26, mods

Just a small update to say thanks for all the awesome feedback so far. I’ve created a “post-compo” version of the game, for download here. It includes a number of fixes to small issues/annoyances with the original 48 hour compo version. I’ll be updating my entry page as well to include a post compo version. And in case you missed it, here is my desktop timelapse.

Thanks!

whilefun

These are my thoughts about the game I made for the Ludum Dare 26 compo.  I will focus on what I feel was the most successful aspect of the game and the two issues I feel were the weakest.

I wanted to develop something I felt was complete and I accomplished this.

I have been preoccupied lately with the idea of games as complete creative works.  To help me in this thought process I have been toying around with parallels between a painting composed of component parts and a game composed of component parts.

I wanted all of the component parts of my game to support each other so that the sum of the parts was something greater.  I am pretty happy with the end result.  I feel the game has a completeness to it.

There were a number of components I felt had to be addressed sufficiently to fulfill the goal.  Visuals, mechanics, audio, story, and dealing with the medium itself.

For visuals I wanted to integrate the idea of minimalism both on a surface level, in terms of how the game appeared and on a subtler level dealing with the theme and the method of delivery, i.e. the screen and boundaries of the game representing ideas and techniques from minimalist painting.  My dealing with the delivery of the game involved blurring the game border both in terms of visuals and mechanics.  I also tried to break the game area up in various ways to compliment the visual style as well as attempt to change the players perception of the game area.

As for audio this is one of my weakest areas.  I dedicated enough time to work on music and audio that it helped tremendously to have sound that felt intentional.  However, I think significant improvements to the audio can be done.

In terms of story and mechanics, I wanted to tell a story in a minimal way.  I decided to have the keys(letters) on the keyboard that were used for input, WASD, to also be the characters in the game.  I felt this helped complement the game as a whole and effectively deal with the issue of explaining to the player how to play.

In terms of the medium, I tried to resolve this in the visuals, story and mechanics.  I already touched upon this above.  I will just add that one of my main goals was to tell a narrative through interactivity.

What I would improve.

I failed to develop and implement the audio I wanted.

I wanted audio tracks that played in layers and were played at random times based on a weighting system.  Two things prevented this from happening.  One is that I did not come up with a sufficient way to implement this in the time I had.  The other is that I have little experience creating music.  I am still looking for a music creation program that suits me well.  With time and research I hope to resolve these issues.

I sacrificed controls for narrative.

The other improvement I feel is necessary is in the controls.

Infernal says …

Apr 29, 2013 @ 6:38am

The only problem I have is the little slide to stop that occurs when you stop input. In the tight spots between two bars, this can end in frustration as you try to park a letter to wait.

Otherwise, very artistic and clean!

I chose to have each character move to the head of the group when the character’s key was pushed.  This was intended to convey the story of a familial group, each leading when it was necessary.  In order to do this I created an invisible object in the world that was the “hub” for the group.  When characters moved it was relative to the hub.  The result of this was a slide when input stopped and characters moving at odd angles at times; when the input and obstacles almost all existed as right angles.  These issues caused frustrating deaths.

While I still want to marry movement and mechanics to story, I feel I dropped the ball a bit by sacrificing gameplay, and control, for story.  While I don’t believe the choice is always one way, player frustration based off poor implementation is something I always wish to avoid, as for example a narrative can be ruined by control issues taking the player out of the game.

Overall I am happy. Ludum Dare is a wonderful event.  Thanks to everyone who has given feedback on my game.  

Thanks for reading.  You can find my Ludum Dare game here:  http://supersoul.co/files/Projects/LD26/LD26.html

Sometimes online communities scare me. What are your feelings on the matter?

This entry was posted on Sunday, May 5th, 2013 at 8:55 pm and is filed under LD #26. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Hy everybody.

So here’s my first day and I’m trying to find my way…

Because I only have lot’s of ideas, but almost no programing skills, I would like to invite cool people who know more than I do, to have a fun week-end of brainstorming, getting in to the basics and maybe programing. Eventually we can make some progress and a little local LD…

The main idea is to prepare a successful project for the october event.

I can provide three computers, additional a netbook (forget this!), some space to stay overnight, FREE BEER and if we’re not too many people I’ll bake a pizza on saturday night or we can have a barbecue on sunday

There are two possible week-ends:

25/26 of May

01/02 of June

Please reply or tell me how to get in touch with you. There’s already one programmer who will join us.

This has been the fourth time I’ve attempted to participate in Ludum Dare, and it has produced the third LD compo/jam game I’ve released. Now, it’s time for me to talk about it:

What went right:

Actually finishing the game. I was so uncertain that I would finish this game, until the last few hours of the jam deadline.

Transitioning to a new platform. I made all my previous (mini) Ludum Dare games in either Flixel or FlashPunk, which are some really awesome frameworks focused on creating games in Flash, but I believe Flash is starting to become the new ‘Shockwave’, and will slowly be losing support from game developers, as the web, and HTML5, slowly evolves.

What went wrong:

Inexperience with melonJS. I was originally going to use craftyJS for my game, but, a week before this Ludum Dare started, I switched to melonJS, as I had some issued with Crafty (which I also had little experience with). This lead me into…

Nearly giving up. It was only within the last 4 hours of the jam deadline that I decided to take what I currently had, and attempt to turn it into what I consider a finished game.

Ugly code. Because of my inexperience with melonJS, I had a lot of really unoptimized code, and I took many shortcuts, just to get the game working.

What was dropped:

Falling / shooting spikes. I had planned to include falling spikes into the game, but due to my inexperience with melonJS, this was dropped, and dangers in the game were reduced to spikes.

Colour changing character. I originally planned to have the character’s sprite change to white once they entered a dark area. I dropped this, due to the problems I had with inexperience with the engine I was working with.

Checkpoints. Many comments on my game’s page complain about the loss of their powerups once they make a tiny mistake. I had originally considered checkpoints, but they were dropped from the game, as I has no time left to implement them.

I am currently working on a post-compo version of Stykk, and I have cleaned up the code a lot, and I am also going to make it so you don’t lose your powerups on death, making it less frustrating. (I will also include the original behavior as a ‘rage mode’)  

Watch my entry page for updates!

So I made a game. I think it’s pretty good. Definitely the best game I’ve made solo. I wanted to not just finish, but to created something very polished. For the most part, I think I succeeded.

Play it now!

Friday I discover the core mechanic of my game. Saturday I perfected the core mechanic. Sunday was for polishing and play testing.

V1 was a physics puzzle game where the moving pieces would paint on the background. I didn’t really like the aesthetics and it sucked, so I scrapped it.

For V2, I wondered if exploring the world of Mondrain would be interesting, so I quickly hacked up a random maze generator:

I tweaked it a bit so that instead of generating a static square, the world would be created as the user moved through it.

What went right

• Unity3D. It’s so easy. Minima is only about 1700 lines of code. I got to spend a lot of time tweaking game play instead of fighting with complex code. Also I can target Windows, Mac, and Linux platforms for free! I even built it on iOS fairly easily.
• The theme. I can’t draw. The theme let me stick with boxes and make them interesting.
• Pentatonic scale. I can’t compose music. Procedural music from walking around worked out great. Next time I would like to experiment with other scales or fifths.
• Playtesting. I got some great initial feedback Sunday morning and was able to tweak it.
• Talking blue cube. I was under about making the cube talk. Making it not talk seemed to fit the theme better, but making it talk increases player motivation. Everyone really hates Blue, so I think leaving it talking was the best call.

What sucked

• The ending. I underestimated how much people need to know when to stop playing. I thought the ending was clever, but it’s only clever if you’re me.
• Analytics. I really wish I had put analytics in the game so I could know how far people go. Next time it will be a core feature.
• Unity 3D. It’s great, but I got reports of failures on the web build. I had no way of debugging it. Eventually I figured out what the problem was when I ported it to iOS.
• Web hosting. I started the weekend with www.screaminggoose.com being broken. I’m all fixed, but next time I’ll have my web hosting fixed up before hand.

So, it was awesome. Thank you everyone that played my game!

Tags: postmortem

A couple of my thoughts about my first participation of LD:

Don’t Take the Theme Too Seriously

I think I tried to interpret the theme a bit too literary. I thought the game has to be *about* minimalism, which means that minimalism is not about its styles, but the *goal* of the game. What’s the problem with that? It turned out to be difficult to come up with a game design that is about minimalism but still enjoyable. I thought minimalism always involves some sort of design or structural construction, which is a creative act, so the obvious choice for me is to make some kind of puzzle game. But I didn’t want to make a puzzle game! I wanted to make an action game. So this put me into a dilemma. I spent one hour for brainstorming the basic idea in the beginning, but even after that, I wasn’t really sure what I’m going to do.

The first idea that came to me was a trash compactor. Its goal is to minimize the volume of garbage, and it can be a game. But it didn’t much sound like minimalism, so I came up another idea, which is to design a minimalistic house under some condition (think of an artsy house that modern architects design). I was thinking of something like “Art Game” by Pippin Barr. You push materials around and then “play” on it. And then at some point, the materials turned into food, and some crazy insight told me that I should make a platformer on the top of it. Hence the idea of my game “Controlled Diet” has come into reality.

You cannot Learn Your Tools Enough

I used a combination of Windows + Linux environment (I run Arch Linux on VirtualBox on Windows). I edit and compile on a Linux machine and test it on a Windows machine. I used a vanilla Flex SDK 4.6 and Makefile (Yes, I am very old school). I used a shell and Python interpreter, as well as a set of well-known tools (e.g. ImageMagick). Here are things that I think would be useful if anyone uses a similar environment like mine:

• Get used to Emacs’ Actionscript-mode. There are several versions of it by different authors, and they vary slightly in its highlighting and indentation. Using a wrong one will end up a lot of annoyance.
• Use a debug version of standalone Flash Player, so that you can double-click the build and run it directly.
• Don’t forget to add -debug=true compiler option to mxmlc, otherwise trace() wouldn’t work!
• Use fdb (Flash command line debugger) to siphon trace() outputs to a stdout/file.
• git config --global core.filemode false
• If your machine is slow to launch Java, try using fcsh (Flash compiler shell), which somewhat reduces the startup time of mxmlc (but not by a large margin).

The bottom line is that the more efficient the edit-build-test-debug cycle, the better. Try to spot the bottlenecks as many as possible and eliminate them.

IRC is Helpful

I had been lurking around the Ludum Dare IRC channel for a couple of weeks, and I can tell that this is a very nice place to hang out. You see a lot of people talking about their ideas. At one point I was murmuring about the need of creating a quad-tree implementation that was necessary for my simplistic physics engine. Then someone in the chat said “a quadtree is overkill for this”, and he was right; I didn’t really need a quadtree for only a dozen of objects. Now I want to thank that person. You saved me a lot of time.

Things that Went Okay

• Overall framework. I wrote a generic framework and posted it on github beforehand. This strategy went well. I can start quickly tweaking on a working codebase, and it was simple enough to allow me to change it drastically later on.
• Time management. I put a TODO list on my desktop and tried to update it at every hour. Later I had to reorder things but this helped me greatly to stay focused on what I’m going to do.
• autotracker.py. This is an awesome tool, even more so when you know a bit of Python and how to tweak it. Thanks a lot.

Believe in Your Idea, with Passion

Generally, I think I’m more of an “idea” guy. I wanted to come up with a wacky, eccentric idea and somehow I succeeded in it. I finished my game, and even its not the most fun thing to play, I still enjoyed the whole process a lot. It was a nice challenge, and hope I can do this next time again.

Tags: postmortem

[Cross-posted from Omiya Games blog]

Here’s a dump of all the design decisions I’ve made on The Sentient Cube.

First, the debug level. Always gotta have one for Unity. It’s a great place to create prefabs, and tweak the numbers to apply to the rest of the levels. Also a great place to test stuff, like the water block (top-left), unattainable block (top), bouncy block (top-right, unused in game), ice block (not shown), and rocket boosters (red, left).

How to Play was a nasty one. The first curve is there to give a clear and empty view for the player to practice the controls. It also puts the Goal out of view, making it easier for me to teach the basic objective of the game: collect smaller objects. The first bend is where I scatter the smallest objects, and provide the instructions to roll into them. I’ve put a lot of objects there to show them lighting up as you get bigger.

Proceeding forward, I have this weird bend that stretched all the way to the left. The straight-way itself is intended to let the player practice collecting bigger objects, in a true breadcrumb fashion. It’s also here that I mention the arrow at the top of the screen, that it indicates where the goal is (straight ahead). It’s worth mentioning that I call this bend “weird” because it was also intended to hide a problem: Unity’s default GUI shader draws over all other objects. By placing it to the far-left, the player wouldn’t see the text at the beginning of the level. The shader that corrects this weird overlap is openly available online, but to respect Compo rules, I didn’t copy this shader; I merely hid it.

Level 1 was actually the second level I created, code-named “pyramid.”  This level simply acts like a practice level, where the goal was clearly above you, and the objective was simple get large enough to be able to climb up the steps.  The bouncing spheres was a small challenge I’ve added to make things a little more interesting, i.e. you have to time it correctly to obtain each sphere.  Past that, it’s a pretty generic Katamari level.

In Level 2, I wanted to establish that the Goal could be anywhere.  In this level’s case, directly below you!  This was actually the first level I created, and you can tell from the knocked over objects I really just zoomed through this.  It was the first place, though, where I got a good handle on the amphitheater formation.

In Level 3, I introduce the rockets!  I initially intended the rockets to help you fly upwards, but that was nearly impossible to do with the given control scheme.  Instead, I found it useful to traverse great distances due to its added speed, and decided to do a level designed to demonstrate just that.  To acknowledge that players may simply wants to play around with the rockets, I placed slopes around the Goal to make it easier for them to reach it.

In Level 4, I introduce the water block and the ice block rather haphazardly.  This was the last level I created, and I simply had very little time left, so I dumped every new assets I had into it.  The walls surrounding the ice is there to prevent both you and the objects you’re trying to stick from falling out, making it easier to collect things.  The objects are placed almost randomly, partly because of the chaotic nature of the ice-block.  The water blocks were intended for helping you adjust your controls, but in the end, they ended up being pretty useless.

And the Credits. This was actually hard to design, mainly due to tweaking the size of the breadcrumbs so you can definitely grab each text. Other than that, it’s intentionally a breadcrumb-to-breadcrumb level with no other purpose than, well, providing the credits.

Interested? Try The Sentient Cube here, and please rate the game!

Tags: design, game design, level, level design, The Sentient Cube

About a week has passed already, so I decided to polish up a little my LD26 entry, following the feedback I received in the comments:

• Made movement smoother.
• Fixed dumb crash when clicking the mouse outside of a fight.
• Added WASD movement.

I’m also making the instructions a little more detailed, but it’s hard to it without spoling the game. It’s a game for players who like to explore and experiment

So, my current ToDo list:

• Fix character progression.
• Give proper feedback during fights.
• Fix sound bug (no idea, using a third party lib).

I’d like to get the game a little more polished before abandoning it 😛