Would like to relearn programming

[CaptainJei]

I find myself viewing the ChangeLog on a fairly regular basis, and I'm thinking I would like to get back into programming and maybe become proficient enough to help out on the ScummVM project. I have some limited background in programming--I've learned some C, Java, Pascal, and Basic; and I've also programmed incomplete games in Inform, AGS, and AGI--and I'm wondering what some of the more experienced programmers here would recommend that I concentrate on in view of eventually working on ScummVM?

[dreammaster]

I find myself viewing the ChangeLog on a fairly regular basis, and I'm thinking I would like to get back into programming and maybe become proficient enough to help out on the ScummVM project. I have some limited background in programming--I've learned some C, Java, Pascal, and Basic; and I've also programmed incomplete games in Inform, AGS, and AGI--and I'm wondering what some of the more experienced programmers here would recommend that I concentrate on in view of eventually working on ScummVM?

We'd certainly be pleased to welcome you to the fold of ScummVM developers if you're able to. As a developer who's been doing ScummVM development for several years, my thought is that there's two major areas to look into if you want to do some ScummVM development.

The first is learning how to develop using ScummVM itself. Part of this will require learning C++, but as long as you know C already, the learning curve for C++ won't be very high. With the exception of the occasional use of template classes, such as for lists, most ScummVM code tends, for example, to use classes mostly for code separation, and not much in the way of inheritance. So you're off to a good start already knowing C.

The other part of learning to develop using ScummVM is learning how to use the framework, such as the event manager and graphics surfaces. There's already some documentation in the Developer area of the ScummVM Wiki. Plus, you can look at how existing engines work to get events and do graphic output.

What may be most effective is to try creating a new engine to do a simple game. For example, drawing a small block on the screen that you can move around with the arrow keys. Doing something like that would give you a simple goal, whilst requiring you to learn how to get events, and draw things onto the screen. That's something I did originally.. I copied the detection code and game engine class from another game engine, set it up to detect a dummy text file (so I could register my new game in the game list), and had some basic input and output. I then moved onto more complicated things, actually starting to implement a full adventure game.

This is the second major area for ScummVM. Finding a game to work on. You have two options there: either work on enhancing the functionality of an existing game, or striking out on your own. The former is probably somewhat easier for someone new to ScummVM to try working on. Most of the game engines have TODO lists of functionality that is currently missing, or would be a 'nice to have'. You could always pick one of them, and submit a patch/pull request when finished.

As for working a completely new game, It's somewhat rarer for us to get given source code for games, like we were with Tony Tough. The majority of the games have been implemented by patient work with a disassembler. This will be the harder area for both you and other prospective develoeprs.. choosing a game, and getting familiar enough with using tools like IDA (free version), to figure out how the game works, so you can implement your own version of the game.

There an article on the Wiki about how to start off with disassembling a game, again in the Developer section. The biggest requirement, of course, will be time and patience, since, particularly when you're starting out, it may take a while to work your way through a game.

If you do decide to go ahead with it, remember that we're mostly a friendly bunch, and you're always welcome to hang out in the IRC channel to ask questions about the ScummVM code, disassembly, or help ensure you don't start working on a game someone else has already put work into.

[LordHoto]

What dreammaster described is actually just one part of the whole ScummVM development. Improving support for existing games/game engines is an important part, since it will improve the experience for our current user base and thus keep users interested in ScummVM. Adding support for new games is also a nice task, since it will attract new people to ScummVM, but is pretty much centered about the new games and their fanbases.

On the other hand there are two other parts of ScummVM development, both as important as the game engine development side. Sadly those seem to get a bit forgotten behind all the game support talk, at least that is my view from my history with ScummVM.

One of those parts is the backend side. ScummVM runs on a lot of platforms, for each platform there is a backend, which provides the frontends, i.e. GUI and game engines, functionality for audio output, graphics output, user input etc. Work here has a direct effect for users, may it be improved performance, better input handling or new graphics filters/modes or even a whole new port. There are backends, which could use someone to polish them again or fix bugs which prevent the backend from being supported in newer ScummVM versions (the PSP backend comes to mind here). There is a lot of things, which could be done here. If you have any ideas on your own you can submit patches for individual backends. On the other hand you can also talk to our porters to see if they have any tasks, which could be implemented (easily). Last but not least you can search through the bug tracker or the TODO lists on the wiki for things to work on.

The other, and probably usually forgotten side of ScummVM development, is the "glue" code. This code serves as a middleman between the backends and the frontends. This allows to simplify the backends, while providing the frontends easy solutions for common tasks. This for example includes APIs for digital audio playback, MIDI output, video codecs, graphics codecs etc. All those ease the life of the game developers. The reason why this is often forgotten is that for a user of ScummVM he usually doesn't have a direct view on improvements on this side. On the other hand without this code ScummVM wouldn't be what it is today. So it is also an important development area. But frankly it's one where you need a good amount of self motivation skills, since the feedback is rather small due to changes not being that easy to notice from the outside. There are also TODOs for that on our wiki, some developers also have ideas what could be improved here. The GUI code is actually "part" of the "glue" code, but unlike the other aspects of it, it has a bigger effect on end users. There's also a TODO list for that on our wiki and individual developers also have some ideas for tasks here.

For your initial question on what I would recommend you should do to get better at programming: Write code and don't be offended when people don't think it's good code. You improve along the way. Write some simple programs you always wanted to have, say a resource extraction utility, some graphics format conversion from your favorite game's format to a standard format like BMP/PNG/etc. This is actually still the best way of learning this: Just write code. Last but not least: If you don't enjoy the act of writing/improving code, I wouldn't recommend to work on improving projects. That might sound harsh, but in the end it's the better solution for all the parties involved.

[CaptainJei]

Thanks so much for the detailed replies! My primary interest is in improving support for games already supported and fixing bugs, but now that you mention it, I would love to work on the audio end of things since I have some experience with that.

I'd like to put a few months of practice and study in before I try to get actively involved. Thanks for all the good advice.