Posts Tagged ‘Flixel’
So I’ve been making small changes and additions to what was my Ludum Dare basecode, and its getting to the point where I think it might actually be useful for other people. This begs the question: What do people actually need/want in an entity/component management system? Anything you can think of, please post in the comments, or tweet to me @nico_m__
Note that my system is for HaxeFlixel, and is already available on github, the point of this post is just as a general question though, whether you use flixel or not, what would you want/need in an entity/component management system?
After throwing a hissy fit over the theme last time I’ve decided, on retrospect, that the issue wasn’t with the theme, but with my incredibly narrow and literal-minded interpretation of the theme.
So I’m back in and I’m going to figure out something for this theme regardless of how much I’m inevitably going to hate it.
- IntelliJ – Code
- Flixel – Framework
- Pickle – Graphics
- AutoTileGen – Graphics
- Bfxr – Sound
- DAME – Map Editor
- Sunvox – Music (ahaha unlikely)
Here’s hoping this time around goes better than last!
Hey guys, I’ve been taking part in the Ludum Dare competitions since April last year, and it would be an honour to take part for another year!
This time, I’ll be switching up my tools. Last year I primarily used Game Maker 8 on Windows, however I’ve recently turned to free solutions instead:
- IDE: Sublime Text 3
- Framework: HaxeFlixel (Haxe/OpenFL/Flixel). Definitely check it out if you haven’t already. It’s absolutely fantastic! (apparently they’ll be supporting consoles soon, that’s awesome!)
- Art/Asset creation: GIMP
- elementary OS. It’s a free Linux operating system based on Ubuntu. It looks amazing, and it’s lightning fast. Not sure about livestreaming with it though. We’ll see, I’ll do some tests soon.
- As for music, I’ll switch over to Windows 7 half way through to use FL Studio.
The game I make will be uploaded to Itch.io, GameJolt, IndieDB, and the Google Play Store (see point below)
Expect the game I make to be released on all desktop operating systems (either Flash or native compilations), and Android Phones and Tablets. I will likely design the game with phones in mind.
Good luck everybody!
Although it was not completed in time for the Jam, we would like to share the game we started for Ludum Dare 28.
More details at the link above.
Hi guys and fellow devs,
Just wanted to hop in the postmortem wagon and let you learn a bit more about how I worked on “One”, my LD28 entry. English isn’t my mother tongue, so be ready to read approximate french-glish.
If you’re interested, you can first test my game here.
When I heard about the theme, I got a little disappointed because I voted against it, for the simple reason it didn’t inspire me that much. I almost gave up on participating. My first idea was to make a game about getting only one seed in an arid world, but it was too complicated and, in my opinion, not original enough.
I was a bit depressed that saturday, the sky was dark. Thinking about the LD smoking my cigarette outside, I suddenly decided to cheer myself up by cheering other up, and I decided to make the happiest and cutest game I was able to do in 48h.
With that in mind, I thought about the theme again and remembered that one dream I used to have which filled me with happiness. In this dream I wasn’t flying but jumping so high, and falling so hard ! It was fun and magic. I decided to turn that into a small game.
For those who didn’t play the game, the game is about a little child who learn to jump up to the stars. Little light balls help you to get higher and higher.
I’m what you could call a experienced dev, with more than 20 games released in my career, and 4-5 game jams. After several years, I’m now experienced with scoping a game. My advice is to always go for the simplest idea you can have. Because during the course of development, either for a full game or a jam, you’ll always spend twice the time you planned on small things like researching, debugging, adding signs and feedback, etc. We always tend to underestimate the details, so focusing on the simplest idea and growing from there is often the best solution.
I used Flixel, which is, in my experience, one of the best technology for game jams, for two reasons : it’s perfect to create very small projects in a very short time, and it’s meant to be distributed online, as it’s Flash based. The second is useful for LD because people tend to test games with Web version more (it’s far from being enough to get a lot of ratings, but it helps a bit).
My idea for One was so simple I managed to tackle gameplay code in a couple of hours. I love when it goes that way, because I know I can use plenty of time to make art, music and moreover add signs & feedbacks.
Several people have been surprised, playing One, that there isn’t any instruction. Well it’s been a choice. I love to do game jams to experiment with ergonomics. Having no instruction is a risky challenge. If it’s done right it helps immersion and focusing on the message of the game. If done wrong, it simply ruins the whole experience. So far, I don’t think anybody really got stuck in the game, so I would say I’ve done it right this time !
Here are a non-exhaustive list of simple things I implemented to make sure players learn how to play by themselves :
- Control scheme : as intuitive as possible, only three buttons (left, right and up). Duplicated on ZQD and QWD
- At least one bonus is visible on screen at start, encouraging to reach it and learn to jump and move.
- Audio feedback when touching bonus and also when reaching the current max altitude, hinting a bit on what to do.
- Midgame, my texts help a bit, by notifying that there’s more to discover upward.
I’ve worked with Photoshop. I’ve made backgrounds mainly using a brush to get this cloudy aspect. I didn’t want to spend too much time on animation so I made only a few poses of the character, mixing pixel art and painting techniques.
Surprisingly, I spent most of my time on music, with at least 4 hours spent on it. I must say I got a little carried I really enjoyed making it, so I wasn’t able to stop until I was satisfied with that small piece.
What went right
This LD went really well, for the main reason I did a game with a message and an intention in mind, I think. Working with the purpose of sharing a bit of love and poetry is wonderful. I managed to do a little something I’m proud of in far less than 48h because I didn’t get too ambitious and managed to focus on a simple idea and make the best I could of it.
What went wrong
The game was a bit oversized, and loaded from a website it discouraged some of my early testers. They complained it wasn’t working because I forgot to add a preloader : the page showed a blank page for around a minute. I hope those early testers didn’t rate the game too bad. I also stupidly forgot to proof-read my texts and let a small typo in the game (which I corrected later, as I learned it was allowed).
Make game with love, message and passion, focus on a simple idea but don’t forget about the little details ! Happy new year everyone, and let 2014 be filled with hope, love and plenty of wonderful games ! I think games can help the world be a better place, so keep going guys, I love you all.
You can reach me at contact [at] cuvegames.com if you have any question or feedback which I would love to have.
Here it is my post mortem about 0RBITALIS. For this game I got inspiration looking at other themes in the final round. It’s hard to make a game that is as vague as “You Only Get One”, but when you couple it with “Gravity” and “Chaos” it’s much clearer what you can actually do. I have always been interested in games which explore how simple rules (such as Netwon’s laws) can generate beautifully complex behaviours.
Most of the “features” of the game are actually consequences of the strong time constraints Ludum Dare imposed me. For instance, mi initial idea was to have a moving camera that could zoom in and out, but I didn’t have time to code it properly. And this automatically lead to a “stay in the system” mechanic. The vector fields that you can see in the background was a debug tool I used to test and calibrate planets’ masses, but when I realised that it was fitting nicely with the style, I decided to leave it there.
Since the very beginning of the voting period, 0RBITALIS got a lot of attention: so far, it’s both the most voted and commented entry in the 48 hours competition. I think part of its success is due to its aesthetic: it’s simple, yet effective. I spent lot of time polishing the game rather then designing more levels. This can really do the difference, especially when games are picked almost exclusively by how appealing their screenshots look like. 0RBITALIS has doing unexpectedly well. For this reason I am already working on a full-game version that will include both more levels and new mechanics. There will be probing missions, for instance, which require to scan a celestial body for a certain time. I am already working on landing missions as well, but I’d rather keep them mysterious for now!
Since I *hate* menus, 0RBITALIS won’t have one. I am working on a different system, however, that looks like a star chart. Player will be able to select levels and to change settings just touching and connecting stars. I also collected lot of statistics about levels but… I’ll keep them for another post!
If you liked the game, you’re more then welcomed to vote it or leave a comment on its LD48 entry page. If you want to follow 0RBITALIS news and further development, you can find me on Twitter as @AlanZucconi.
Hey all! I’ve been enjoying a lot of games from this Ludum Dare, and I hope you all have to. I participated myself in the jam, collaborating with another indie game dev known as Code_Assassin. However, through details I’ll explain below, we didn’t finish. While we did submit an entry, it wasn’t a finished game like we hoped, and after a day of thought, we requested the entry to be taken down, and the game removed from Newgrounds.
Our game originally started off with a premise of finding a mob boss out of a group of people, the levels and the clues would be random each time, but you only had one chance at killing the boss. We agreed on using Flixel as our framework due to its ease of use, my experience from using it in last year’s Ludum Dare and CA’s experience with Actionscript3, and that we could upload it to the web. We got a Git repository set up and we were hyped up and ready to go!
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!
First Ludum Dare I’ve participated in!
Engine: HaxeFlixel (probably using some code from the demos)
Graphics: Inkscape + Gimp
Sound: Sfxr + Audacity
Music: Probably Musagi
Tilemaps (if I decide I need tilemaps): Tiled
I was the one who made the unusually challenging 10 Second Paper Flight. This will probably be a hectic Ludum Dare for me since I’ll be at a Christmas Party on the Saturday and work on the Monday, but what the hell, I like making games and I can use some of Saturday to plan something interesting.
Anyways, I plan to use the following tools:
- GitHub (Source Control, my first ever solo project to use source control :O)
- HaxeFlixel (Game Libraries)
- Paint.Net (Graphics)
- Tiled (Possible Level Design)
- iNudge (Possible music)
- Bfxr (Sound Effects)
My plans/advice so far for the jam, based on last Ludum Dare:
- Plan well.
- Constantly show your progress.
- Graphics and Music are just as important as the game itself.
- Know how and where you will distribute your game.
- Everyone likes Time Lapse vids
- Follow the 621 (Sleep, Food and Clean Yourself :P)
Everyone have a good Ludum Dare!
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.
Time for our post-mortem
I won’t re-introduce the team, you can go to our “we’re in” post for that. Basically there were 3 of us and we’re pretty awesome!
So what happened?
Well, we made a time-bending tower-defence game called “10 Second Onslaught”. It’s about an onslaught you see, and the onslaught in question lasts 10 seconds:
The game wasn’t really “finished” after 72 hours even though it’s completely playable. I’m actually glad we were over-ambitious though: it’s a good beginning and something I’m still working on (in a separate branch of course )
What went well?
The art pipline was probably the one thing that went particularly well. Thomas is really a 3D artist, so soon reverted back from pixel art to making models and rendering them to bitmaps. To speed things up I wrote a couple of little ImageMagick scripts to mirror and then stick these images together into sheets. Then it was just a matter of using the haxelib spritesheet to have animated characters in the game
What went badly?
For various reasons, mostly the technology (OpenFL) being something only I had ever used before, I ended up writing a majority of the code, which is just stupid. Next time we’re going to have to organise ourselves better.
Read on for a rather long discussion of OpenFL, including comparisons to Unity 3D and Löve 2D…
Well our first LD is over, we’ve made our first ever game together as a team, and we’ve got the obligatory platformer out of our systems
Technical stuff: Made with Haxe 3.0, Flixel, Flashdevelop, GraphicsGale, sfxr, Autotracker, Excel.
What Went Right
- We finished a game in 72 hours without killing each other!
- The toolchain worked really well, Haxe, Flixel & FlashDevelop felt very familiar despite not using any of them before the warmup.
- Use of Microsoft Excel (hardcore mode!) as a level editor. There are obviously some very good tile map editors out there, but learning them would have taken way more time than setting up a spreadsheet with some conditional cell colouring.
- Bringing in a third person for brainstorming and powerup graphics on the first day. Thanks Graham!
- We anticipated that the main source of bugs would be unexpected interactions between multiple powerups, and set time aside to get this working properly.
- Almost all of the powerups we came up with initially made it into the final game.
- Staging the powerups and level progression to ease the player into mechanics without explicitly telling them. Combining different powerups gave us a clear sight of what obstacles a level needed to have, and a convenient “to-do” list for the 20 levels we built.
- Targeting web – easier for people to play off the bat, rather than having to install or download or compile, it just works on most platforms. Having never built a Flash game before, this was surprisingly painless.
- The platformer controls and the level design we thought went well, it felt polished and enjoyable to play, even when getting squished every 5 seconds
What Went Wrong
- Difficulty with scaling the character & collisions, as well as the timestep changes interacting poorly with the collision logic in Flixel. Getting it running at 60 resolved most of this, but there are still spots where a random bit of wall will just make you explode.
- Lack of experience with the IDE & HaxeFlixel meant the initial setup wasted about an hour.
- Music was a bit of an afterthought, we tried a few different packages to create the music eventually settling with Autotracker.py.
- Collisions. The collision logic wasn’t quite doing what we expected it to, and we wasted time re-implementing certain collision features that were already present in Flixel.
- We had smooth interpolation for the scaling of the character, but had to take it out as the player kept getting stuck in walls during the scale change. In the end we had to bodge in level-specific fixes.
- Not understanding transparency in GraphicsGale – a lot of time was spent sucking the backgrounds out of sprites using Photoshop.
- While we’re pleased with making a platformer that feels nice to play, the genre is obviously well-worn as a Ludum Dare standard. We defaulted to this because we knew we could get the game finished in the 72 hours, but it’s kind of old hat to people who’ve been doing LD for a while.
What We’ll Do Better Next Time
- Familiarise ourselves more with the tools, as well as deciding in advance what software packages we are going to use rather than flailing around!
- Artwork – practice creating artwork for next time, it had been a while since Bob had done any serious artwork and the simple 5 minute sprites that we knocked out were OK, but could have been better. Paul plans to learn some pixel art techniques too!
- We need to have alternatives for different game types, HaxeFlixel was good for rapidly building a 2D game, but it would have been nice to have the option of 3D.
- Work out how to use Flixel properly, rather than having to hack bits of code together to bend it to our will.
- Get together some flexible game ideas that we can adapt to the theme, instead of just defaulting to a platformer.
Please play our game, and let us know what you think!
Watch our timelapse video!
Play these awesome games that we’ve tried over the last few days!
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!