Ok, another little “experiment”: cell-based movement. On each keypress the character slides 8 pixels left, right, up or down, thus keeping aligned with the tiles. Also, the character’s position is constrained to the inside of the “room.” Next up: solid walls and some cell-based collision detection (i.e. divide coordinates by 8 and compare…)

 

On the game design front, this is turning into a series of rooms that the player has to traverse avoiding hazards and maybe solving simple puzzles. Vague and yet not very original, I know… ;P

 

Ok, not much time to do anything, but I decided to join. Maybe I can do something in a few hours? (since I won’t have much free time tomorrow?)

Wish me luck!

A zombie and the player

 

I’m working on a wave-based platformer where you have to protect a building from raids and sieges of different kinds of monsters. There are different kind of weapons and support gadgets you can use to protect yourself.

Ok so I think that once again I started writting something over-ambitious, but anyway here’s my progress shot after the first day of coding on my MS-DOS first person dungeon crawler game (not gonna happen): Deepstone…. (details after the pic).

 

I’m running this on my old Pentium 200mmx MS-DOS machine, as seen in the pic. It still sucks a lot, but I’ve got crappy affine texture mapped polygons, 256 color palette managment which automatically manages the gouraud shading color ramps on textured polygons, 3D polygon clipping,  and first person shooter-like camera control with free mouselook.

It’s not all from scratch; some of the code I’ve ripped out of a simpler DOS 3D hack I wrote about a year ago. For the most part what I did today was port the code from 16bit BorlandC to 32bit WatcomC, rewrite the rasterizer, write a 3D polygon clipper, and fix horrible bugs all over the place. The 3D scene in this shot was ineptly created in blender.

