Holy shit, the music and SFX for this game really pop so far.
The gameplay's really shaping up and looking promising-- I hope that the level design has enough thought to make the game just keeping the challenge at the perfect height.

ALso: I like the zoomout at 1:45. Oh.. that was your camera, right? Hm..


Nobu, AMAZING work. What're you programming this again?

Well, I was writing up a nice and thoughtful comment when Linux CRASHED THE FUCK OUT. So, let me try and gather my thoughts and try to remember what I was gonna say.

1. While the sfx are a mix of original and free samples, the music is actually from another game called "The Scheme", an early Yuzo Koshiro score! While I plan on having everything being original for release (this is a commercial project after all), I'd have to work very hard to even come close to something like what Koshiro puts out.

2. Now that the toolchain's ready to rock and roll, I'm hoping my co-workers can help me out with some of the level design. I'm working on various ideas to keep the gameplay fresh and interesting throughout. One of the big selling points my boss wants me to emphasize to keep the game selling is in fact the ability to design your own dungeons and maps for it. We'll see how that ends up working out in the long run, but it's exciting nonetheless.

3. The zoomout is actually 2 videos stitched together very carefully!! FRAPS refused to record the game running at 60fps at its native resolution, so I had to make a special 640x480 scrolling version of the game to make the capture. When it came time to record the menu subsystem, I had to capture the entire screen at once, so the second video had to start pretty much exactly where the first one ended.

4. The game's being made in MMF, for now. I've run into a lot of issues using MMF, so future projects will be done in another language.

Looks great and coming along well x3

Wow. This is looking pretty slick so far :3
AND YAY JUMPING. I FUCKING LOVE JUMPING.

This is looking great so far. Jeez you work fast. xD

Wow. I've only just started to experement with pixel sprites. How are you putting all this together, and test your caracter sprites, let alone build them?

BTW were those omanyte you were wacking away at?

they're all placeholders munged from various random places really. The important part is to have the size and hotspot metrics down for the assets so that the graphics match the gameplay. So, I go with a general idea of how I want something to be, then go looking for something to fill the missing gap to slap there until I can get something better. If something doesn't exist, I'll either make it myself or edit something which already exists.

This is not usually considered kosher for a production game, so of course I'll be hiring a professional to go and do over all the character and enemy graphics, as well as some tilesets. If I didn't think doing the engine (and likely, a big chunk of the soundtrack) was a daunting enough task, I'd probably attack some more of the graphics. But pretty much the only original gfx in the video are the menu graphics, and small things like shadows and particle effects. Everything else in the gameplay video are temporary

heh how about u use a real programming language,,

just kidding i will buy your game

Oddly, the thing that I'm most impressed with is the menus - because I have first-hand experience of just how long they can take to get running smoothly! It's nice to have someone else doing the graphics, not having to worry about the mechanics and the visuals at the same time - I've tried to replicate that in my own project by just sort of ignoring how shocking my own graphics are until the very end, and it's freeing to be able to concentrate on making things look good, with all the actual game mechanics already handled.

It's good to see you coming out with stuff again :)

thanks a bunch :)

One thing I discovered which is really kinda annoying to me is that the graphics do play a much larger role in things like visualization of hitboxes than I would've liked. Increasing the hitbox size for the sword, for example (a suggestion some folks have given me) will require increasing the visual metaphor for the sword when it's out and swinging. Making it look good while attached to the player character will depend on the proportions of the final character graphics and how "realistic" the body proportions are compared to the width/height metrics of the respective parts. Ironically this means that I've ended up taking some ripped graphics, and adding entirely new pieces to them to visualize some of these things (lol). No problem in the long run, I think, since they'll be ditched anyway.


As for the menus, I really appreciate that someone can see what kinda work goes into making those things for MMF! The entire system is hierarchical and I worked to make the windows themselves as object-oriented as possible. Their drawing animations are all stored in a behavior, so the window itself is actually a clever widget which custom-draws a few rounded rectangles on a surface and shades 'em! I put a lot of work into making sure I can expand the system easily if I needed to, and make changes where I deemed them necessary while still having something pretty to look at.

When the user presses the appropriate button on a menu, the system generates a new object relative to the last menu and gives it a unique, hierarchical ID from the main enumerator object. This allows windows to "talk" to each other but also to distinguish themselves from one another when multiple windows have focus at once. Furthermore, when each window is given a call to destroy itself, it creates an object which does its closing animation separate from its parent. This means that you can jam on the buttons all day and the enumerator shouldn't ever get confused with window or group focus (a BIG deal in MMF games since user input are loop-breaking events!). It also means multiple windows can open and close simultaneously and input focus will still go to the proper menu.

