Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | #LD48 | #ludumdare on irc.afternet.org (Info)

Ludum Dare 29 — April 25th-28th Weekend [9 PM EST] — Theme: ??? (Theme Voting!)
  • Ludum Dare 29 Compo (48 Hour+Solo+Scratch+Src) Begins: in 2 days, 15 hours, 38 minutes, 17 seconds
  • Ludum Dare 29 Jam (72 Hour+Teams OK+Relaxed) Begins: in 2 days, 15 hours, 38 minutes, 18 seconds
  • [ MiniLD 50 | Warmup Weekend | Real World Gatherings | Ludum Deals | Wallpaper ]


    Archive for the ‘MiniLD #03’ Category

    so far so good…

    Posted by (twitter: @S0phieH)
    Saturday, September 6th, 2008 12:30 pm

    really not used to making editors for stuff, but I think I’m blundering through pretty well:

    (heres a link to a web version so you can play with what I have so far)

    use the arrow keys to move the cursor, and click the tile types to alter the current tile.

    didnt quite think the tile thing through, so I’ll have to have a way of having more than one plane per tile. after that I’ll be getting on to textures :)

    Ludumdare World Map idea

    Posted by (twitter: @rtsoft)
    Saturday, September 6th, 2008 5:43 am

    Well, I haven’t actually done anything but I’ve been pondering!

    I think a neat tool website feature(?),  would be dead-simple to use WordPress plugin that allows users to place themselves on a map and can be installed here on Ludumdare for future competitions.  I did this by hand a long time ago but it’s time to enter the 90′s or whatever.

    After some initial looking around I can’t find anything existing that really fits the bill.. a requirement would be the end result has to show the names directly on the map, not just those dumb balloon things.  It looks like this can be done with Google maps using elables.   Hmm, would be nice if they were clickable to bring up more info as well…

    Also, it should be smart enough to only show people on the map who have made at least one post in the active competition so the map stays more or less readable totally zoomed out, at least for that mode.

    Hrm.

    Swimming in a texture pool

    Posted by (twitter: @mikekasprzak)
    Saturday, September 6th, 2008 5:35 am

    I have a seemingly endless list of libraries and tools I want, and a few I need to finish up my current project. So I’ll be starting with something I need. If all goes according to plan, I’ll get to start another one tomorrow.

    So I need a Texture Pool. In other words, I want a nice way to say “hey, load blah.png”, and it’ll use it’s brains to know that I already loaded “blah.png”, and return me the same copy. Pretty straight forward stuff.

    This Texture Pool is a piece I’m adding to my graphics library. Said library is designed to wrap multiple graphics API’s. Currently it wraps OpenGL (1.5) and OpenGL ES (1.1), but it also has a slightly out of date software renderer too (lacking texture support, but does geometry and transformations).

    The Texture Pool itself I’d like to eventually support several formats. Currently it supports a hybrid format of mine, LZMA’d Power VR (PVR) files. The way it’s structured, it’s easy enough for me to support ZLIB, BZIP, or RAW PVR files as well, I just don’t currently. And while I don’t yet support them, I have stubs in place for PNG and DDS files.

    I have some other wild goals for the Texture Pool down the line. Right now, one of my main target platforms requires square power-of-two textures. So I’d like to build a tool for combining multiple smaller images in to a single texture atlas. I’d also like a way to automatically fatten up a PNG image file, yet still somehow remember the original dimensions. This slicing information I’d like to be known by the Texture Pool, so I can draw centered or aligned texture elements with just a call, instead of having to build geometry or remember dimensions.

    My solution to both is a custom file format, vaguely like an archive format. As an added bonus, I want it to be able to support storing multiple images in the same file. But the important point is to create this “many to one” relationship, where I have a single texture and some way to say it contains many elements. I’m leaning towards throwing together a text based format and tool to generate a sliced file, so I can start using this right away.

    Alas, that’s a tomorrow issue.

    Today, we’re building a Texture Pool. After some breakfast, we’ll do it.

    Here goes…

    Posted by (twitter: @S0phieH)
    Saturday, September 6th, 2008 3:35 am

    so I’m going to be making a tile-based level editor… a 3D one… kind of. I guess really its 2.5D but whatever, heres a mockup of the interface:

    fugly mockup

    to tell the truth I’m still working on the bits of it that build the level, but I guess that grows up with the editor, so hopefully it will all fall into place and if not, I’ll learn something :)

    —edit

    so its started coming together:

    yay, 3d flash tiles

    Wall of text!

    Posted by (twitter: @kamjau)
    Saturday, September 6th, 2008 3:24 am

    My first thought when I saw what the theme would be for this MiniLD was, this is the perfect chance to finally start making that pixel/paint program I’ve been meaning to do for literally half a decade! So far I’ve gotten by with Gimp, but I really don’t like its interface, and it’s pretty obvious it wasn’t made with pixel art in mind at all, among other things. Its tablet handling is also buggy, though to be fair that’s actually a GTK issue. (On the other hand, GTK was made for Gimp, so, uh.)

    Anyway, a gfx editor needs an interface. This is part of the reason it’s been delayed for so long, there just hasn’t been any cross-platform interface lib that I’ve been satisfied with, and apart from GTK’s buggy support I haven’t found any cross-platform tablet libs either. Tablet support isn’t exactly essential for a pixel editor, but if I put that in it wouldn’t be just for pixels. And it doesn’t have to be cross-platform, the Linux tablet evdev interface is pretty easy to use (or was, until Xorg started blocking it), but it’d be nice. Still, I’ve made some half-hearted false starts on a tablet-less version using a custom interface in SDL, but SDL is also limited to one window, which is really not that big of a deal either, but still, multi-window support would be nice.

    While these things shouldn’t have prevented me from getting it done, they have been.. irksome. Which bothers me. That’s the problem with being a perfectionist, if you want something to be perfect the first time around you’ll never actually get anything done. But! I’ve been getting slightly better at avoiding that problem, not least of which thanks to Ludum Dare and some other game compos. If you’ve seen some of my entries you know what I mean =)

    Also, SDL 1.3 has been getting to a usable state lately. It’s still in development, but it supports multiple windows and pressure-sensitive tablets, and it’s cross-platform. This kinda leaves my excuses baseless.

    In short, it’s time to make this thing.

    It still needs that interface, though! I actually started working on a simple library for that earlier this week with the intention of getting it done and ready to be used before the compo started, so that I could use it for my tool and maybe others could, too. While that didn’t happen, I did get some things done, and I like how it’s turning out. It’s based on SDL 1.3, using Lua for the interface. You can do stuff like this:

        Frame {
            w = 100,
            h = 100,
            Button {
                label = "Click",
                onclick = function () print "whee" end
            },
        }

    But it also supports a kind of hybrid immediate mode!

        if Button{ x=10, y=5, label="Click" }.clicked then
            print "hurray"
        end

    I say hybrid because I’m not sure it could be called a true IMGUI, since some things like drawing are really delayed actions (though it happens behind the scenes, so you usually don’t have to care about this). This way immediate and retained mode can be freely mixed, so you could eg. have immediate-mode stuff inside a retained-mode frame’s onhover handler, and it’d all combine seamlessly.

    I call it “SIF 2″ for now, but that might change. (If you’re wondering about SIF 1, that’s an ancient project that never really got anywhere. I guess I could just call it SIF. Or probably something completely different.)

    Anyway, it’s not quite ready for use yet, so now I’ve got to decide what I want to do for this MiniLD! Do I keep working on the interface lib, even though that means I cheated by starting way before the deadline? Or, do I make some other tool without using the interface lib, so I can keep it within the 48 hours? I do have an idea for another very simple tool that could possibly be slightly useful. Decisions..

    Salvation

    Posted by
    Friday, September 5th, 2008 11:10 pm

    In the mist of portability problems, java comes to the rescue. Because i use linux, and my artist and X-editor uses windows, i have a problem that tools have to be portable. I don’t want to use GTK+, becouse i don’t think i works well in windows, in don’t know QT (maybe i should learn it?), i was very much prepared to write my own UI in SDL, so it could port (that would never work as well as it should). But this morning i realized (duh), that java solves my portability problem. And i might even get a nice builder, which will make it that much posibble to finish TLM. Might even work. :D

    My plan

    Posted by (twitter: @@mmatvein)
    Friday, September 5th, 2008 9:39 pm

    Since I don’t have too much time on my hands today, after I get back home I’ll do this:

    I’ll find myself a nice music tool that supports my digital piano without a hassle, so I can make some music for my team’s pyweek entry. I’ll also familiarize myself with the software to make creating and editing music feel more doable next ludum dare. :)

    I’ll also try to set the last bits of tools up for pyweek, created the packaging scripts already!

    Mini LD #3 Progress

    Posted by
    Friday, September 5th, 2008 8:42 pm

    Update 1:

    I decided to go for option 1, the ultra-simple 3d modeller.

    The other options didn’t set my “ooh shiny!” reflex ablaze, although they are probably significantly more doable in the time frame.

    In the same vein as Ludum Dare I have given it a Latin name – Carpe Lutum (Seize the Clay).

    I have put all the woes I had with Flex in LD12 behind me – i had so much trouble because I was trying to treat it like normal Flash, and it will resist you every step of the way if you try that. Use it like an app platform and it purrs like a kitten.

    Here is a screenshot of my interface as of hour 5:

    Carpe Lutum Screenshot 1

    My ideas/plans for the tool compo

    Posted by of Polygon Toys (twitter: @pekuja)
    Friday, September 5th, 2008 3:07 pm

    So, the compo has started. The sort of ideas I have:

    • HUD editor/library. Basically, this would be a GUI editor/library with no support for direct interaction, mostly just pretty ways of displaying data.
    • Start work on a multithreaded scriptable game engine. I kinda want to learn some multithreading and scriptability, so I’m thinking maybe I could start building an engine that does those.
    • Library for making replays of a game. This requires close integration on the game’s part so I’m not sure if I could quite make this into a reusable library, but I think this would be an interesting feature to implement. The idea would be that this would be useful for both debuggin and as just a nifty feature on its own.
    Will have to see what I actually end up doing and what I manage to get done. I just moved to a new apartment so I’m kinda compelled to get all of these boxes around me empty.

    Mini LD #3 – Tool Making Weekend Go!

    Posted by (twitter: @ludumdare)
    Friday, September 5th, 2008 2:38 pm

    Hey there Sports Fans,

    Our special “Tool” making Mini LD weekend has now begun.

    I’ve received a few requests from people asking when the start time is. Well, if you haven’t started yet, now is a good time. And if you have, keep going!

    There’s no fixed end time, but I will be making a news post on Monday collecting a summary of the various entries and efforts. Again, you’re not required to share your tool, but do share your progress with us.

    If you didn’t catch it, the theme for Mini LD #3 is “Tool”. In summary, build something to help you (or everyone) make games quicker/better, and talk about it.

    To learn more, see the announcement.

    http://www.ludumdare.com/…/mini-ld-3-theme/

    Good luck, and see you Monday.

    - Mike Kasprzak (PoV)

    My plans for MiniLD #3

    Posted by
    Friday, September 5th, 2008 2:36 pm

    I like the tool theme, but I don’t really have much time for MiniLD #3, since I’m trying to get a Flash game finished for the meez-inside contest. It is nice that the LD is going on at the same time, just to set the mood, so I’ll have the IRC on and watch the posts here.

    However, I’m not skipping this competition completely. For this game I’m using a tool I made myself, Tile Studio (tile/sprite/map editor), and there are some new features I want to add. Also, there are a couple of small bugs in the program, which really need to be fixed. So I’ll be improving Tile Studio this weekend.

    Good luck to everyone!

    It starts…

    Posted by
    Friday, September 5th, 2008 2:16 pm

    As LD12 was my first entry and I started with no tools or pre-conceptions (and failed quite spectacularly!) I have several smaller ideas which I can play about with instead of aiming for one big one.

    Ideas:

    - Ultra-ultra simple 3D Modeller for very low-poly models

    - Asset Management and loader (Graphics, sound, models)

    - Maths libraries (I suck at maths though)

    - Multiplayer server? (already written the main guts of this in PHP, just need to get it finished and working)

    - Tile/map editor for my RetroRemakes entry.

    ASLW

    Posted by
    Friday, September 5th, 2008 1:36 pm

    Well, seeing how it’s most important to finish an entry for LD, i guess my first candidate is more or less done. I’ve done a log wrapper, becouse i needed something to debug my program, while im doing the other thing (i prefer log text over poor debuggers). If i don’t make it, i guess ill tag ASLW as final.

    MiniLD3 – My Tool Ideas

    Posted by
    Friday, September 5th, 2008 5:51 am

    I’ve got two ideas for this weekend.  I’m pretty sure I’ll do #2, but it sounds hard, with lots of math.  I don’t like math.

    #1 – Pixel Editor

    This is a unique idea.  It’s a paint program, with features intended for pixel art, lots of zooming and whatnot.  So what’s special?  Well, it can ‘render’ in various ways.  Think of the Puppygames type of look – big pixelated things, but they’re done up all nice in photoshop with glowing outlines or whatever.  You can take your pixel creation (zoomed in to at least 2x) and render it with several different effects, saving your work in a 32bit png:

    - An outer glow around it in whatever color you like

    - ‘Tetris blocks’ (each pixel is a shiny block rather than a single color)

    - An overall highlight, treating the whole shape as one huge tetris block – if a pixel has no left neighbor, shade its left edge, if it has no right neighbor, brighten its right edge, etc

    - ‘Piping’, highlighted stripes on the internal edges of the shape

    - Other!?

    I think that would be a really cool tool for making that nice modern-retro art.  Almost a SFXr for graphics, in a way.

    #2 – Hitsuji Editor

    I saw people talking about doing this in the chat too.  They called it a manikin editor.  I just want to take the concept of the editor I made for my long-ago LD entry Hitsuji and make it nice and more powerful, so you can do freeform creations instead of sheep holding swords.  The concept is to make models by stringing bitmaps together with pivot points, then you can rotate and translate them all (scaling would be nice too).  Then you make animations for them, and it stores it all much like a 3D model, only it’s 2D.  Then obviously you can put that in a game and animate it all nicely and smoothly.  I love how it’s trivial for such a model to transition from one animation to another.  I could see a lot of potential for games made with these types of characters.

    #1 sounds a lot easier than #2, and it’s more original.  But it’s definitely not as useful…


    All posts, images, and comments are owned by their creators.

    [cache: storing page]