Posts Tagged ‘as3’
Came in to work this morning to see that our LD27 game had 1000+ gameplays on Kongregate. Turns out it’s featured on the front page of the site in the “Trending” and “Hot New Games” sections!
We really want to tweak some things and add weapons, levels and music to the game for the post-jam version, so hopefully this is the start of something cool.
Thanks to everyone who played it!
I always wanted to create video games, I did some tests, but aside from one game, 2 years ago, (http://www.kongregate.com/games/tet2brick/lost-colony/ if you want to test it) none was finished or published.
LD was a good opportunity to have a deadline … and it worked!
I’m pretty happy with the end result, it could be improved, but for a developed 48 I think it’s pretty cool.
What I’m happy about
- The design in general and in particular that of the character … I’ve never done pixel art before a few weeks ago, so it’s not too bad.
- The gameplay is functional, I think the difficulty is well balanced and evolutive.
- The game is fun (I enjoyed playing it myself… :p )
- The music is ok and was done in less than two minutes, that was a last minute addition.
What I intend to improve in the next version
- A prettier start screen
- More levels
- More ambient sound
- More scenery
- More graphic details (tree, plants, rocks, tombstones, etc..)
- More different traps?
- More levels
- Mooooore levels
- A better title.
Well, that was a really interesting experience that helped me realize that I could develop full games more often.
Feel free to test and give me feedback!
That’s it! I consider it to be one of my best Ludum Dare games ever
As always, I managed to somehow wake up naturally at 3:58 AM (2 minutes before the theme announcement) , saw the theme and then returned to sleep. I streamed the whole gamedev process and it was actually really fun, almost always there was someone on the stream chat and it was nice talking with you guys, thanks! When I first woke up in the morning I started writing down ideas and later I decided to continue with the first (and quite simple) game idea, actually, it turned out to be a good decision!
My main goal was to make the game as polished as I can and I think that I accomplished that goal very well. All in all, I had a lot of fun making this game, I had a lot of encouragement from my friends (which really helped me ) and I even had time to take a few naps during the jam!
The Cave Of Light
Join our little friend on his journey into the depths of The Cave of Lights.
Wisely spend your 10 seconds of light each level to find your way through the cave…
What will you find at the end?
Play and rate “The Cave Of Lights” here:
First, this was an awesome experience. That was an intense 48 hours. I’m so glad I did this and actually finished the game I wanted. I’ve seen quite a few of these post-mortems here on LD so I decided I should end this experience with my own.
Just a heads up, I go into spoiler territory below so if you have any desire to play this game, do yourself a favor and click the link below. Play it first and come back here after. Don’t ruin it for yourself! I’ll wait. I promise.
——–STORY SPOILERS BELOW!!!!——–
So without further ado, Captain Robert’s POST MORTEM.
- The story (3/4 of it anyways). I made a story that I liked to watch and read. Parts The Thing (80′s version, people), parts Lovecraft, parts every other sci-fi movie I grew up loving, this game was a kind of love-child to all those great movies and books. I put a large portion of my time into making these characters and their reactions somewhat grounded. I think it turned into a solid (if unoriginal) tense sci-fi mystery. I guess I was banking on a decent story overcoming some the other shortfalls of the game. The end product’s tense atmosphere, the story unraveling before the player, and Julie’s tragic story are my proudest moments.
- The gameplay. I’ll be the first to admit that old metroid games were a huge factor in developing this game. It didn’t start out that way. I started with making a general list of gameplay elements I could develop within 48 hours and it wasn’t much. AS3 and Flixel are still a pretty big mystery to me (More on that below) so I had to carefully choose what I could develop well. It just so happens that the majority of the exploration elements of a metroid game were things I thought I could pull off well.
- DAME. This tile editor is amazing. Without a doubt, the final ship would not be what it is if it weren’t for how easy it is to pick up DAME and incorporate it into a Flixel project. Any compliments to my jumping and collision detect? All the handy work of the boys behind DAME and Flixel.
- Captain Robert. Not quite him but his sprite (or lack thereof). This was one of those things I meant to get to, after I finally got the core game and story down. The core game and story were completed less than 2 hours before the deadline and I had to pick and choose what was going to make it into the game. In the end, I decided that my best programmer art for Robert (Let alone what I could produce well in such time constraints) wouldn’t do him justice and just distract the player from everything else on the screen. So, a solid white rectangle for you, Robert. (Besides, Thomas Was Alone pulled it off pretty well IMO).
- No radar or map. Sorry guys. You’re just going to have to slug it out, old school style, with no sense of direction. If I had the time, the player would have at least a static map of the ship. On a similar note, I wish I could have added a better indicator of what keys the player had and what doors he had access to at any given moment. This general confusion only hurts the pacing setup in the game.
- The theme. Put this inside the ‘not enough time’ bin. Originally there was a lot of dialogue explaining why 10 seconds would mean the world to our Robert. How the potential to not be yourself and the thoughts that follow that can define or redefine someone. What makes a person and how the creature kind of ruins that. Instead of refining these cool concepts into the game, I was cramming all I could to make the story being told coherent and fun. Given the time, I would follow up on this portion with an expanded final quarter of the story.
- The music and sound. The music was added in within the last hour of the dare. I thought it connected the world together and still think when the music stops, your palms get a tiny bit more moist, but the fact is that it was largely untested and was almost cut from the game after I couldn’t fiddle with it enough to get it working properly. What stands is a buggy music system that plays when it’s not supposed to and vice-versa. Simple things like footsteps for Robert and the banging coming from the storage room would add volumes to the game but with time being a premium here, all sounds that made it into the game were luxuries that I’m happy worked out.
- The code. I’m so sorry for that poor excuse for structure in my source files. You may need bleach for your eyes after looking at my code. Mega-blobs and unused code lurks in every corner there, rivaling my own game’s horror elements. The worse part about it was that I thought this would be a learning experience with AS3 and Flixel. I only dived into developing with Flixel and AS3 earlier this week. After learning a portion of the fundamentals, I completely shifted gears and jumped into making the game with that limited knowledge and fudging my way along. The only redeeming factor is a cautionary tale. NEVER MAKE CODE LIKE THIS AGAIN (until the next dare that is!).
- Of course. That ending. Two things went wrong here that I can see:
- First I saw that some people were confused to whether it was supposed to end there or whether there was another key on board the ship. The escape pod key was a dropped concept that I left in the game as a sort of red herring (that it was the ‘right thing to do’). No one would actually look for it because everyone would want to see what’s inside the storage room, right? Well. People actually looked for it. Sorry about that. It should be clearer now.
- The other issue with the ending was that it’s incomplete. All the dialogue I intended for the game is in there but a followup of that door opening and a little closure after that would have made sure that it was unambiguous what I intended as ambiguous and leave a slightly different shock to the player.
I was going to end this thing with a list of features I ran out of time with but now that I’m seeing some of the response the game has had with some people, I’m thinking of putting out a ‘Director’s Cut’ of some sorts that clears up the timeline, fleshes out the story, adds more background, adds the missing compartments, adds an item or two, maybe even adds the intended ending(!). Who knows? Robert may actually end up with a sprite after all.
I think I’ve gone on long enough. Let me know if there’s any desire to see more of Robert in the comments. Lastly, thanks to everyone for playing. I’m loving the theories so far. You guys and your responses totally made it worth stressing out, losing sleep, giving up, restarting, giving up again, cursing myself out, then finally making that mad dash towards the finish line. Sincerely, thank you. If you have any questions about the making of the game, please ask away! Otherwise, see you in the next dare!
My first LD, I’m happy with how things are going so far but I am afraid that I’ve planned too much.
Yes, I’m in too! (so plug your noses:)
This will be my third attempt!
I’ll be using Flash and pure Actionscript 3 – no frameworks and other’s libs.
As usual I’ll give you advantage as I am starting with sleep again not before I see the theme (at 4 am : )
There is something special to think about theme and game concept while falling asleep – You wake up early in the morning before the alarm and you can’t wait to throw some pencil trails
Well, I’ll gona do this. Just prepared this soundFX tool – from my previous experience there is never enough time for integrating sounds.. It’s a singleton class that handles both sound effects and music loop.
Well, this is the first Ludum dare I will take.
I will use this short of tools:
Language: AS3 (so people can play the game on the web).
Libraries: Spiller for AS3 (A port and improvement on Flixel AS3)
IDE: I will be using MAC and OS X so Flash Builder.
Music and Sound: For audio I will use bfxr and maybe Audacity.
I hope I can at least achieve something playable :).
I released the spiller-as3 to the public so anyone could use it in case they needed it:
Good Luck to every one!!
Above I’ve created a basic pool manager for AS3 for using object pooling and keeping it efficient! Hope this is useful to some for next weekend.
What is object pooling?
Wikipedia describes the object pool parttern as:
The object pool pattern is a software creational design pattern that uses a set of initialized objects kept ready to use, rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object, which is a specific type of factory object, to the pool rather than destroying it.
My game is a minimalistic puzzle game where we tell a history of a little boy called Ted, trying to make a better world around him with the imagination.
We receive in our page great reviews, and the most good thing is the surprise of the game be so polished. It’s because we fix in the idea that the game have to be something minimalistic at all, not only in the graphics, but also in the gameplay, and even in the story.
During the compo, I ran into a bug that made two pushable box (which should collide and stop) run over each other. I’ve been trying to fix that, but now nothing makes sense anymore… The gif bellow can better show it (and also show a new stage! :)).
As you can see, the first time it collides perfectly… but the second time (which should be the exact same situation), they overlap each other… One thing that I was able to notice (after dumping some frame-by-frame information to a .txt file… >_<) is that there may be a relation with their order in the object list (FlxGroup, if you’ve ever used Flixel).
Ok, this gave me a (stupid) idea. I’ll check which is the left most one and pass that as the second object to the collision method (FlxObject.separate). I’ll post soon with results. Obviously, it didn’t work. ¬¬
Now that the weekend is over it is Post-mortem time.
TL;DR: I managed to create a fun game by taking a well known game mechanic and adding a twist to it. Unfortunately, the lack of proper feedback put a steep entry barrier into it.
On Saturday noon, when I learned about the theme, I wasn’t sure that I would participate at all. I had been brainstorming some ideas for the themes in the final voting list, but didn’t pay too much attention to Minimalism because I wasn’t particularly interested. It occurred to me that it could be an excuse to be lazy, and there was the risk of having most games resemble each other (…well, I’m happy to say that in general the compo entries I’ve checked so far have proven me wrong; it’s amazing how many different ideas can stem from a simple theme). Of course, Murphy’s law stroke back and that happened to be the final choice.
The first ideas that came to my mind consisted on just picking one of the concepts from the day before and reduce graphics to its bare minimum (yup, I’m lazy). However, after thinking that most people might follow that approach, I started thinking about what minimalism really means: to remove everything non-essential until you end up with the core of a particular piece of work. In games this can be achieved in different areas, either by themselves or as a combination: graphics, sound, narrative and, of course, gameplay.
In many current games the main concept hides behind layers and layers of superfluous functionality: stunning visuals and excessive feedback, over the top GUIs, tutorials, meta-game features,… Sometimes they do enhance the experience, but in some cases they can also obscure a set of mechanics that already work perfectly well by themselves. So I decided that for my entry I would pick some well known gameplay mechanics, bloat it with unnecessary stuff, and then strip them from the game as the player progresses until you got to the “essence” of the game. At first I thought about the classics: Tetris, Pacman, Puyo Puyo, Match-3 games,… possibilities were infinite. However, I figured that I could at least try to add a twist to them, or imagine a new game concept that fit the theme by itself and at the same time was fun to play. This way, even though I wasn’t able to implement the “non-minimal” feature set I would have a decent entry.
I ran some searches to find some inspiration and then I ran into this image:
When I saw it, I felt that familiar “click” of inspiration, and the match-3 with ring rotation as one of the possible movements just came naturally. Gameplay was certainly minimalistic, and so was the art style.
For the sound I thought of Simon, so there we go…now we have minimalistic audio, too…
And you can check the final result here.
What went right
I know I’m not the one to judge, but people seem to really enjoy the game from what I get from the entry’s comments (Thank you all!) and from friends who have tried it, and I think this is the most important thing, besides being really encouraging. When I was coding, sometimes I’d run the game to test some new feature or reproduce some bug and then would find myself playing it longer than necessary, which was a promising symptom. Still, I wasn’t sure if people would like it or if they’d find it too casual, or boring. It seems they do enjoy it =)
Start small and modular
This makes planning and prioritization easier. Given the Ludum Dare’s tight time constraints, this is fundamental, and it’s much easier said than done. For this edition I managed to “split” the concept into two: the basic game, and then the “start excessive, then simplify” idea, which didn’t make it. At times I resent it a bit that I had to drop the latter: I liked it as a means of criticism of certain tendencies on games today (I may sound a bit snobbish here, sorry :S), but if I had decided to go with both at the same time I probably would have failed at both.
Not too many bugs
This can be a secondary effect of the game being simple enough, but the match and possible movements calculation logic relies on lots of array checks, leaving the door open to “off by one” errors that can show up in the game with unpredictable results. I’m aware that there is at least one of such (or it may be due to the logic in charge of the blocks state transitions after a match), but it is quite infrequent. In general, people have not complained about bugs, so I’m quite happy with that (of course, those bugs have an arrest warrant on them, so I’ll try to fix them)
This would have applied to the “What went right” of my entry for LD25, Conquer All The Castles!, if I had written the post-mortem for it (procrastination, the root of all evil), but as that was not the case, I’ll state that here. The game was coded in AS3, which despite not being my cup of tea had two advantages compared to C++, which I had previously used for It’s evolution, Baby!, my first LD game: the first advantage was that it was easier to get things done and display them on a screen. On C++ I generally use SDL and OpenGL, but I don’t use any higher level graphics library (and I haven’t coded any of my own yet), which means I have to spend lots of time in graphics programming rather than gameplay.
The second advantage is that you may distribute it easily via web. No zip downloads, no installers, no platform issues (generally), no dependencies and no annoying external redistributable packages required (We could argue about using GCC, or maybe even developing on Windows vs Linux, I know). This grants you a lot more visibility, as the game is more accessible and people can play it immediately.
Easy to evolve:
The idea is really simple, and there are lots of opportunities to expand on it (although this means that we’re straying from minimalism )You can always improve the visuals, of course, and add some eye candy, but music and sounds, and evolve the gameplay in lots of ways (for example, allowing horizontal swaps, adding a special ability to “sacrifice” a ring, further victory conditions, etc, etc)
What went wrong
People have a hard time figuring out what to do
The fact that I needed to add an external tutorial for a game with only two movement types speaks ill about the feedback the game visuals provide, or maybe even the controls. I’m against in-game tutorials as a general rule (and in this case in particular, I felt that it went against the theme), so I decided not to add one. This is OK, but if you choose to do this then you must count on the game itself teaching the player to play it, either with sound, animations, intuitive controls or any other type of means. I made the fatal mistake of assuming that it was easy enough as it was, and anyone would get it instantly, or after a short period of trial and error. That assumption is indirectly taking for granted lots of things: that everyone is equally familiar with the “match-3″ mechanics and that all those games are played the same way (for example, clicking on blocks vs dragging), that the way people perceive the game is always the same, which is not true, etcetera.
Lack of play test.
The above mentioned problem could have been solved easily if I just had some more people play the game while I was developing it. It’s actually interesting seeing people play by themselves, as you can see where and why they get lost, and you can spot pitfalls that have slipped unnoticed. After seeing some people play I discovered how much the spatial perception of the scene differed from one person to the other. Some people would see the square as a 3D box, while others saw it as concentric plates.
This actually affects the way they think the game is played, and raises an interesting question: could people be less confused if for the starting levels I had used circles or polygons with a larger number of vertices instead of squares?
Despite I’ve already talked about this in the “What went right” section, I must also drop a few lines about it here. Following with the theme’s motto, “less is more”, so it’s better to have the main, most important features well implemented and possibly leave out some minor details, no matter how simple they are. For example, the time spent for the random tips at the top of the screen or the addition of the “timeless” mode could have been used polishing the controls, testing if the level progression made sense,…Yes, they’re simple and they may not take more than a few minutes, but if you keep adding things up you end up deviating from the main goals.
This is related to the previous point. Of course you don’t want to throw down work you’ve done. At times, though, you must stop and rethink if it’s really sensible to add that here or there, or if it just detracts from the experience. Again, I must use the “Timeless mode”.
Lack of polish.
Besides the visuals, sound, etc, balancing comes into play here. I haven’t been able to move past the fifth level (a square with a larger number of rings) so far, and I’m not sure if someone’s managed to do that, or whether it’s actually possible at all. In the end it all adds up, so as I mentioned in the “Playtest” section, perhaps having a proper progression where you decide that a level with (X vertices, Y rings, Z matches to complete and T seconds) makes more sense if played before another one with, say, (X + 3 , Y, Z + 2, T – 10) could help people have less trouble to understand the mechanics.
External side effects
As a result of spending two days in front of a laptop screen, my neck has resented to the point that I still feel as if I had needles piercing through it due to muscular strain. This is a combination of my terrible postural habits and the long work hours without any kind of rest. To top it all, I lost several hours of sleep. At that moment it’s not important, but then you go to work like a zombie and have problems focusing.
Despite the obvious mistakes (Or perhaps even thanks to them, to some extent), I’m quite happy with the end result, to the point that I’m considering to keep working on it, and even maybe a mobile/tablet port.
These would be the next steps:
- Rotation animation. This is a MUST, as it would probably make the game A LOT more intuitive.
- Bug fixing.
- Better match animation/visuals, specially for chains.
- Improve overall feedback.
- Experiment with controls. Maybe dragging might do miracles for rotations, and probably for swaps as well. In the best case, give the player the ability to choose the input scheme that works best for her.
- Add game states, maybe game modes (for example: challenges with fixed levels, convert the “timeless toggle” into a game mode,…)
- Better sounds, better graphics, perhaps even music.
And this is it, I think that I’ve bored you enough already. Thanks to everyone who’s bothered to read all this wall of text, and specially, thanks to everyone who has played the game and given me suggestions on how to improve it. I hope you enjoyed it and I hope that I can keep the motivation to work on it and make it much better.
So I didn’t even know I was going to be able to participate in this Ludum Dare because of other things going on, but I knew I’d be travelling all day on Sunday and I happened to get an idea for a very small game on Saturday night.
My entry was created over the course of 8 hours and involved traveling through four states, on three different types of trains and one bus!
I am so glad the theme was one which supported a heavily constrained timeline.
Use the left and right arrow keys to avoid the blocks!
You can play Squeezed Out in your web browser and it has online leaderboards if you’re into competition with other players.