Quote:

Original post by KylotanI'm a firm believer in the maxim of only coding what you need to. You can plan for the future and develop libraries and components but you tend to end up only ever completing those libraries and components and never the products they're supposed to be used in. So I find it more fruitful to just code things as I go along and refactor them into libraries, components, modules, classes etc as necessary. One of my old university lecturers said to us, "it's not reusable until it's usable", which is quite wise. In other words, only code what you need; that guarantees that it's useful and is a candidate for re-use. As a result, I don't write engines. (Quick prototypes and the like excluded.) I write very basic game loops and factor out the subsystems as needed. I start off with a game and finish with a larger game, without ever just having a technology demo or engine.

Best advice I've recieved all month. Thanks

Edit - Geez, lots of insightful comments in this thread. *bookmarks it*

Whoa all the previous posts seem to be very conceptual and philosophical, haha *i'm lost*. I'll just stick to bland and straight-forward comments.

I'm sorry if I'm very traditional in my thinking, but I don't feel that hobbyist programmers should be afraid of the products that are available in the market. Some nice and successful (successful as in it achieves the main game objective: it's fun!) games out there that I have seen on the Internet need not implement complex programming. Even simple games like Acrophobia and ISketch (www.isketch.net) are fun and can be marketed widely through proper know-how.

Console games are also known for its simplicity. Even if Advance Wars did not have cute and bright graphics or even if Katamari Damashii didn't have a good soundtrack or proper blur effects or had limited objects to pick up, they would still be great games. It's all in the game mechanics and concept. Success need not be measured by sales: many people liked Gitaroo Man (where the game's 3d graphics played no role in the gameplay) and Vib-Ribbon (how's that for crappy graphics?!), but they were not even on the top-50 of best selling game charts.

Conclusion is, commercial games are getting better, widening the gap between the hobbyist and the professional, but do not forget your roots. Stay exactly the way you are. Don't follow others. Mainstream games are getting boring. The game market is getting more and more saturated with clones. There can only be so many world-war-based first-person shooters. Get your unique game out. Do not delay. Just sufficiently program to bring out the game concept, don't worry about all the eye candy so early in the game development. Most importantly, get a group of people of different skills, hobbyist composer, hobbyist storyteller, etc. Not only could they help in the actual production, they could also increase your confidence and bring the game's progress forward.

And that is all. Simple games, simple graphics and simple programming techniques need not be less interesting or fun. Remember that.

Quote:

Original post by ahbonk Conclusion is, commercial games are getting better, widening the gap between the hobbyist and the professional, but do not forget your roots. Stay exactly the way you are. Don't follow others. Mainstream games are getting boring.

I think this comment is important in highlighting the creativity side of the 'rift'. Most of my experience and frustration focussed on me trying to acheive a software engineering calibre parallel to that of the professional dev teams. I was striving for a software masterpiece without acknowledging the facts that a) I wasn't formally trained b) I didn't have the time and c) I probably didn't have the skill.

What you just mentioned was perhaps the way a lot of new starters think - after playing many games they already know that a game 'should' be an epic of cinematic proportions. I personally already knew I didn't have the skill to get the best graphics, sound, story or whatever else was needed to produce this masterpiece. I also didn't have the resources - I for one, cannot afford 3DS Max, Photoshop, Reason, etc - I barely cobbled enough together for VC++ .NET. Whilst I do have access to this sort of software once in a while (my friend is a web designer) I have to 'make do' with Milkshape 3D, Paintshop Pro and such like.

Quote:

Original post by ahbonk The game market is getting more and more saturated with clones. There can only be so many world-war-based first-person shooters.

I was having a private discussion with someone and we agreed that and whilst there are a lot of clones in the game market, the hobbyist community can potentially deliver more from the concepts that aren't even looked at by the professionals. Take my new project, for example. I've been working on a space invaders style game, but I've added something unique to it. I've built in the ability to script the entire game - as a result it'll be posisble to create a whole raft of 2d shooters from the same basic game. Whilst this is a simplistic example, I think it's important to highlight the things we could be doing but aren't because we're all trying to make Quake 10.

Quote:

Original post by ahbonk Get your unique game out. Do not delay. Just sufficiently program to bring out the game concept, don't worry about all the eye candy so early in the game development.

Whilst I agree with your statement, I have to point out that a lot of people are only tempted by games that look good. For my old Manta-X development site, the most hit page on there is the screenshot page. It's sad, but true. I showed a demo to a freind and rather than talk about the gameplay, they said "what about making the ship do this?". It was a purely graphical effect that didn't do anything for the game. As a result, I ended up with an impressive graphics tech demo but I lost sight of the game itself. That project has died 3 times now because of this.

