Singularity Update 3

Changelog:

• Atom parsing now works about as well as RSS
• Missing data files are now created, and missing configuration files now have their settings replaced with default values.
• Started working on an auto-delete feature, to remove old items

Sorry for the short (and late) post. I'm rather sick, so getting work done is difficult right now. Hopefully I can get back into the swing of things in a few days. That said, Singularity is almost ready for a 0.1 release, similar to what I did with AMAZE. I want to finish the auto-delete feature first, however. Right now, it isn't working too well.

Singularity Update 2

Changelog:

• Created the initial UI
• Feeds now update on startup. Note that there are two differences from the previous version: First, the updates don't freeze the UI anymore. The second major difference is that the feeds should no longer have to update in order, but instead update all at once. This should speed up the update process as well.
• Feed items can keep track of when they were downloaded, so that later I can have them be deleted once they've been around for a while.
• Added buttons to the UI for adding and deleting feeds. This was one of the biggest missing features from the old version, so I'm glad that it all works.
• Deleted feeds aren't fully expunged until the application exits, so that I can easily add an undo function later.
• Started initial work on Atom parsing

These past couple of weeks have been great for Singularity. For some reason or other, I feel really excited about the project and I've been super productive on it. At this rate, I can probably put out a public build by the end of next week. The main thing that I need to do at this point is testing. If I migrate all of my current subscriptions over to the database for the new version of Singularity, it'll probably be a pretty good measure of how well the application works. There are some crashes here and there, but most of the common bugs are gone, and I have the others sorted out somewhat. Now that college has started again, my productivity will probably take a hit, but I'm quite confident that I can finish this soon thanks to my current momentum.

Expect a minor release soon!

Finally, here's a screenshot of the work in progress UI:

Lots of placeholders still, but it's already a bit better than
how the old version looked.

DFEngine Update 6

Changelog:

• Started rewriting some of the collision handling code.

With the collision bug fixed, I started thinking about the way collisions are handled right now. The current system works well enough, but it definitely creates issues. For instance, balls in AMAZE would sometimes 'tunnel' through multiple blocks. This usually happened because the blocks were destroyed immediately, so the ball might not have bounced when the block disappeared. To fix this, I'm going to add two new collision callbacks:
The first is only called when two objects start colliding. In other words, it's only called when two objects first touch, and won't be called again until after they stop touching. Not only does this give me a way to respond to a collision only once, it also ought to make things run faster, since it isn't called every frame.
The other callback is for when the objects stop colliding. Just like its counterpart, it only gets called once. This one will most likely be reserved for special cases, like the problem that I described above.

Overall, I think these new callbacks will give me a much greater level of control over how collisions are handled by the engine, and also help make games use cleaner, more efficient scripts. One last improvement is that the new setup should be expandable. I may be able to keep track of other things with this system in the future, like collision velocity for instance.

Singularity Update 1

Surprise! I bet you didn't see that coming!
That's right, I never forgot about Singularity. Really, it would've been embarrassing if I had, since I use the thing several times a day. In it's current state, Singularity needs work. In fact, what it really needs is a massive overhaul, and that's what it's getting. As I've done in the past, I'm throwing out the old code and replacing it with something a little bit better. I'm still amazed at the difference a single year has made, first for DFEngine and now for this. I've already written almost all of the IO functions for handling web and database requests, and they work much better than their predecessors. One of the biggest issues with the old Singularity was how slow and unresponsive it was. This was because it handled web/database IO poorly, which caused it to lock up from waiting for things. Assuming the stuff I've done so far is correct (and my tests seem to show that it is), the new version should be silky smooth, with absolutely no interruptions.

Anyways, for the moment I'll be giving Singularity the same treatment on here as DFEngine, post-wise. With any luck, I ought to be able to actually release it (with the source code, of course) in the coming weeks.

One Game a Month, Month 1-2