oh, and of course, the main movement engine and scripting engines are in separate groups, so when the menu is activated, the game is effectively paused. The only thing that I don't like is that you can't "pause" default MMF movements and restore them perfectly, so I can't rely on those anymore for cheap enemy AI if I want them to behave predictably should a user jam the menu key a lot :C

Yes, a lot of the trouble with it is that there are two very distinct modes, one where you're using the default quick and easy movements and get something done quickly but with a signature MMF-y look, or one where you have to do everything manually and rapidly get tied up in events. Knowing exactly how those work and what it's thinking at every stage underneath is the equal of learning any code-based language :) I still love having graphics and collision detection automatically handled too much to go and write a game from scratch, though... I feel if I spent my time in the same IDE at work as at home I would rapidly go insane.

Having an actual system that you can expand on sounds like a wise choice (much like for level generation and loading) - I know it's a great feeling when one of those systems just... works :) In CT2, the menus are an abject boatwreck of checking for unnamed values of different objects to see if a keypress should be allowed or not, and even though I thought I had organized it well at first with groups and layers that get toggled on and off depending on options selected, it's quite unwieldy to alter their order, and there are entire menus that are no longer ever used but still exist, because it would take too much time to untangle them. This is a further problem with allowing a project to go on for four years - by that time, you've learned so much that you sort of want to rip it all out and start again to do it better. For example, each of the 40+ levels is in its own frame with its own events, and I can tell you right now that that's never happening again.

It's not far off being finished, though :)

oh noooo @w@

you know the part that bugs me the most about these big games in MMF is that feeling when you know the crap you thought would help you make the project easier or go faster ends up being a major hurdle in the future! That seems to always happen! :C

The latest issue I've had is a huge memory leak with MMF caching backdrops created from extensions.... since my engine uses Surface extensively to paste backdrops of the level on each frame, the RAM usage jumps up ~4mb with each new map loaded! I talked to looki and yves about it (and provided an isolated reproduction of the issue), cause it's such a serious game-breaking problem, but it's been over a week now and yves hasn't made another peep what the issue is so I may have to rip out the whole thing and re-do the tile loader using Active Picture Objects again just to make the game viable :C

Worst case scenario, he comes back and says it's such a deep issue that it could take months to fix, or even have to wait for MMF3... insane thinking how something as simple as a backdrop has so many issues with RAM usage when there's too many of them in the frame / too many variations...

The previous APO-based tile engine was scrapped because it averaged about 4000 backdrops per screen (optimized to remove invisible tiles). They don't add to the debug object list, but they do add to the object count, which could cause the game to crash if too many objects appear on the frame at once! Autotiles make the problem worse since they're half the size of a standard tile @_____@


Every time I get into this, I say to myself, "I've learned my lesson, never again.....", but MMF just keeps drawing me back in. I really need a more solid framework to work under in the long run, I think :C

The danger whenever you're working with somebody else's framework :) I'll see if I can put a word in for you about the Surface object if I see either of them, though (I've never used it myself). I'm surprised nobody else has encountered it.

you don't have to. I don't want to be annoying. I've already talked with looki a lot about this, and both him and Yves claim they're very busy at the moment. There is a private thread which is supposed to be specifically about this issue, so if there isn't any word on it for a couple weeks I'll poke the thread and see if Yves could confirm the bug.

I think possibly the reason why nobody else has encountered this bug is because I doubt very many people have extensively used Surface to load large amounts of custom backdrops into their applications. Previous tile engines typically relied on APO for the backdrop handling, and while it is somewhat inefficient, it seems to be able to be properly garbage-collected when the frame ends. Now, this could just be something Looki's doing with Surface, but if it is, he doesn't seem to be aware of any way his method is causing trouble. It could be that the API to backdrops from the extension SDK doesn't garbage-collect properly at the end of a frame. Regardless of the situation, though, it causes an insane leakage of RAM.

I first noticed it when making this demo: http://www.youtube.com/watch?v=pfyq_fafvOs
Surface rotates a tile before pasting it to another surface, which it handles in memory just fine. It's really slow in HWA when combined with other objects and at 1024x768, so instead of continuously shifting the pixels in the bitmap, I transferred the entire generated surface to a layer and then shifted the layer. Because each layer of truchet tiles was unique / algorithmically-generated, each background paste added a new bitmap to memory. These Surface-created backdrops aren't eliminated from memory when the backdrop's destroyed, nor when jumping to another frame, but only when the application is restarted. Interestingly, APO also continues to cache backdrops in memory after they're "destroyed", but must mark them for GC because they're eliminated on a frame jump.

why are you attacking poor little marshmallow peeps?

It's so awesome to see this in action! It looks like you've been working your butt off!!!