Quote:

Original post by ahbonk Most importantly, get a group of people of different skills, hobbyist composer, hobbyist storyteller, etc. Not only could they help in the actual production, they could also increase your confidence and bring the game's progress forward.

This is a matter for personal opinion. I dislike working with others on my gaming projects, mainly because I find that the focus gets lost along the way. Perhaps I've not worked with the 'right' teams, but the ones I have worked with were 'amateur' in their outlook. What I mean by that is that there was no organisation to their work or methods. Hours were lost on trivial debates before any basic agreements could be made, eventually the team just disbanded with nothing to show for it except for a couple of splinter projects (which then failed). People are all too keen to start a team (I'm thinking the MMORPG crowds that advertise on here) but at the root, the have no idea about the game they wish to create.

I'd personally love to work with a team on a project that we all felt passionate about, but from my own experience there needs to be perhaps a greater sense organisation than in professional teams. Most hobby teams are internet-based which brings more difficulties than if they were all sat in the same office. If I could find a group of intelligent, professional and motivated hobby developers I'd jump at the chance - but for now, I'm alone and I think that probably a lot of people are like me in this respect.

Quote:

Original post by evolutional I think this comment is important in highlighting the creativity side of the 'rift'. Most of my experience and frustration focussed on me trying to acheive a software engineering calibre parallel to that of the professional dev teams. I was striving for a software masterpiece without acknowledging the facts that a) I wasn't formally trained b) I didn't have the time and c) I probably didn't have the skill.

Well if you're so worried about the skill, then either get someone who has the skills, beef up your skills or produce a lousy-looking demo, still showing the game concept, and encourage a publisher to fund you with the skills and the software. Or even better, create a game in 2D or whatever technology that don't require much skill to produce. That way, your game concept carries through, giving confidence to your team or your sponsor.

Quote:

Original post by evolutional Whilst I agree with your statement, I have to point out that a lot of people are only tempted by games that look good. For my old Manta-X development site, the most hit page on there is the screenshot page. It's sad, but true. I showed a demo to a freind and rather than talk about the gameplay, they said "what about making the ship do this?". It was a purely graphical effect that didn't do anything for the game. As a result, I ended up with an impressive graphics tech demo but I lost sight of the game itself. That project has died 3 times now because of this.

There is a reason why this happens. When I went over to your website, no offence but there was no game write-up. Even if there was, if there's no playable game demo, the point is the same: There are no other parts of the game to discuss about. I have the feeling that your friend didn't go through one whole level of your game, which limits his opinion on the game, leading him to talk about the eye candy. You can produce an impressive graphics tech demo initially, but swiftly come out with a game demo. Losing sight of the gameplay is equal to your game project committing suicide.

Quote:

Original post by evolutional This is a matter for personal opinion. I dislike working with others on my gaming projects, mainly because I find that the focus gets lost along the way. Perhaps I've not worked with the 'right' teams, but the ones I have worked with were 'amateur' in their outlook. What I mean by that is that there was no organisation to their work or methods. Hours were lost on trivial debates before any basic agreements could be made, eventually the team just disbanded with nothing to show for it except for a couple of splinter projects (which then failed). People are all too keen to start a team (I'm thinking the MMORPG crowds that advertise on here) but at the root, the have no idea about the game they wish to create.

Yeah I totally understand how you feel. I've gone through the same process as well. Some of them were lacking passion and enthusiasm. Some of them were just plain irresponsible. Ended up that everyone got disbanded.

However, I think working alone is just as bad as getting bad teammates. You may have control of everything, but you can't be good in everything. You will lose focus, concentrating on every aspect of your game project. This can discourage you and eventually your game project will come to a bitter end.

What I suggest is that you should stay patient and find the best teammates you could ever find. Let the game concept grow as you search further. Join communities, chat with experts and newbies alike. This can make your game sweeter inside out. Make a playable game demo if possible, so that the best are encouraged to join your team. Heck, you could even get funding for that demo.

Anyway I applaud you for your effort. Try again, or get a new game concept. All the best, dude!

Quote:

Original post by ahbonk When I went over to your website, no offence but there was no game write-up. Even if there was, if there's no playable game demo, the point is the same: There are no other parts of the game to discuss about. I have the feeling that your friend didn't go through one whole level of your game, which limits his opinion on the game, leading him to talk about the eye candy.

None taken, there used to be a whole load more information on the site but I've actually torn it all down when my project failed for the third time running. What I'm doing now is working on a smaller project which will then be 'launched' before moving onto my main Manta-X site again. I'm taking a more holistic approach and will launch it all as one when I have a small demo to play.

Quote:

