One of the titles Blitz Arcade is working on has finally been announced - PowerUp Forever on XBox LIVE Arcade and PSN.
Published by Namco Bandi, it’s currently looking at an Autumn (Fall) release in 2008. Everything that has been announced is pretty much covered in the linked preview, so I won’t go over the same ground here.
It’s great to see it getting such a good reception, especially from the limited information that has been released, and everyone here is really happy with the previews and the various comments that have been written about it so far!
Here’s a couple of screen shots taken of the game that have already been released…
Whether you are a graduate or someone who is self taught, your demo portfolio is the key to getting your foot in the door of the games industry. As a junior applying for their first position it doesn’t matter if you graduated with honours from the best University in the country, without a good portfolio you will not even be considered for an interview let alone be offered a job. Unfortunately it’s one of those questions that gets asked again and again, with rarely the same answer given by two different people.
Recently I have been working through a University Module specifically designed to answer some of the questions often raised about demo portfolios (and hopefully to raise the standard of job applications) and thought it would be appropriate to post that information here so people who do not have access to these modules aren’t left at a disadvantage.
This topic will be broken up into three parts. The first will cover the content of a demo portfolio, the second will cover the presentation of this content (which can be just as important) and the final part will look at real portfolios to see what went right and what went wrong.
What Should Be In A Portfolio?
The first and most important element to decide on is what exactly needs to go into a portfolio. The main thing to remember is that this demo is meant to impress the person who will eventually offer you a job, so it needs to be your best work. There is no point including half-finished, broken pieces of work as it will do nothing to push you forward. You also need to think about how you want to be viewed. Are you interested in general game play programming or are you really interested in special effects, physics or one of the other many things people can now specialise in?
If you are interested in specific area’s then you need to include multiple demos’ to prove you’re not just a one trick pony. Physics for example could include technical demos that feature…
- Dynamic cloth
- Rigid body physics
- Deformation
It’s even better if these technology demos are elements of a game included in your portfolio, but that’s usually just a bonus and not usually a requirement.
If you are interested in general game play programming (and this is usually where most juniors start) then you can do nothing better than include a range of different but complete games, both 2D and 3D. What kind of games would be expected though is usually the hardest question to answer. One thing you need to understand is that, regardless of whether you have a degree or not, you are not expected to make something as playable as Halo or as good looking as Crysis.
From a recent quote on a popular Game Development forum
“In modern days you will basically not get through the door without a college degree unless your portfolio is truly astounding. (By astounding I mean you are able to do things that no one can do in realtime; or you have developed an entirely new technique for ).“
This is simply not true, your demo portfolio needs to be good, but even some of the best studio’s in the world won’t have technology that produces the kind of output that that statement alludes to.
Complete and Finished Work
So what kind of completed games would be expected for a standard junior entry level position? Try some of the following:
- Asteroids clone (full of special effects, explosions and particle effects)
- Simple 3D death match (AI bots, 3D character models etc.)
- Simple TBS Game (2D like Advance Wars or even 3D with the effects and environment to go with it)
Now obviously that is a very limited list, and you can make up any kind of game to go in a portfolio but hopefully that gives an example of what it expected. Well thought out, 2D and 3D titles showing a variety of different features (special effects, AI, terrain generation etc.). Go down this road and you are definitely on the right track.
The thing to note is that you do not need to have games that are huge and that take months to complete. People understand that you have a life outside your hobbies and that you like doing other things. And taking that further, chances are if you over-stretch, you simply won’t achieve what you want, meaning nothing will be finished and your portfolio will not be as good as if you concentrated on smaller, manageable demos.
Now it’s worth pointing out that in both cases, I stated that you needed a complete game. A complete game is just that, something that has the flow of a full game, from the menus to the game and back out again. Other things that you can include in a complete game would be
- Front End - Start new game, options, exit game etc.
- Loading Screens
- High Score Tables - People love these
- Pause Menus
Why is it better to have a set of complete games rather than just diving into the game when the reviewer boots it up? Simply put it shows you have an appreciation for what a game is and what else is needed other than ‘the fun’ part. This will stand you out as someone who knows what to expect and knows what goes into making a game from start to finish.
Graphics, Style and Good Looks
Another question asked is how good these games should look. If you read my previous post you are expected to be a programmer, nothing more. Programmer art is more than acceptable for demo portfolios. If you have friends who can help you out then all the better, but you will not be viewed in a negative light because you are not a fantastic modeller or pixel artist.
University Course Work
Graduates will also have work they did as part of their University program (yes, the content covered so far is generally assumed to have been done in your spare time), and there is every chance the quality of this is high and suitable for the portfolio. One thing I would recommend if adding this is to make a clear distinction between your course work and work you did off your own back. More on this in part 2, but it is worth noting that here.
Making Sure It All Works
So now you have an idea of what to include, there is still a lot more to do to make sure your portfolio is complete and ready to be put together. Your games and demos probably use a wide range of external libraries and API’s (DirectX, OpenAL and OpenGL to name a few). Unfortunately, your PC is probably the only one that has the right combination of installs to make your demos work. So it is vital that you include (or provide a link to) the relevant installers that will be needed. This will mean the reviewer has instant access to what is needed and can install things easily instead of rooting around for one missing library (at which point they may well just decline your application).
Right, so we should have everything we need now and everything is perfect, right? Wrong. Imagine what happens when the reviewer tries to run your demos and (even though you tested it on machine after machine) it fails to run. None of your demos do in fact. This is another reason a lot of applications get rejected. So how can you avoid this? The simple answer is that you can’t as chances are your game will crash on someone’s machine no matter how much testing you do, so the trick here is to make sure they still know what you can do even if they can’t run your work.
So for each demo and each game you need the following
- High quality screen shots of all major features of the portfolio
- Videos of each demo showing the good bits (nobody wants to sit through a video showing 2 minutes of menus!)
With those in your portfolio, you are pretty much guaranteed that the reviewer will have the chance to see and admire your work.
Source Code - A Window into A Programmers Mind
So, anything else? Just one more thing and this can be one of the most important parts of a good portfolio. You need to include the source to all the demos included in your portfolio, and it needs to be easily readable and accessible (this is where free copies of various .net IDE’s come in handy).
But why is the source code important when you have the most amazing demo’s ever seen? A lot of the time, the journey is more important than the destination. People like to see how you approached a problem, and how you worked around common dilemmas but most importantly that you write consistent and safe code. The source code will also open up another line of questions if you get to the interview stage which can help you shine even more.
You need to make sure that the source code is clean and suitable for other people to read. Take that to mean that any abusive or inappropriate comments and variable names need to be removed (though they should never exist in the first place), and it needs to be well structured and laid out. Best to do this from the start rather than the day before you build your portfolio, as you wouldn’t believe how easy that is to spot.
The source code also allows people to find out one of the most important aspects of any demo. What part of it is yours and what parts were done by someone else. This needs to be clear in the code (and in the portfolio itself) as you do not want to be seen as someone taking credit for someone else’s work - this will get you nowhere.
Say That Again?
So that’s it when it comes to content. To recap quickly what was mentioned
- A collection of small complete games and/or technology demos
- Include all the required installs for all demos
- Provide screen shots and videos of everything in case they don’t work
- Include the source code to everything
- Make sure elements carried out by other people are clearly noted
Now I know some people will be saying that this is going overboard, and not everyone will produce portfolios that have everything mentioned here. And they are correct, most people won’t. But the best people will, and it is these people that will get jobs in the games industry and it is the bar they set that everyone is judged against. It is these people you are competing against and it is these people that you need to stand out against, second best simply won’t do.
In the next part I will talk about the various ways in which you can present your portfolio so that your work can been seen and appreciated in the way you want it to be.
Following on from my previous post on the state of Education and Game Development (Are Universities Teaching The Wrong Things?), I wanted to look at what I see is the other main problem with most Game Degree courses… That you come out at the end with experience in game programming, design, animation, modelling and probably many others, but still don’t have the skills necessary to do one of them at a professional level.
To start, let’s get a few things straight. As a game programmer, I will not:
- Write the design document for our next title
- Create the models that are described in the design document
- Texture those models, or create the textures for someone else to use
- Animate the model for the various situations it will find itself in
- Create the music and sound effects that will populate the world
Take any other profession in the games industry, and the sentiment will be the same.
As a hobbyist, then this list is exactly what you would do, but people do not go to University to study for their hobby, they go to learn the skills necessary to follow the career they are interested in (well, most do anyway!).
So what is the problem with a course that covers all the various roles available to someone when they start out? Isn’t it good to have an appreciation for the roles your fellow team members are carrying out, and what about those who don’t yet know where their strengths lie?
The first point, an appreciation for your fellow workers is a valid point, but as a junior in the games industry, that appreciation will be thought of for you. The tasks you will be given to complete will have been thought out and will have all the facts already mapped out (or at least they should have been!). You will obviously still have a lot of work ahead of you, but you shouldn’t be making decisions that greatly affect other people on the team. As your experience grows and your responsibility increases, your appreciation for the work other people do will grow along side it, meaning you will have that knowledge through experience, not academia, which is worth a lot more.
As for the people who don’t really know where they want to go, then it’s a hard lesson to learn. Most people either lean towards an artistic temperament or in the totally opposite direction. There are those lucky few who have a talent for both, but for most people to excel in one area they have had a tendency for that since childhood. Most of the time it’s a clearer choice than they realise.
But why isn’t it enough to study the different disciplines, and why don’t students come out at the other end with the relevant skills? It’s all down to time spent working with the tools you intend to use when you graduate. Today’s games are deeper and more complex than ever before. They require a quality of in-game assets an order of magnitude larger than any previous generation. Unless a (lot) of time is spent honing those skills, then they simply will not be good enough when compared to another applicant who has, and at the end of the day that is where the competition for junior positions comes from.
Fortunately, there is a trend towards discipline specific degrees being provided, such as Computer Games Programming (BSc) and Computer Games Art (BA), which obviously focus more on the specifics rather than the whole, which is an excellent start. As these start to take on elements of the more traditional courses (Computer Science or Graphic Arts for example) they start to become the courses that will produce graduates that are perfect for the Games Industry and still attractive to the undergraduates looking to participate in them.
I was lucky enough to be invited to the Games Fleadh (pronounced Fla) ‘08 event being held in Thurles, Ireland on the 13th March. While there were other events being run at the same time at the festival, I was there as a member of the XNA Ireland judging panel, which was based around the 30th Anniversary of the original Space Invaders game by Taito.
As the event was primarily in conjunction with Microsoft the event was tied to XNA, with all entries being required to base their work on a given XNA Framework while being asked to expand on the original concept of Space Invaders. Many Universities from all over the country were in attendance, with 7 teams (of 1-3 people) up for the main prize and there were some excellent projects on show. The eventual winner, Finn Krewer, who is only 17 and worked on his own, managed to show a real passion for programming and game development, and I only hope that he eventually makes his way into the industry to take what is a real ability and develop it as far as it can go.
Now before I say anything else, I just want to cover what some people will already be thinking. With my previous posts in the suitability of XNA and University Courses, how can I being on an XNA judging panel be anything other than hypocrisy?
Unless you are involved in events like this, looking at work that is being produced by the students on Game Development courses, discussing the courses that are being taught and talking to the students about what they are learning, you simply cannot comment with any authority on the subject of games education. The competition was also open to Universities that do not teach XNA as a primary tool and the groups had to use this (possibly new to them) API in ways they may have not used it before. Whether this is XNA or any other development API, experiencing a situation like this can only benefit the students who are participating in the competition.
I was also excellent to hear some the new (or future) Game Development courses acknowledging and teaching C++ as their primary programming language. This can only benefit the Games Industry, and hopefully other courses will see how successful these Universities are and begin to follow suite.
It was an excellent event, and the people contributing and competing in the whole festival were obviously having a great time. The organisers did a great job of bringing so many people of different ages and interests together for a day dedicated to games and programming and hopefully sparked interest in the games industry that may not have been there before.
As with the Great Development Blogs post, this was originally started on Bruce On Games, with the view to spreading it to as many blogs and websites as possible… Enjoy!
Some of my personal favourites for anything Games Industry related…
- GameOn. Lots of information about what you need to get into the Games Industry
- Game Developer Magazine. A wealth of information on game development and even has a cheaper digital version and back catalogue
There is enough information there for even the keenest budding game industry professional. Please add any great industry sites you may know using comments. Bloggers and journalists feel free to copy this anywhere you want.
There was quite an interesting response to my previous post with some very fair and valid points being raised here and in forums across the Internet. Rather than try and respond to them individually (it might take a while!), I though it would be appropriate to list and discuss some of the more common points that were brought up.
Studios Prefer People Who Know How To Make Games
Something that was mentioned in numerous places stated that games studios should prefer graduates who know how to make games (and have tried various techniques that may or may not be used in games), or have a good awareness of the game development process.
Simple answer to that is no, it is not preferable to have a graduate who ‘knows how to makes games’ than someone who knows how to program and program well. If someone is a great engineer, has a excellent understanding of how languages work and how to use the tools available to them, then learning the ‘development’ process of a game is not going to be a massive undertaking. A few days in a functional studio will give them all the ideas they need to build on in that respect.
Besides, there is generally no process to making games. Every studio (sometimes every team) will have their own processes and ideas on what is the best way to develop their titles. What is taught in Universities may not be applicable in the studio you end up in, but you will be using a general set of tools and languages wherever you end up.
*Just a note regarding the last point - I am not at all against team based exercises on Games Courses, in fact I think they can be the most beneficial aspect of them. I just wanted to stress that it is not a replacement to learning the tools of the trade.
Is The Technology To Blame?
No, not at all. The fact is I have a great respect for XNA and C# , have seen some fantastic things come out of them, and use C# personally when developing tools to work alongside out tool chain. I totally agree with the point that was made, in that it is the responsibility of the University to point the students in the right direction, showing them the tools that they need to better understand the environment and technology they want to eventually working with.
The amount of support that is provided by C# and XNA means they are doing exactly what they were designed to do. Just in this case I don’t believe it is in the most appropriate environment for them to be used.
Games Are About Fun, Nothing More Nothing Less
This was also mentioned in a few places, in that game development and making games should be fun and about making them fun, not about boring programming practices.
Games are (or should be at least!) about fun, and developing them should be fun too. A programmer on my team may be a great game designer, and have some fantastic ideas which improve the title drastically. Unfortunately, no matter what area of the game they are working on (effects, character controls, graphics or animation for example) they will need to use the same skill set, just in different ways and with a different amount of practical knowledge. Just because people are working on the ‘fun’ aspect of the game doesn’t mean they don’t have a hard programming job in front of them.
If you will allow me to geek out for a minute…
Game Programming != Game Design
Engineering Principles Don’t Apply To Game Development
This point is worth a whole discussion on its own, and I’ll respect that by not going into to much detail here, but hopefully this should cover the basics.
This was mainly in response to that idea that understanding the basic principles leads you to have a better understanding of and awareness of Software Engineering principles. It’s not always true in the strictest sense, but having that backbone of education allows people to apply the ideas presented to them in an efficient and useful way. There is a reason that development principles have been a mainstay in the world of large scale application development and there is no reason why they don’t apply to game development either.
Hardware can be a nightmare to work with especially when you’re developing across multiple platforms each with their own quirks. Combine that with the sheer scale of game development projects today, and you have a recipe for disaster if you don’t plan for and use ideas that have a solid base and are understood by more people than just yourself. Engineering ideas and practices enable software to be structured and organised in a more efficient manner, allowing them to be better understood and maintained by multiple people, something which is getting more and more important every day. Without the education to back that up, graduates are simply not in a position to work with and develop games in a way they need to be developed.
Ever since their inception, there has been a lot of discussion regarding the viability of Game degrees, but instead of looking at them as a whole, I thought it would be interesting to look at various elements of them and discuss their relevance to the games industry and in producing graduates that are progressive and well rounded.
This idea for this thread came about due to the number of game degree and placement students I have had to review over the past few months, plus having been asked to look over a couple of degree course descriptions to feed back my impressions of them (luckily I didn’t have to do this alone!). I was also involved with carrying out practical interviews for a large number of students looking for placement or graduate work at the end of the year, and it was these experiences (plus many little things over the past few years) that made me think this was a necessary discussion.
The main thing that constantly stands out, in both currently taught and prospective modules is the fact that it is generally Java or C# that is taught as the primary language. And with XNA becoming more and more widespread (in both academia and the general indie scene), many courses see C# coupled with XNA as a valid combination for their principle tools. I think the reasons for this are pretty easy to spot, and unfortunately not so easy to change
- C# (and specifically XNA) allows people to get nice things on screen easily. This might only be a simple spinning teapot, but it’s a lot easier to do that in XNA than DirectX or OpenGL!
- By making it that much easier, people may see it as more fun, and the more fun they have the more likely they are to join the course and stay on the course
- More people on the course means the University is getting additional funding for both that course and research linked to the department (as this is one of the fundamental ways Universities are funded, there is nothing wrong with that in the slightest).
- People teach what they know, and a lot of Lecturers are experienced in Java and feel an affinity with C#. Being experienced in a language makes you a better teacher, so it makes sense to proceed with these languages.
Making these languages the language on which these students base the majority of their learning is, unfortunately, flawed, and that is becoming more and more obvious with every graduate that sends a CV my way (and it’s not always student’s game degrees).
Wherever you go you can always hear the phrase “A good programmer can program in any language” (easily taken from ‘Real programmers can write Fortran in any language’), but that claim is nearly always based on programmers who have been working with (especially compared to today’s tools) languages that are hard to use, hard to understand and most importantly hard to write well. I fully agree, a good programmer can (generally) program in any language, but it’s that disclaimer, a good programmer, which is where these courses fall over.
It all boils down to the sheer amount of support that tools like XNA give developers and how that stops people from learning what is really happening. XNA (and to a lesser extent C#) does a lot of things for you, and it does it under the hood, through calls to a few simple functions (lighting, animation and online spring to mind). A student might be able to knock together a pretty decent piece of work in a couple of weeks, but I would be surprised if the majority of the demo’s weren’t collections of calls to high level library functions, with the student at times fumbling around looking for the right package until they found something that worked. Unless they have thorough groundings in more low level languages (I am mainly talking C/C++ here but other languages are just as good), then they never really understand what is going on in the background, things like garbage collection, pointer arithmetic or true encapsulation and modularisation. They also manage to bypass some of the (possibly less glamorous) elements of game development and as a result struggle with things like basic vector maths, trigonometry and C fundamentals.
Without this basic foundation using languages that force you to do things the hard way, allowing you to make and learn from you mistakes, it is difficult (if not impossible) to take the skills and transfer them into different environment and different situations. This is, to put it simply, a core skill that is needed by every game developer currently in the industry. Unique hardware, new APIs, incomplete or incorrect compilers and multiple development environments are all problems that these skills allow you to navigate around making the developer an attractive proposition to any game company and an asset to any team.
This is a real shame, because due to their experience of using XNA, their demo’s might look pretty good and create an impressive demo reel which gives them (and an interviewer) an over-exaggerated impression of their skills and a real awakening when they find they don’t have the skills to do the job they want to do (the real shame here is that it is simply not their fault). Without a more realistic approach to basic programming skills on these courses, this will continue to be a problem as the distribution of these high level tools gets wider and deeper into academia and the indie scene in general.
So what should these students be using? C/C++? Well yes, that is pretty much an industry standard but concentrating on those would cause exactly the same problems. Try C/C++, try Lua, Prolog, Lisp, SML and a variety of scripting languages. Keep working with C# and XNA, but make sure the syllabus contains a variation on the skills, and then the students, if they really do have a desire to work in the games industry, can concentrate on the things they find interesting and become experts in the languages and areas of their choice as their experience grows, not as their tuition fees are paid.
This was started on Bruce On Games, suggesting a way in which readerships can be increased between blogs. Other blogs have picked up on it and I thought I may as well too ?
• Mainly About Games. Informative and well written it has a nice personal feel to it.
• Dopass.com. Short entries not just about gaming. Funny at times.
• A Path Through Possibility. Irregular updating but well worth a read for some incisive commentary.
• Japanmanship. An incredibly good read of a Western developer’s life in Japan.
• Magical Wasteland. Refreshingly irreverant.
• Survival Horror. Does what it says on the tin.
• Gamedev.net. A big and serious site with a lot of good content.
• Seven Degrees of Freedom. Very nice diary style blog.
• Random Encounters in Imaginary Realms. Just cherry picks the good stuff.
• Cheeky. Sparse and interesting development diary.
• Peter Mackay’s Projects and Development Diary. Quake on Gamecube.
• Life In The Rain. Often long interesting personal articles.
• T=Machine. Wide ranging blog with much that is happening at the sharp end online.
• Black Company Studios. Semi diary semi event driven articles. Nice.
• .mischief.mayhem.soap. A serious game developer’s blog.
• Bruce On Games. This guy is unbelievably prolific in posts. Mr. Marketing extraordinaire.
• Gamefeil. Games, comics, diary.
• Scientific Ninja. Technical stuff here.
• Devbump. Aggregation of gaming articles.
• Nimblebit. Game development diary. Lots of technical stuff.
• It’s Bezness Time. Bedroom developer diary.
• I Love It, I Feel Like Sisyphus. On start-ups, game development and programming.
For anyone with any interest in games the above blogs are just pure gold. Japanmanship, for instance is written by a game developer who works for a Japenese games company, lives in Japan and speaks Japanese. If you want to understand the game industry in Japan there is no finer source of knowledge. It amazes me when fanboys with a millionth of his knowledge and experience argue with him on forums.
And here’s a few more that I tend to read whenever new content is available.
• Power Of Two Games. Excellent information on the trials of a start up and ever present Agile Development methods.
• Engineering Game Development. Hey, if Bruce can pimp his own blog, so can I!
• Introversion. Still doing some amazing things and the technical posts are always interesting to read.
• Google Test Blog. Not game related, but it’s always interesting to see what this group comes up with next.
• Sutter’s Mill. The C++0x standard insights are a great look forward to what we’ll be working with in the future.
If you’re a student that is…
Microsoft have announced that they are going to offer VS 2008, Expression Studio, Server 2008 and XNA Game Studio 2.0 absolutely free if you can prove to them you are a student in a small set of countries – under the name of Microsoft DreamSpark.
Ignoring the fact that this is a blatant push by Microsoft to make sure the next generation of programmers are indoctrinated by there (in my opinion fantastic) tools, and that they are obviously trying to position Expression Studio as a direct alternative to Adobe’s powerful application suite, this can only be good news for all those companies that regularly work with Universities or have a past history of hiring graduates.
Whether you like it or not, Visual Studio is an industry standard when it comes to development IDE’s, and having a raft of students who are experienced in the nuances of the tool and the way it can be integrated with source control tools or network development for example can only help them fit into their role faster than before.
Of course it’s not without its problems, pushing XNA will cause issues for students especially if they start to rely on that as their primary development platforms, and I’m waiting for the day when I get demo after demo of Visual Studio 2008 projects and I have to rush around finding a copy as we’re still working with 2005.
For a bit more information on DreamSpark, have a read of this interview with Joe Wilson of Microsoft about the initiative.
Recently the topic of code size and its effect on the productivity and maintainability of a code base has been brought up in a number of forums and blogs across the internet. One of the more read would be the following (I won’t go into the issue I have with the author only ‘talking’ to young or inexperienced programmers) -
Codes Worst Enemy - Steve Yegge December 19th 2007
But what exactly is the problem that’s being brought up in these comments? Is it actually the size of the code base that seems to be the issue or is it everything else that has contributed to a problematic increase (a lot of the comments lead towards the difference between strong and weak type languages but a bit on that later)?
A Symptom Not A Problem?
Take for example the attack on design patterns (see ‘Design Patterns Are Not Features’)
A Factory isn’t a feature, nor is a Delegate nor a Proxy nor a Bridge. They “enable” features in a very loose sense, by providing nice boxes to hold the features in. But boxes and bags and shelves take space. And design patterns – at least most of the patterns in the “Gang of Four” book – make code bases get bigger.
When it comes down to it, every single feature of a language ‘enables’ a set of features, as do linked lists, rendering systems, input handling and anything else that comes to mind. But a correctly implemented pattern using these features is much more suitable for a large system than an individual solution that crams as much functionality into as small a space as possible. God help the person who then has to come in a fix this solution when the original author has moved on, where-as a simple comment of ‘This uses a proxy pattern to do…’ would make the code instantly more understandable to any half-decent programmer.
I wouldn’t have such a problem if the issue came from over-use of patterns that lead to a large increase of very small and distributed classes that spread out the functionality across the entire code base, but it seems as though this has come through ‘simple’ implementations, so the question that is begging to be asked is “what has happened to make it so big?”.
I really feel that the main problem being missed here is confusion between code bloat and duplication (and I don’t just mean simple copy and paste duplication but implementation duplication). Steve has mentioned this in his original post but seems to quickly skip past it.
However, copy-and-paste is far more insidious than most scarred industry programmers ever suspect. The core problem is duplication, and unfortunately there are patterns of duplication that cannot be eradicated from Java code.
Now I will admit that it has been a few years since I worked closely with Java, and I am sure someone of Steve’s experience with the language is not wrong, but there are problems with every language and solutions need to be found for the problems you encounter (not everyone is fortunate enough to be able to say “From now on, we are working with X”).
As an example take the FTL. On previous titles I’ve worked on, the mantra was if you needed something, then you implemented it. It didn’t matter if someone else had written a linked list, you needed something slightly different so you created what you needed (one of the first titles I ever worked on professionally actually had 3 different list classes used in throughout the project). But now we are moving forward and using the FTL to avoid this, the code base has been reduced, and it’s clear that it wasn’t the size of the code that was the problem, but the way in which the code base had been approached.
Language Choices
A lot of the discussion (as mentioned above) has come down heavily on the strong/weak language divide. I’m fortunate that while I work primarily with C++, I spend a good chunk of my time working with Ruby. And I will be the first to admit that my Ruby tools are written with less code than the equivalent would be with C++ (or more likely C#). But why?
The simplest offering is not that the language is weakly typed (I would personally say that has very little to do with it), but with the amazing level of support from externally developed libraries. I don’t have the code to hand, but recently I needed to create an FTP interface for a particular script I was working with. With Ruby, this was simply a case of requiring the relevant module and away we go? And if I was writing the tool in C#, if there was an equivalent library, it would have taken just as many lines of code. The only difference being that (in my opinion) the C# version would be easier to understand without running it than the Ruby one for a majority of developers.
An interesting quote from one of the developers of Bugzilla earlier this year
Since 1998 there have been many advances in programming languages. PHP has decent object-oriented features, python has many libraries and excellent syntax, Java has matured a lot, and Ruby is coming up in the world quickly. Nowadays, almost all of our competitors have one advantage: they are not written in Perl. They can actually develop features more quickly than we can…
Full article can be read here - The Problems of Perl: The Future Of Bugzilla
This accurately sums up the point I just made, that these newer language are easier to develop for (and indirectly decrease the code base) because of the number of modules and contributors they have developing for them. Without these (and it’s a shame Java and C++ don’t have such plug-able modules) the languages would be used to create programs that are just as big as any other language.
Conclusions?
Don’t get me wrong on any of this, a large code base is difficult to maintain and develop and care must always be taken not to overly bloat something when it isn’t necessary, but rather than look at a code base and say “This is big, before I move on I need to make it smaller to make my life easier”, you need to approach it from a different direction. Examine the complexity from all angles, and if trimming code makes it easier the read or work with, then go for it, but if refactoring it increases the size, but makes it more structured and maintainable, then that is just a valid as any other solution.
