4 Hugues Ross Writes a Devlog: 01/01/2015 - 02/01/2015
Hugues Ross

1/29/15

Let's talk about engine architecture

In my last post, I might have said some thing about "getting back to making games". As you can clearly see, I've yet to do anything of the sort. In fact, I've now missed the Global Game Jam for the second year in a row, which was a tad disappointing. In fact, I couldn't blame you if you were to think "What gives, Hugues? What on earth are you doing?"

Now I could just say that I've been swamped with schoolwork, and I wouldn't be wrong, but that's not a very honest answer. In truth I am..... *drum roll* .....rewriting DFEngine. Yes, again.
I know what you're thinking, and I know rewrites aren't usually worth doing and waste lots of time and resources, but I think this one's a bit different from my usual follies. To explain why, though, I'll need to give a bit of background.

On the subject of Software Architecture

When designing software, most devs like to throw around the word architecture around a lot. But what is architecture, in the context of software development? The meaning is much closer to its origins than you might think. To sum it up neatly, software architecture refers to the general layout and structure of the code. This is a higher-level concept, meaning that it deals more with the overarching design rather than the specifics of each implementation. In other words, the architecture is the frame that any given program is built around.

If your architecture is bad, you might not necessarily notice or care at first. Your program will run fine, and it'll do what you want. However, the problems will begin to emerge as you try to expand and maintain your code. It's a little like building a house where the foundation and supports aren't well placed: Just because it doesn't immediately turn into a pile of toothpicks doesn't mean it's safe, as you'll realize when you start building an extension to it. If an application's architecture is well designed from start to finish, then fixing bugs and adding new features is much simpler.

There is a way to fix bad architecture, at least in theory. Through a process called refactoring, you can move around and rewrite smaller sections of code to match a new design without breaking existing features. It's still a difficult and time-consuming process, but it's generally way simpler than a full rewrite. However, refactoring is only at its most effective as a preventative measure, where you fix the problems before they become serious. The goal is to gradually make things run smoother, not turn the entire structure upside-down.

Back to DFEngine

As you might have already guessed, the current design of DFEngine was not well put together. It has some kind of structure, unlike the abomination that was AMAZE's original engine, but it's inherently flawed in several ways. To return to the house-building metaphor, AMAZE's engine is a pile of rotten planks and rusty nails that someone has arranged in a vaguely shelter-like fashion, and current DFEngine is a house that looks okay on the outside but secretly violates about 13 different safety regulations. You could go in and try to sort things out, but the problems are so deep-rooted that it may be cheaper just to demolish it and make a new one. I'm still at a point in DFEngine's development where I can afford to do that, so I think it's the wisest decision. After all, if the engine already has issues and it's not even finished yet, things will no doubt only get worse from here. On top of that, I had several game ideas floating around that required certain features that simply didn't exist in DFEngine, and wouldn't have fit with the existing structure of the code.

So far, things have been going fairly well. It's been a slow process, because I am loathe to make the same mistake twice in a row, but things are pretty solid so far. I would post some screenshots, but I haven't finished the rendering code yet so there won't be much to show for a few weeks.

Next time, I'll talk about the new engine and how it works.

1/9/15

Singularity Version 0.2 Released

 If you've been following this blog recently, then you'll know that I finished off the newest version of Singularity last week! If you're interested in messing around with it, you can download the source codefor the release here. That said, if you're just looking for a feed reader, then you should probably wait for the next release. This set of updates brings major stability improvements, and adds a number of 'must have' features, but still lacks some of the polish and smaller features that you'll find in other applications.

Now that I've got that out of the way, here's a quick rundown of what got added in this version:
  • Added support for downloadable attachments.
  • If there's room, multiple items can sit on the same row.
  • Additional work is no longer required to get Singularity running properly once it is installed.
  •  Added a 'Welcome Screen' that appears when your database is empty, prompting you to subscribe to some feeds.
  • Singularity can now periodically check your subscriptions for updates while running.
    • You can also manually tell Singularity to check for updates.
  • Added settings!
    • Also added a feed-specific settings pane to override application settings on certain feeds.
  • Replaced the automatic clearing with a more powerful rule-based system
    • e.g. "Delete read, unstarred items after 5 days",  "Star unread, unstarred items after 1 month", etc.
  • Improved how command-line arguments work, making them work like they do everywhere else.
    • Also added flags to display help and enable verbose output.
  •  Added a 'mark all as read' menu option.
  • Singularity now asks for confirmation before deleting feeds.
  • Added an 'about' dialog.
  • Moved the feed adding dialog to a pane.
    • This addition doesn't actually change or improve anything, but it'll allow me to add some nice stuff later down the line.
  • Items can now be starred/unstarred.
  •  Updated the update status emblems to be higher-res.
  • Fixed a ton of bugs, some of which were quite major.

So there you have it, 3 months of bug fixes and improvements. Now that the push for 0.2 is over with, I'm going to be taking a break from this project for the most part. I need to get back to making games, after all! Singularity will still be receiving occasional small fixes and improvements as necessary, of course, so it's possible that some smaller releases will be popping up from time to time.

Lastly, I should probably remind you that this is my last weekly post. As I explained here, the 'post once a week' model doesn't seem to be working out for me, and I think it's leading to worse content overall. This means that you probably won't be hearing from me as much here, but I plan on spending more time and effort writing each individual post. Hopefully, I'll eventually find a good balance. For now though, I must ask you please continue putting up with the constant changes.

1/5/15

Singularity Update 11


Changelog

-Moved the feed adding dialog to a pane. This doesn't do anything yet, but it'll let me do some nice things later.
-Feed content is packed together a bit better now.
-Blank authors/dummy dates don't show up anymore.
-Items can now be starred, and starred items can now be viewed.
-Singularity now actually downloads attachments when the attachment is clicked. (This uses, and thus requires, wget. I may look into an in-application solution at some point.) The old style(opening in a browser) can still be used, by changing a hidden setting in dconf.
-The default location for downloads can be changed in the settings.
-You can make Singularity ask for a location to download to, or have it download to the default location automatically.
-Added Feed-specific settings, which can override the application settings. Currently, these only affect downloads and rules.


Somehow, I managed to finish everything off of my todo list before the New Year. It wasn't easy, seeing how I didn't do any work last week because of Christmas. 0.2 isn't quite ready for release yet, however. There are a few things that I want to test/improve still, but I think I can safely make a release within a week or two. When that happens, I'll give a rundown of all the new features, just like last time. The main new features here are things that are generally boring but required, and a few major bug fixes. This means that Singularity now has most of the necessary features for it to work nicely, but is still largely unpolished. Hopefully, 0.3 and 0.4 will feature more polishing and 'quality of life' improvements.

Anyways, it'll probably be a while before I start working seriously on Singularity again. It's been far too long since I worked on games, and I have some fun stuff coming up that I can tell you about soon. Maybe I'll even get back to my tutorial soon!