Posts Tagged ‘as3’
Hello. I didn’t make a post about my LD game yet, so here it is.
I would have liked to put in more levels, music, blah blah, but overall I think it turned out pretty good. Give it a try.
Well I made it through my first LD with Monochrome as my entry!
It was tiring, and frustrating on occasion, but mainly it was pretty fun and I can’t wait to give it another try!
I just wish I had learned more before starting, because I lost a lot of time learning to do some stuff for the first time, and it made me waste time on silly mistakes and work slower overall. I couldn’t do as much as I wanted, but oh well, I definitely learned a lot (although I left my code real messy :x).
In Monochrome You Only Get One color at a time. The one-colored world you see is the world you are in, but periodically the channel changes and you have to deal with another one-colored world, so be sure to move in time to arrive at an adequate position in the following color (or you may even end up stuck in walls until the world changes)! I hope you enjoy this little platformer!
game title: Wifes
almost finished implementing game engine. Player and women interact as they have to. Still working on bad guys :). No another screenshot , because all day I was working on deep engine stuff, preparing all framework from scratch.
Some more info: your target will be to reach point goal as fast as possible by marrying and divorcing with women. There will some challenges , like enemies – random guys from nowhere – who can take your place by marrying another women and not letting you to get enough points to win. Also there will be enemies-guys , who will be able to steal your wife and as you know – you only get one wife at the time :). Tomorrow top priorities: to finish bad guy class and start working on graphics and sound.
Good luck everyone.
The game idea I decided to go with is that you’re the only crew member of a ramshackle submarine. You have to dash between posts to prevent the thing from sinking. So far, it gradually fills with water, and you can operate the bilge pump to drain it. This probably makes it the only Ludum Dare game with an operatable bilge pump.
I mostly just like saying bilge pump.
I decided to make a LD48 game too! It’s about trying to dock a spaceship into a fuel station with realistic Box2D physics for extra QWOP-iness. You have one tiny fuel tank and limited electric charge. The realistic physics make it hard to simply move and dock, but you still need to dock to the station before you run out of electric charge or fuel.
The fuel station and fuel/charge gauges aren’t implemented yet, but you can fly the spacecraft with WASD.
Here’s a screenshot:
Here is a playable demo: link
I used Blender3D for the graphics, Box2D for the physics, and Flixel as a game engine.
Happy coding everyone!
I’m in again for the LD 28 Jam. This is my second Ludum Dare and I’m excited to be taking part again! Hoping to actually get something finished that is in a workable state.
I’ll be using ActionScript with Flixel. Adobe Suite, including Flash Builder. Possibly Logic for music.
Changed from the Compo to the Jam to give myself more time and the possibility of working with someone else. Looking for a pixel artist.
Hijack Humans Hastily was my compo entry for Ludum Dare #27 under the theme “10 seconds”. It was a game developed in pure ActionScript 3 (using Adobe AIR), with the OUYA as its main target but with a web version available (given the platform). Here’s a short gameplay video:
Here’s the mandatory post-mortem, with a few development snapshots scattered around the article.
What went right
Reusing stuff I already knew about
In my previous Ludum Dare entries, I’ve rarely re-used many systems. I like to build my own stuff. In fact, so far I’ve refused to use full-fledged engines, and while I’ve used Unity previously, it was mostly an excuse to force myself to get acquainted with it.
This time around, I had decided ahead of time that I would be using AS3 and a couple of frameworks for certain features (Nape for physics, Starling for GPU graphics). I had no engine, per se, but I complemented those by developing several additional libraries for game controller input, game looping, and physics level data loading (most of which are open-source and posted on my blog). I was certain I’d spend more time working on a game, rather than working on systems for a game (which, as fun as it is in itself, doesn’t make a good Ludum Dare entry).
The strategy worked pretty well. While I still had to use a pretty amount of time getting basic stuff working (due to my lack of knowledge of some Nape features, for example), I felt I was actually building a game earlier than on my previous entries.
Art was straightforward
I loved doing the art for the game, even though I hadn’t been drawing in a while. While a bit was dropped and unused (specially background art), I think the simple aesthetic I reached was pretty flawless even if it wasn’t brilliant.
What went wrong
Getting a game idea is always the hardest part for me, specially under pressure. I spent the whole first semi-day of the compo (Friday) doing nothing other than dicking around online, or reading, just because I couldn’t figure out an idea. The idea Saturday morning – of a flying UFO capturing humans – was a mechanic I’ve been thinking of for a while, but to be honest I didn’t have the gameplay challenge or the relation to theme figured out for a while.
Features were dropped (surprise)
While I tried having a smaller scope, some features were dropped out of the game. There’s only one level, for example, and while it’s randomized and it’s all based in easily configurable parameters (size, assets, etc), I never had the time to add actual level progression and assets for more levels. The current level used (city-ish) is a mix of my two initial levels ideas, park and city.
Worst of all, I couldn’t even begin to implement the enemy A.I. In the best Choplifter fashion, the second level of the games was supposed to game enemy tanks that would shoot at you. They would not do any damage, but their projectiles would throw you out of balance and make control a bit more difficult.
Not enough time for bug testing/QA
While I didn’t run into any huge problem, my entry still had some issues I had no time to test. Those include some bugs related to web playback (losing 3D context when switching between fullscreen, for example), and some OUYA pitfalls I wasn’t aware of (having the game suspended by the system puts it in an unplayable state when restored). Those are things that are likely easily fixable, but were noticed too late.
I think this was probably my most well-rounded Ludum Dare entry so far. I’m pretty happy with how it turned out, and I spent plenty of time watching my own time-lapse video of the development process. It’s great seeing it slowly transform before your eyes.
Still, the relative smoothness of this Ludum Dare made me realize something. Ludum Dare is a lot more about the content, and I’m not sure I’m very happy with it.
Because of the limited time, it’s better to have a great idea, create a lot of content and gameplay, and test it out until you have something fun. Some of the compo and jam entries I’ve tested were really fun to play, more than just being an interesting concept that could become a game.
In my mind, I like to use Ludum Dares to explore new mechanics – mostly in the form of new code – and almost as an excuse for learning something. And to be sure, I’ve done a lot of that; all Ludum Dares have been a great experience, even the ones where I didn’t have anything very playable in the end. I learned a lot in a short period of time.
Still, having to be forced to spend more time with content and gameplay is something bums me out. Having to ignore bugs unless they’re showstopping, and having to get things to work fast (as opposed to right) is something that, over time, I’ve almost forgot how to do. Nowadays, I like to get a cool system to work as a stepping stone. In a way, it’s almost as if gameplay is secondary to that (in that it comes after that, not that it isn’t important).
Something else made me realize that. Over the past few months, I’ve been slowly developing a game prototype on my free time. It makes me really, really happy. I take my time to get some things right – be it gameplay, animation, or lower-level systems – and it’s very rewarding. I do one thing at a time. Putting a pause in developing that to do Ludum Dare #27 was good in technical terms – I ended up learning several features I plan on adding to my game, such as ray casting in Nape – but I also realized I wanted to get some things right rather than just getting them done. For example, my starling shape utility classes – to transform imported Flash Sprites and MovieClip into Starling textures – is a mess. It works, but there’s a lot of edge cases where it doesn’t work as intended, or where there’s a lot of redundant code. And I’ve used it in 3 projects already, with no actual time for refactoring them and making them elegant.
I know the usual solution for Ludum Dares it to use an engine. Some might say I should have used Flashpunk, Citrus, or any other engine. And they would be right. But the reality is that it wouldn’t have been as much fun for me. As weird as it sounds, to me, Ludum Dare is an excuse to write something from the ground up. Not just to get something done, but to appreciate the journey of development. And I’m sure that, for many people, seeing something done is what motivates them over everything else. It surely motivates me. But I’m starting to realize that I care too much about getting systems right. Maybe it’s an annoying developer thing. My own professional work is always done on tight deadlines, make no mistake, but over time I’ve learned to balance it all and use time well to get something that’s mostly right from the get go. It normally means a better, more stable project in the long run.
I’m very grateful for everything I’ve done and learned. Ludum Dare is an awesome idea. But I’m not sure what I’ll do with the next Ludum Dares. I might do them, but maybe as part of a team, or maybe without submitting anything. I may use it as an excuse to build a “demo” of a system – e.g. my game controller classes, which need a few additional features – rather than an actual game to be played. We’ll see.
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!