Rise and fall of the hobbyist game programmer

Started by
65 comments, last by evolutional 19 years, 9 months ago
I was reading this ancient article on Loonygames and it got me thinking about how things have changed so much since I started programming.
quote: Professional game programming and hobbyist game programming have become widely separated. And yet people don''t seem to realize this, or they seem unwilling to acknowledge it. The bitter battles on Usenet about the importance of C++ and other hot topics: those are the concerns of people who have to follow the accepted standards for professional programming in team environments. They have different concerns than the after-hours game designer. Some hobbyists don''t want to admit they are hobbyists, they try to follow the professionals, and they are never heard from again. Oh, they''ll write part of a hot 3D engine and get all the "in" opinions, but except in very rare cases you never see their name on a finished game. And that''s too bad, because when you''re working on your own you can be creative and different and do things according to your own vision. That''s the only reason for being a hobbyist in the first place.
This section of the article got me thinking about how we design our games these days. When I first started designing Manta-X, it started with a simple concept to which I added more and more complexity until the project eventually lost focus and crashed into a heap of ill-designed technology demos. Now, I''m designing an engine to base my games on. It''s not hugley complex but it''s still several abstractions above the ''core'' of how I used to create my games on the Amiga. But my point is that I seem to be more and more focussed on the technology behind the game, the engine powering it all rather than the simple aspects of the game itself. But beyond and because of that, the expectations of what I can achieve on my own in my spare time seems to be far outweighed with what is actually achievable. I''m thinking that because my engine is able to achieve certain things, then my game ideas should grow to accomodate this. It seems that I am aiming too high and invariably getting lost by trying to achieve a professional type game; forgetting my ''roots'' as a hobbyist as if it''s something to be ashamed of. It''s obvious that many people joining GDN these days are guilty of such things, wanting to create The Next Big Thing (tm) and failing after they realise it''s out of hand. My question, or thinking point for you to discuss is simple - when designing your own games, do you design the game based on what you know you can achieve or do you ''aim too high'' and try to achieve what a team of professionals can only accomplish? How do you bridge that gap when designing your games? Surely it''s boring to churn out PacMan 2004 for the 90th time, but it''s obvious that it''s unacheivable to recreate Doom III from scratch. So how do you set your goals? Are they a moving target? Does the game evolve, remaining playable as a ''complete'' game in it''s own right, but evolving in features and size/complexity as the months and years pass?
Advertisement
It depends on what you mean by game design, really. If you''re talking about the Ernest Adams sense (link requires login), then core design is a simple, repeatable process, and the problem of scope is limited just by growing a design only in those directions that offer maximum gain for minimum effort. That''s true of both professional and hobby game development. If you mean in a total-scope sense, then in my experience you need at least one "big idea" to continue to hunger for the art, but in the meantime you still have to recognize that you are in fact limited in very significant ways as to the things you can achieve.

ld
No Excuses
I was talking about the holistic view of the entire game; both gameplay and technical design. I''m just interested how people who have completed one or more games (on their own or with one/two more people) managed to balance the fact that the world is now expecting more from games before they''ve started; placing ''professional'' expectations on the hobbyist programmer.

For example, I''m looking to create a game that in itself isn''t the next Doom III or doesn''t have SuperGFXCardFeatureX10 (tm) - will people still play it for it''s simplicity? Or will they drop it and move on because it''s not eye-candy? When planning the game, should I plan for The Next Big Thing (tm) or take it as it is - a small game from a hobbyist programmer.
The games market is a big area which can be broken down in many ways, e.g.:
AAA Retail titles multiplatform (Xbox,PS2,Nintendo,PC)
Other Retail titles (perhaps less platforms)
Retail Budget titles (single platform e.g. PC)
Downloadable games (shareware,freeware,etc, e.g. PC)
Games in web pages (flash,director,java)
Mobile games
etc
This is just one way of breaking it down and is by no means a definitive list.

Each market sector has different customer expectations, different types of customer (ranging from casual and non-gamers to hardcore gamers), and different typical hardware setups (e.g. casual gamers might not have very good graphics cards on their typical home PCs).

