Posts Tagged ‘to do’
First off, to anyone reading this–when exactly does today’s LD end? Is it at a specific time, or just midnight, relative to whomever is doing the dare?
Last day. I’m fortunate that my game happens to be significantly less complicated than everyone else’s, so I have the luxury of effectively being finished, then having an entire day to polish things up. The downside is that I’ve decently recreated everything that I’d intended, so I’m not quite sure on what direction to go with said polishing, aside from the inclusion of music and sound effects. I suppose that’s part of the learning experience.
- Sound Effects – 100%
I expect that I’ll just use the sound effects created for the Atari 2600 version, since they’ll be simple to acquire and appropriate for the retro-inspired style I had intended.
UPDATE: I’ve got some sound effects in, most of them simply recorded from the 2600 version of Heartbreak, though I generated a couple with DrPetter’s awesome SFXr, made for LudumDare participants, as it so happens. The sounds that I chose aren’t particularly great, but sound engineering is something I have zero experience in. May be a field worth learning more about for the future, particularly if I intend to keep participating in dares like this.
- Title Screen – 100%
This took the longest. I’ve been working on the title/credits screens for half the day. My desire to make things as “neat” as possible has resulted in an absolute mess of code all over the place as the entire game only uses three rooms, one that only initializes two variables before kicking the player to the title screen, and one that just scrolls credits on screen, since it seemed easier to use a unique room than to modify an existing room. The remaining room handles all levels and the title screen based on what global.level is set to. It’s both elegant, and an absolute mess.
- Music Integration – 100%
This went off fairly well, especially since the songs I’m using from incompetech.com list the BPMs of the songs, making it a lot easier to make them feel integrated. In hindsight, there is a song for the last three levels of the game that may be almost unfairly fast, which causes the heartbeat to be nearly too quick to get the color you want, so you have to anticipate it. Ah, well–I’m sure that anyone who can make it to that level will be able to handle it.
Pixel Grunge Style? Scanlines?
UPDATE: After some research, it seems that most of the effects like noise or scanlines are done using surfaces, which I know nothing about. I’ll definitely be looking into them in the future, but since I’m on a deadline with this LD, I think I’ll stick with the crisp, clean style that I’ve currently got. Besides, I have a couple other ideas on how I may polish things.
Time to get to it.
After a relaxing night’s sleep, some Thanksgiving leftovers, and a couple YouTube videos to wake up with, I’m back to work! While checking the new posts for this mini-LD, I came across this particular post, which posted a video about motivation.
Now, I, personally, often have trouble keeping myself motivated. I tend to want to go do something else, like watching YouTube videos, playing a game, chatting on Skype, etc. and it’s been a bane to my productivity for many years. In the interest of giving the aforementioned video’s suggestions a try, I’m going to set out a clear list of things that I must get done today and organize them into “modules” so I can see the progress I’ve made. I’ll be editing this post to update my list as I work.
- Mobile Controls – 100%
Mostly complete, and much simpler than expected, thanks GM’s point_direction function. Still need to test it on a mobile device with someone to see how intuitive the controls are.
Update: Complete, with press-dragging to move the blocks and tapping to create balls or change ball colors, if a ball already exists on the playfield. It’s actually very intuitive on a mobile device, which is pleasing.
- Lives – 100%
This was one of the shorter, simpler tasks. The heart is resized based on a global lives variable and is destroyed when the lives are set to 0, which also serves to lock out any controls but a simple tap, which resets the stage.
- Ball Color Checking – 100%
I underestimated the work involved in “Bouncing Ball,” so I’ve split it into two categories, now. Collisions work, with balls correctly changing the colors of the blocks they hit, but I don’t have any bouncing code implemented as of yet. It may prove to be complicated, and I’m not exactly sure how I will implement it. I’ll ponder it while I take a break.
- Bouncing Ball – 100%
Finally managed to get this implemented. Not only did decent bouncing take a while (and it could use some work, but it’s serviceable), but I came across a number of other things that needed tweaking and fixing in the process. There’s still one bug that I can’t reliably replicate that strikes almost at random, seemingly only when a blue ball hits an orange block, but only on occasion. I hate loose ends.
- Level Progression – 100%
This task was fairly simple, and I took advantage of GM’s defaulting unspecified array values to 0 to my advantage to cut down a tad on how huge the level array will be, at least in code. Now to type out the levels, which should be fairly simple–it’s just a bunch of copy-pasta.
- Implement Levels – 100%
There are currently 22 levels implemented, with plenty of room for more. My level system is pretty flexible, allowing me to specify how many rings there are (I’ve set up the rings in a switch case statement so that they’re rendered in a certain order), which colors the heart progresses to (a necessary control for the earlier tutorial levels), and what the odds are of each of the eight possible colors spawning. It worked out quite well, and I could easily add more levels that have different color spawning odds, but I’ll probably leave it at 22.
- Score Implementation – 100%
The current score is rendered on-screen, just above the heart, as in the original Unity3D version of the game. I had to look up how to make it always display zeroes to the left of the score, but in hindsight, it’s something I should have figured out, myself.
Scanline Effect Sound Effects
Time to put on a game soundtrack and get to it. On a related note, while Hotline Miami has an awesome soundtrack in the game itself, it doesn’t make for good listening on its own. FTL and Super Meat Boy are great to just listen to, though. If you can think of some others, let me know.
Not quite sure if I should call it a ‘post-mortem‘. There are hundreds of these already there. It’s not about what I think went right or wrong. It just … did. Generally I’m glad the way it turned out. However, since I want to keep working on this game I’ve decided to make a list of changes I want to apply to it. That’s why I called the post ‘The Aftermath‘.
The main purpose is to expand it and make the framework more flexible. Then I will extract it and use in future compos.
So, here it goes:
Level entities’ management. Every object in a level is derived from a CEntity class. The examples are mainly … blobs. The pointers to the entities’ instances are stored in a globally-accessible array, which can be accessed at any time. When an entity is no longer needed – it gets deleted and the array is rearranged, getting rid of an unnecessary pointer ( it’s a C++ vector container ).
What if we want to store the reference to the entity and use it on later occasion? For instance, a blob chasing another blob could save a reference to its target and update its position every tick based on that. Storing a raw pointer to the data in memory is risky – we are not able to check whether the entity has been already deleted and the memory’s been freed. Trying to use such a pointer would result in very pesky and hard to track down bugs.
That’s why I came out with the idea of … IDs. An entity’s ID is an index at which it can be accessed in the main entity array ( the STL vector mentioned earlier ). When an entity is about to get deleted, the memory is freed, but the pointer in the array is set to NULL. That way it never gets overwritten and we can check if the object is available, or not. An ID would be an unsigned integer, so it could range from 0 to over 4 000 000 000! The free IDs will never get depleted and the entities themselves will be getting deleted from memory at a constant rate.
The array itself could be though great in size after a while. Every frame each entity needs to receive a tick. Iterating the entire array will be getting more and more time-consuming with the number of the array members growing in size. So … what about a second array? It would contain the IDs of non-deleted entities – that way only the valid members will receive a tick every frame without iterating through the NULL-ed entries.
Although it looks complicated compared to the previous system, it seems that it’s worth a try. Did anybody run into similar, or other worthy conclusions on that matter?
The level editor. Because of a lack of time, I had a really tough time designing the levels. A level editor and an external level file format could really get in handy in this case. Running a game, writing down coordinates and typing them in manually in a source code doesn’t sound appealing, especially when you’ve got dozens of objects which need to be somehow adjusted. I have really no idea how I’ve managed to put all of these blobs in place manually in 48 hours.
The scenes. The hardest thing to think through than the levels themselves. I’m talking here about an intro and ending scenes. Naturally, when you have an idea, you write it down as following: “It fades in within the first 2 seconds. Then it plays the sound X, waits another 2 seconds, shows a few lines of text slowly and gradually fading in …” etc. Not a tough job. It gets complicated, when you only have a level tick method called every frame to put these things in.
Let’s say you want an entity to play an animation after 2 seconds after the beginning of a scene. In the level you’d have to write an if statement which will be called each frame. It’d have to check, whether the time from the beginning of the scene was greater than 2 seconds and if it hadn’t been already greater that 2 seconds the frame before ( starting playing a sound every frame wouldn’t sound pretty – it must be called once and left alone for it to play along ). If there’s many of such ‘timed events’, we need a lot of variables. And now, if not the static variables available in C++, I’d find myself in the dead end. Although the scenes work pretty well, the code itself is a massacre and I was really confused which if statement was responsible for what event.
The threading system could be excellent here. Unfortunately I did attempt this concept few months ago and failed tremendously. Maybe because I used very unfriendly Windows API, who knows? But what other alternatives do I have?
And that’s when I thought of … Lua. I never had the opportunity to work with Lua and so I don’t know its specifications. Hopefully it allows for such maneuvers. I’ll have to dig into it. Is it possible to use threading in Lua?
That’d be it I suppose. There’s a lot of other points in my list but these are regarding either entities’ classes in particular or their implementations. Anyways, after polishing out the game itself, I will add more enemies and more levels, scenes. Hopefully it will come with a great ease. Greater than previously, that’s for sure. Eventually I will publish it.
If you have any suggestions, I’d appreciate if you shared them! I don’t want to implement a total bummer and base the upcoming code on that