The idea, which doesn’t look like is going to happen, is to have the player walk around a small pre-modelled dungeon, and collect treasure, while ideally fighting a couple of “monsters”. Realistically, it’s very unlikely that I’ll find time to add monsters, so it might become just a dungeon “exploration” “game” (note the amount of quotation marks

Tags: DOS, dungeon crawler, MiniLD #45, software rendering

Today I whipped up a proof of concept for MiniLD #45. It is written in C.  My tools of choice are MinGW and SDL2, everything being 100% open source.  I wanted to do OpenGL as well, but since I am totally unfamiliar with either MinGW or SDL, I figured this would be a good enough start.

I managed to get all the basics to work, that is: bitmaps, sounds, keyboard, and mouse.  In C I got a fair performance, of up to about 20,000 moving objects.  The code is pretty simple, so it may be useful for some of you who want to participate in the MiniLD or another LD as well.

It’s not much of a game, though it’s playable and fully functional.  Maybe tomorrow I can turn this into an actually interesting game.  I hope it works decently on other computer as well! The first level has 1000 enemies, the second one 2000, etc, up till 5000.

You can download the game + source here:

tmtg.net/ludumdare/pix-l-tron/pix-l-tron-prototype-20130922.zip

Pix-l-tron level 1

 

So today I got most of the fundamental gameplay in place for my game.  There are now two enemy types who pursue the player, one which shoots at the player and the other which tries to swarm the player at close range.  The player also has three weapon types, though two of them are effectively identical at the moment.  There is also a rudimentary GUI that tracks player health, monsters killed, and weapon type current equipped.

Tomorrow I am going to focus on adding content and creating a progressively increasing difficulty curve.  I am not sure whether to add audio, but if I do, it will be fairly primitive.  I am actually having quite a bit of fun with this, which is probably helped by the fact that I chose a super low-scope game to build.  Hope everyone else is also enjoying their MiniLD!

As usual, I cross-post this to my personal blog.

Tags: MiniLD #45

 

Aw yeah. Got the tilemap loading / drawing / collision working! This is all the main tedious parts out the way. I managed to write the worlds smallest (and worst) .TMX loader so I can just load the Tiled level files right into the game. It felt a bit funny using tech from the 80s to load XML, a format which wouldn’t be invented for another 8 years.

I think the game is going to end up needing a Pentium at the very least, I doubt I’ll get it running well on a 486 given the time constraints. The sparse colour palette was a stylistic choice, I could display up to 256 colours — more colours will probably come into play later.

Could not get anything decent working on time, and I have a lot of other things to do, so… that’s it for me. I love the theme, but my personal life got in the way. Maybe next time.

At least I learnt that my OpenGL skills are VERY rusty. I really need to practice a bit before I try to do anything with it again. It was good using a bit of C++ again, though. C# really has spoiled me a bit, and it was kinda refreshing, have to worry about things like memory allocation/freeing, references, linker errors, build events and all that hellish thing. I love it

Good luck for you guys!

I spent a few hours yesterday wrestling visual studio and blender. It’s unbelievable how many convenience shortcuts and refactor tools Visual Studio C++ is missing in comparison to what I am used to from eclipse and Java. Maybe I am just to stupid to find the cool features of Visual Studio, but I really wish I had started with CDT from the beginning…

Nevertheless I was able to establish a very rudimentary workflow that enables me to uv-map things in blender, create basic scenes in xml format and display everything with lights and shadows in a Horde3D scene. I also got Coment – an entity component framework for C++ – to work. Everything takes really long because there’s so many things that I either don’t know or that are just overcomplicated

Horde3D is based completely on shaders and doesn’t use the fixed pipeline. That leaves room for a lot of things you can do with it by writing own shaders and I think I want to focus on writing my own shader for the rest of the day.

Don’t know if I will come up with a game  in the end, but I am really enjoying to learn some new stuff and leaving my java/libgdx/2d comfort zone for a while. I have a cool idea for an educational game (yes, educational games can be cool) but I think everything takes far too long for me to get it done this weekend.

Hope you guys are having fun too

MiniLD “Progress”

I just posted a post-compo version of my LD27 entry, The Vengeful Baby-Men, to Kongregate.

It’s largely the same game with a few minor fixes/enhancements. The biggest addition is integration into Kongregate’s High Score lists. See if you can get the best time!

The Vengeful Baby-Men on Kongregate

My Mini-Ludum Dare #45 entry has been posted and is located http://www.ludumdare.com/compo/minild-45/?action=preview&uid=15656 . It is my first NES game written in 6502 assembly language. I was already familiar with 6510 assembly language from my Commodore 64 days so the big learning curve was understanding the NES hardware. This worked surprisingly different from the C64 making this a more interesting challenge than I expected. Needless to say, if you want to try this game you will need a NES emulator. I plan on looking for a web-based emulator so I can have the game running on my site but that won’t happen for a few days. The goal of the game is to get to the treasure chest while avoiding the ghosts. There are 4 levels in the game.

So I just finished Monster’s Maze and uploaded it to the main thread!  This has been a very whirlwind experience, since I didn’t at all expect to participate in this MiniLD, especially not since it only lasted 3 days and I had other work to attend to.  And yet here I am, and I think I can say with confidence (I hope!) that Monster’s Maze turned out even better than my MiniLD #44 entry (Jumpstarter).

The development process was incredibly smooth, with only a few major blockages.  I think it helped a lot that I chose to make such a heavily restricted game world; that helped me focus my efforts on gameplay and balancing.  I’m happy with the end result; it may be a little too hard (I can’t even survive until unlocking all weapons!), but it’s frantic and hopefully fun.

I also learned a few things.  Diffusion-based pathfinding is amazing, really, and I will have to pay close attention to my future projects to see if they would benefit from an implementation; it’s such a useful technique, that alone was worth getting into this MiniLD for.  I also learned about using cellular automata to create mazes (and how to deal with the mazes if they aren’t completely navigable – interestingly, diffusion-based pathfinding really helps fix broken mazes!), some minor SFML details, some debugging techniques, and had my first real clash with the need to balance numbers in my game, both directly and algorithmically.

Great and rewarding fun, all in all, and I hope everyone else enjoyed their time too!

As usual, cross-posting to my personal blog!

Tags: MiniLD #45

Oh well, weekend is over and I am not close to finishing my little game for Mini-LD #45. I intend to keep working on it but there will be no submission for the jam…

 

 

Submitted the “game” last night, but I was too tired to make a post about it. Game is over here.

I unfortunately didn’t didn’t get a chance to finish it, so it’s very short. That being said, I’m rather happy with the results. I was using a very old 16bit DOS compiler (turboC, 1988), I had to run it with warnings disabled as it wouldn’t shut up and no amount of brackets and casting could make it understand that I meant to do something a certain way — the lack of useful warnings was a massive contrast to how I’d run GCC, with -Wall. This lead to a lot of bugs, glitches and issues throughout.

I’m also convinced that as you approached the 64kb global/static memory limit in TurboC that some variables would begin to overlap or something to that effect. I did a little reading and discovered TurboC was prone to a lot of weirdness, so it doesn’t seem out of the question. Knowing the compiler would be less forgiving in terms of warnings I specifically approached the code with the intent of avoiding malloc (I did use it for allocating memory for the images, though), I only discovered later on about the global/static memory limit. Despite turboC’s 64k limit there was something quite nice about only using the stack and global/static memory, as if you get a much clearer idea of exactly how much memory you’re using and don’t need to worry about memory leaks or other memory issues, everything has a preset upper bound. This has made me consider writing a game that doesn’t use malloc at all in the future, although I’d have to use a different compiler.

I may do a longer write up on the technical aspects of the game and its code, but I question how relevant the information might be in 2013 😉

Looking forward to trying out some of the other entries, I saw some impressive screenshots being posted. I’ll hopefully get a chance to give them a go this evening.

I submitted Pix-l-tron yesterday night.  The “low-level” tools used are C in MinGW and SDL2. The graphics suck.  I didn’t spend any time on them, so consider them placeholder graphics.

An advantage of using C and SDL over my usual tools of choice is performance.  So, i figured, I want this to be a game with massive amounts of objects. Since I was pleasantly surprised to see that my LD27 game (two minute mayhem) scored #144 on fun (3.5 stars), I took some ideas from that game and turned them into an arena shooter.

I wrote a minimalist game engine from scratch. The entire game is about 800 lines of code. It does most stuff you need for a basic game: bitmaps, sound, fonts, tiles, keyboard/mouse.  I figure this code may be useful for anyone who wants to make a game in SDL2, so I’m releasing it as open source (BSD).

You can find the game here:

http://www.ludumdare.com/compo/minild-45/?action=preview&uid=14520

The video quality of the gameplay video sucks, set it to HD to get a fair quality video.

I also “finished” my “game”. Or at least I don’t have time to work on it any longer for a while. It doesn’t have any real gameplay elements. But it is more than just a personal tech-demo. As I didn’t have the time to explain things in the game I will have to make a video. Everything in the “game” is different than normal. Especially the controls and the visual part. But it all has a reason. I was able to add saccadic supression and saccadic motor-control today but I don’t have more time now. I might elaborate on it some more in the future. I have some problems with the executables and dependencies so you can’t even try it right now. But here are some screenshots:

#gallery-1 { margin: auto; } #gallery-1 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-1 img { border: 2px solid #cfcfcf; } #gallery-1 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

 

Aware of the dangers of TL;DR, I constructed a handy pie chart to help do my explaining:

As you can see, I spent a lot of the time not working on Ludum Dare stuff (including various sicknesses and having a birthday). Most of the programming time actually comes from me switching to the Jam instead of the Compo.

And the results?

I did surprising well in innovation, and mood, weirdly. Overall I didn’t go amazingly, which I think was largely due to the lack of clear instructions on how to play.

Still, these results make me think that I should maybe spend a little bit of time actually finishing my game. Maybe.

Anyway, if you’re interested in playing a chaotic and difficult to understand game, then check it out!

 

 

Well, it’s been long overdue, but I am finally posting my reaction and conclusions from my first Ludum Dare competition in the Ludum Dare #27. I did recently also complete a submission for the 7DRTS, but it was nothing like this in terms of time restraints, so I consider it child’s play (pun intended; laugh at your leisure) compared to this competition.

To remind everyone, I created a game known as “Hot Dawg Dash” for the competition. The goal of the game is to eat as many hot dogs as you can in 10 seconds time (hence the theme). The game would record your 10 second record during the course of gameplay, which would allow you to know what score to beat in the next 10 seconds. Some strategy was involved in the course of gameplay, which involved not choking as much by drinking water (eating hot dogs is impossible if you can’t even breathe, which seems logical enough).

(If you want to chance to play it, go to http://www.kongregate.com/games/brgarnet17/hot-dawg-dash)

 

 

 

To the left are my ratings for the competition. I was pleasantly surprised by the humor and theme rating (especially since I did not even expect that high of a ranking in any area), but there is definitely room for improvement in the future.

The only thing that puzzled me about the ratings is my fun score. I thought it might be higher, but it may be a result of my mechanic being so short in duration (since 10 seconds is not a long time for the completion of a game).

Overall, I did some things in my design and process that I was really proud of, and other things that definitely need work. Without further adieu, the pros and cons .

 

 

 

Pros:

• Completed the game. This by far was the top goal of the competition. I had done other design projects before, but most of them I did not finish. I am glad to say that this was one of the exceptions to the rule.
• Fun game mechanic. The mechanic of the game, though simple, was driven by the fun I found in the idea of having a game centered around a hot dog eating contest. Not only that, but I did manage to add a little strategy in the gameplay as well, mainly through the use of the water.
• Small scope. The projects I did not finish in the past in other competitions or assignments was due to the problem of big scope in the design. For the sake of this competition, I decided early to have a small scope in relation to the actual experience I have had in accelerated game programming, while is small but growing at this point. This decision, in the end, made it possible for me to finish the project on time and entertain a few people along the way.

Cons:

• Little digital art experience. Though the gameplay was decently fun to be involved in, the art and animation of the game could have been more engaging and entertaining. This flaw in the design was due to my failure to find artistic direction and experience from either myself or anyone else. For the next jam, I probably need to find someone else to do the artistic side of the design process.
• Needed longer sprints. To pace myself, I would take programming and design sprints in order to remain fresh in those periods of time. Though this was good, the sprints during the design of this game were not long enough and the periods of time between these sprints became too long. Hopefully, this mistake will be avoided next time due to this experience.
• Short duration of mechanic. During the design process, I decided to do a 10 second sprint of eating hot dogs. This mode of play, though fun, is very short and proves to bore the player after a long period of time with only 10 seconds to create a record. I hope to create another mode of play that will prove to engage the player for longer periods of time.

Future Plans for the Game:

This game, though not the best in the competition, does have potential with a little bit of polish and added game elements. I will continue to develop on this game for two reasons: the game’s potential and my learning process (second reason is the main one). For the time being, I will polish up the Kongregate version of this game. In the future, I may use this game to create an Arduino arcade cabinet for the sake of learning more computer systems and gaming technology.

 

Thanks for all of your support, and congratulations to all who finished!

Hey folks!

Instead of taking the usual way and making a game using as3+Flixel and then uploading it to MochiMedia, I’ve been working for the past weeks on a remake of Loneliness (my first “real” game and LD) on C++ (using SDL for event handling and window managing and OpenGL for the rendering). I’ve already got most of the work done, there’s just audio, collision and the game itself to be done! (well, I’ve already got things spawning on the screen and to the player following the mouse)

Then I’m thinking about uploading it to http://itch.io/ (made by LD user leafo). Let’s see how this works out…

On a side note, my LD #27 post-compo version is currently on a “On Hold” state… I’ve already made some lots of tweaks, but the game itself is still lacking. So, after completing this remake I may (or may not…) go back to working on it. I actually want to finish this game, I really like how it came out. (check out the current version here, if keyboard fails, use the mouse to navigate menus)

Later!

I really want to do MiniLD #45. 

I set up Devkit Advance, and dug the internet for some tutorials. But, I haven’t even gotten started yet, and I presume I only have two more days. Oh well.

Also, I definitely intend to participate in the October thing, probably doing something for Windows Phone 7. It’s XNA, compatible with WP8, and WP7 dev doesn’t require Windows 8.