As a hobbyist you''ve really got to decide which market sector you want to be in, and then compare your work with other games in this sector. This will give you a sense of what is achievable and hopefully you wont get too depressed that your game doesn''t compare well with the fancy features of a AAA retail bestseller. Once you''ve decided on the right market sector you may be pleasantly surprised to find that your game is rather good compared to other games in that market sector.

As for finishing a game, my advice would be to keep it simple, and prioritise so that you do the important stuff first to get the game out. (Judging by the early screenshots on your website it looks like you''ve spent time early on with fancy particle effects, perhaps these could have come later, after more of the game was complete).
Solution: more/easier to use developer kits. I''ve seen some very nice one-man Total Conversion projects done with the Unreal 2k4 engine. The hobbyist gamedev is not dead - only the "from scratch" gamedev, and really, that wasn''t from scratch unless you were coding in machine language (you''re always using somebody''s platform - even if its just a compiler).
-- Single player is masturbation.
Quote:Original post by abstractworlds
As for finishing a game, my advice would be to keep it simple, and prioritise so that you do the important stuff first to get the game out. (Judging by the early screenshots on your website it looks like you''ve spent time early on with fancy particle effects, perhaps these could have come later, after more of the game was complete).


Yup, you were correct. Those screens are from the old game. I've started from scratch again and this time the core systems are better, more stable and more importantly - it's quicker to write new ones and implement them into the engine. Mainly because I've taken a totally modular approach based on a small kernel. It's working well so far and is more of an SDK library than an 'engine'.

I have to agree with you that finding your 'place' in the market is important. I have no plans to move mainstream - I'm more than happy being a hobbyist programmer in the downloadable games category. But I think before, the approach to programming my games was too rigid and based in the 'big boys league' of thinking. It's far too easy to be swayed by how the pros do it and how the community hobbyist guys do it.
I think it has a lot to do with wanting to build something worthy of calling "software engineering". That is, some code that is reusable, extensible, powerful rather than something that can "get the job done".

Thanks to my personal and professional life, I no longer have a lot of time to spend in one sitting on hobby programming. As a result, I've made sure that my goals are sufficiently low and that I'm aiming at targets I know I can achieve. At this time, I'm not worried about solving the "engine" picture.

My website shows some results. They may not be visually impressive, but it's something I enjoy and I think it will help me in the long run anyway.

Regards,
Jeff
I think that's how I'm thinking now. I had the view that I'd be able to create a stable base to knock out games by covering all angles. Essentially creating the 'engine' because that's the way the hype was all going. Reading the article I linked in my original post really helped to open my eyes. Mainly because I think I was trying to convince myself that I wasn't a hobbyist. For what reasons, I'm unsure - mainly because all we see these days are how good everything looks, etc. It's not a small thing how the most often viewed page on my small (soon to be replaced) website is the screenshots page.

Ironically, setting myself up a small basecode has allowed me to achieve results a lot quicker. The facilities are there for me if I want to use them, but I'm not constrained by my own architecture anymore. I'm a programmer, not an engineer ;)
The initial quote misses a crucial point; a lot of hobbyist game developers want to be professional game developers one day. Therefore they feel compelled to do things the way that the professionals do, in order to have enough transferable skills to get them into the industry. I often feel that I could write great games in a simpler programming language like Python, but if I wanted to get hired to develop games that might not help me. So if I've got an eye on the industry then yes, I'm thinking about developing technology. If I've got an eye on personal satisfaction then I'm thinking about the game and how best to leverage other people's technology in the making of it.
However, there's engineering and then there's over-engineering. If you're constantly working on the infrastructure and never actually building a final product it will reflect on your ability to commit to an idea and follow it through to the bitter/better end.

I think folks in the biz are really looking for that ability in someone. My "proof" of that is look how many people are trying to build an engine (i.e. "anyone" can do it - assemble some classes to handle resource management, a renderer, an audio manager, etc). Not everyone actually follows through and ends up with a finished product.

Just my two cents...

Regards,
Jeff

This topic is closed to new replies.

Advertisement