Original post by ahbonk You can produce an impressive graphics tech demo initially, but swiftly come out with a game demo. Losing sight of the gameplay is equal to your game project committing suicide.

I couldn't agree more with the last point. This is especially important in the 'engine, engine, engine' mindset we all seem to be in these days. As Kylotan said:

Quote:

You can plan for the future and develop libraries and components but you tend to end up only ever completing those libraries and components and never the products they're supposed to be used in.

Which perfectly highlights the need to focus on what needs to be done for 'now' and not planning too heavily for the future of your game. As long as you make your components reusable, you're creating enough to make the basic game and then you can focus on the important (and often overlooked) component 'the game'!

Quote:

Original post by ahbonk You may have control of everything, but you can't be good in everything. You will lose focus, concentrating on every aspect of your game project. This can discourage you and eventually your game project will come to a bitter end.

I couldn't emphasise this point enough. My Manta-X project has failed three times now. Most people will have given up by now, perhaps I'm stupid. But yes, I'm thinking that once I'm out of a basic prototype stage, I'll be asking for help. Asking for help is important, yet it can be done totally prematurely. As I said before, many people have an idea and then ask for help right from the offset. The beauty about being a lone developer is that if you don't get distracted by the desire to create technology (do we really need pluggable renderers, for example?), you can really get your head down and create your game concept.

As I said, I feel as if I've woken up - I'm not out for the whole 'engine' development. I'm using a small project (jsInvaders) to bring me back to where it matters, the gameplay and to be honest, its working out for me.

The reason I started this thread was not to bitch and whine about not being able to complete a masterpiece, but it was about discussing how we see ourselves in the game development world - what things we feel pressure from as hobbyist developers and how we can actually stay on track and create our games. I think we've heard some really good views from people and as I said, I feel as if some of the comments have helped snap me out of the mindset I was in. I'm hoping that a few others are having similar experiences ;)

Quote:

I'm a firm believer in the maxim of only coding what you need to. You can plan for the future and develop libraries and components but you tend to end up only ever completing those libraries and components and never the products they're supposed to be used in. So I find it more fruitful to just code things as I go along and refactor them into libraries, components, modules, classes etc as necessary. One of my old university lecturers said to us, "it's not reusable until it's usable", which is quite wise. In other words, only code what you need; that guarantees that it's useful and is a candidate for re-use. As a result, I don't write engines. (Quick prototypes and the like excluded.) I write very basic game loops and factor out the subsystems as needed. I start off with a game and finish with a larger game, without ever just having a technology demo or engine.

It is actually possible (and quite feasible) to combine both the "only coding what you need to" approach and the "building an engine/framework/infrastructure" approach. The catch is that you can't combine them in the same system for the same project. It takes multiple projects, and the experience of those multiple projects, to allow this to happen effectively.

I'm perfectly content to call myself an "engine guy" at this point, and most of my day-to-day work involves creating the core components/services that the other engineers rely upon for doing the higher level logic for the game simulation, user interface, and so forth. When considered by itself, that kind of foundation appears as if it was created in a vacuum (as "technology for technology's sake", like many prospective engine writers tend to make). But when you look at these systems in the context of past projects I've worked on, you'd see that the vast majority of them are either:

A) things that I tried on a past project that worked really well,
B) things that started out differently on a past project but which gradually turned into this in the end (because it worked really well), or
C) things that i didn't do on a past project but by the end I really really wish I had because I had a concrete need for them but there was no time/room/whatever.

Basically what this means is that you should "only code what you need", but with an understanding that sometimes "what you need" should be part of your stable foundation, and it usually takes several projects to figure out exactly what should go where.

One thing is for certain: if you're doing an experiment (or any completely new system you don't have sufficient practical familiarity with), don't make it a core dependency like this. Keep that stuff as leaf code so that you keep the dependencies low and preserve your ability to iterate the system's design. The more you iterate, the more you see what the system should converge on and how it should be more appropriately arranged, and you can take advantage of those changes the next time around. These don't even have to be completed projects (although the more completed they are, the more complete your experience with them will be, of course). As a product of this experience, you will gradually get faster and faster at doing this kind of refactoring and reorganizing, and you'll get better at designing more robust and usable systems in the first place.

Keep fighting the good fight, and keep shooting for perfection. Just understand that perfection is a limit that you try and converge upon, and not a goal that you can actually achieve. Every project will have its failings in this regard; what matters is that you learn from those failings and reduce them the next time around. Don't kick yourself for making mistakes, because those mistakes may be some of the best lessons you'll ever have.