Despite my initial excitement, things have not gone well. I've put together a very basic draft of what I want the gameplay to be like, but it's taken me way longer than I'd hoped. The main thing that's been slowing me down is the fact that I now have a number of projects running at once. seeing how things are going, I'll probably have to skip the next Ludum Dare again. In the end, I'm still very productive, but it's not as obvious since the work is so spread out.

Another issue that I've been having is with creativity. I have a cool mechanic here, but I'm having difficulty thinking of ways to make the gameplay interesting and varied. I'm trying to see if I can fix this, but I have yet to try out any of the solutions I've thought of. Whether or not I can make a decent game out of this will probably hinge on this issue.

Finally, I guess I'll leave a screenshot here:

As you can see, this is basically just a bare minimum
proof of concept. Still, it's already rather interesting.

DFEngine Update 5

Changelog:

• Added basic model loading
• The title for the game window can be accessed from scripts
• Possibly fixed that one bug where objects would hit each other without registering a collision
• Fixed a bug where objects wouldn't draw at the correct depth

Models

This was another light week for DFEngine updates. However, it feels like I've hit a small milestone. With model loading in, The engine is close to having 'true' support for 3d, not just as a technicality. Currently, models are imported using the OBJ format, which is a pretty awful format in my opinion. The one good thing about it is how easy it is to parse, which is why I chose it. Models can have built-in UV coordinates, so proper UV mapping is now supported. However, models can only have 1 texture right now, and there's no support for normals, materials, shading, per-vertex colors, bones, or anything else yet. In other words, even with such a great achievement I still have a long ways to go.

One Game a Month, Month 1-1

Time do something a little bit different.

If you haven't heard of One Game an Month, you can think of it as a never-ending chain of month long game jams. So far, I've held off from joining it for various reasons, but I think it's a good idea to start now. The biggest factor that changed my mind was DFEngine. Now that I have a working engine to build off of, pushing out one game every month doesn't seem so difficult anymore. It'll definitely help me expand my portfolio, and add some games with a little more polish than the 48 hour ones. On top of that, these short games can serve as a testbed for DFEngine, giving me a place to try out new features without tearing apart a long-running project.

Anyways, that's enough talk about motivation. You're probably itching to hear about the game. That's right, I already have an idea. This month's theme is Fire, and I'm happy to say that an idea immediately came to mind! A long time ago, I thought up of a puzzle game about setting things alight. The idea was to burn down everything in a level by placing a small number of fires. You'd have to manipulate objects and move stuff around in order to get the fires to spread, and once something burned down it would block fire from spreading. I'm sure someone's made a game like this before, but I've heard of it myself and it's an interesting concept. On top of that, this will force me to leave my comfort zone a bit and try something new with DFEngine.

I won't be able to start coding the game immediately, as there are still a few things that I need to add to DFEngine first, but the idea is there and it'll give me time to focus art, sound, and design. This gives me a chance to handle things differently, and I want to see how that affects the final game.

By the way, this doesn't change my decision to do the next Ludum Dare. It's going to be a busy month...

DFEngine Update 4

Changelog:

• Rewrote all of the drawing code. Yes, ALL of it.

The source code is now up on Github! You can check it out here.

The Rewrite

It was bound to happen eventually. There are many parts of this engine that could use some serious work, and with the source out on the web I need to make sure my code is in decent condition. I decided to start with rendering, for two reasons. The first reason is because I plan to add a bunch of new features related to rendering. While this rewrite doesn't add much on its own, it's provided me with most of the backend needed to add many new and exciting features, like finally being able to load textured 3d models. The other reason is that it make the code a bit more modern. Previously, I was using OpenGL 1.1, since it's what I learned initially. However, 1.1 is incredibly old(almost 20 years old at this point) and I there's basically no reason to use it nowadays. Now, DFEngine uses OpenGL 3.0, which is only 5 or 6 years old. That's still pretty bad, but I don't have much choice thanks to my hardware. Regardless, it's a big step in the right direction.