And BTW, if you're looking at getting into the industry, and you find that you're spending more of your time on core systems than gameplay code (preventing you from getting a game done)... that's fine! Just take that focus and combine with some people who do focus on gameplay code, and who are willing to use the core systems you create, for a better end result. That's what real teams do, after all. You don't necessarily need (or want) several different people all wanting to make the best wizbang graphics engine, or the best scripting system, or whatever... but if you can get people who want to handle different tasks (in different layers of the codebase), then you can start to work out dependencies between those tasks and what needs to get done when in order to keep everyone productive, and so forth. Those kinds of lessons and experiences are just as valuable as the programming experiences themselves, if not more so.

Oh, and evolutional: thanks for the compliment on COTC; I'm glad to hear some folks are still getting value out of it. :)

- Chris

Quote:

Original post by Chris Hargrove It is actually possible (and quite feasible) to combine both the "only coding what you need to" approach and the "building an engine/framework/infrastructure" approach. The catch is that you can't combine them in the same system for the same project. It takes multiple projects, and the experience of those multiple projects, to allow this to happen effectively.

I think I'm understanding this idea now, after 3 failed projects I've noticed that several systems remain pretty much unchanged and that it's the 'glue' code that is at fault. For me, it's realising that writing a generic glue code for my games is (so far) out of my scope.

Quote:

Original post by Chris Hargrove One thing is for certain: if you're doing an experiment (or any completely new system you don't have sufficient practical familiarity with), don't make it a core dependency like this. Keep that stuff as leaf code so that you keep the dependencies low and preserve your ability to iterate the system's design.

I think that this is an important point to raise, especially when you think that a lot of hobby programmers are aiming so high to begin with, we forget that it's taken years for companies and developers to accumulate their knowledge and evolve their technologies. As you said, developing the components that are needed and evolving them for the next project and the next. The Quake/Unreal engines are perfect examples of multi-generation codebases that have been created over time. With this raised watermark, it's pretty much impossible for hobby programmers to enter the market and create something of the same calibre. At least not whilst it's cutting edge.

Quote:

Original post by Chris Hargrove As a product of this experience, you will gradually get faster and faster at doing this kind of refactoring and reorganizing, and you'll get better at designing more robust and usable systems in the first place.

Agreed. I'm experiencing this in my own personal projects. I never see the Manta-X project as an outright 'failure', I've learned a lot on the way and have a small library of reusable code. This has helped me get to a higher stage in the next project at a much faster rate.

Quote:

Original post by Chris Hargrove Oh, and evolutional: thanks for the compliment on COTC; I'm glad to hear some folks are still getting value out of it. :)

Chris, reading your old COTC series over the past few months has really helped teach me some of the most valuable lessons I have learned in programming... It's you that should be thanked :)

There's no other industry in the world than the game industry to teach you that if you fall down, you can always stand up and walk again. Let's learn from our mistakes and improve the quality of the game industry! We're all responsible for the industry's well-being!

Cheers to you evolutional...

well i have a few things to say.
first, you all are right, we don't have to go after Carmack...but we have to take a look at his work. a game without the newest technology must have an extreme gameplay so players don't abandon it after a single hour of play.The technology is evolving, but if a hobby programmer tries to keep up to it, he/she will never finish his game engine. you must say: this is the platform i want to develop, this is the technolgy i want to implement and that's it. even if 10 video cards appear in 1 month after that, you must not try to reimplement the new technologies. so there are 2 ways to develop a good game engine: you are making it fast, the new technologies are not evolving to much and there you are, with an almost new technology compliant engine=very hard method, needs a very good team). the other way is simple(this is where software engeneering rules). u must spend a lot of time to design an engine, to be very modular, u implement a core that will be very independent of what you will plug in(can execute anything, best done by using a general purpose scripting language). then u must have a game design and implement(again very modulary) just what it takes to run that game. so then, on the next game you want to make, u have almost all the engine ready, that needs just some small technology update, by modifing or replacing some modules. that's why the design is very important. u must be able to replace a whole module, with a brand new technology inside, but not to have to modify anything to the core. execuse my bad english and good luck to all of our kind.

Evolutional,

This has become an interesting thread. I went to your site and read your journal and noticed this most recent entry:

Quote:

The other important thing I realised about jsInvaders is that it will be VERY useful for Manta-X development. Rather than just be a learning experience, it's likely that I'll be able to use the jsInvaders base code for at least prototyping Manta-X features. It is likely that rather than create a new engine, Manta-X may run from a heavily modified jsInvaders core. As of yet, I'm open to possibilities, but as jsInvaders becomes more powerful, it's looking likely that this may be the case.

Are you sure you're not slipping back into engine design here? Just suggesting you check yourself again and refocus on completing jsInvaders...sorry to butt in there.

Regards,
Jeff