Archived

This topic is now archived and is closed to further replies.

evolutional

Rise and fall of the hobbyist game programmer

66 posts in this topic

Quote:
Original post by Al Gorithm
You say that people here on GameDev work with the latest tech? Can you give me some links/names?
Yann L. This guy is a god. Here is an overview of some of the threads he's contributed too.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Al Gorithm
You say that people here on GameDev work with the latest tech? Can you give me some links/names?

Most of what I've seen here is people modeling their engine after the latest id/Epic engine (eg. shaders, parallax mapping, dot3, shadow volumes, etc.) along with some fancy terrain stuff.


All of those features appeared in tech demos and hobbyist programs before they were included in a commercial 3d engine. Parallax mapping is the latest example; I first read about it in a thread here on gamedev referencing a research paper somewhere else... Then a month or two later it was implemented by various big name game developers (even then, e.g. unreal engine 3 won't be used in a shipping game until several years from now). Doom3 is the first id engine to use stencil shadows, and that's decidedly old tech by graphics enthusiast standards.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Al Gorithm
You say that people here on GameDev work with the latest tech? Can you give me some links/names?



*cough* Check my signature [wink]



I think a large part of the problem for the small-timers is exposure. There's a lot of great games out there which simply never get circulated, and so their potential is never fully realized. The Internet is a powerful tool for circulating and popularizing a good game, but I personally don't think that anyone has really truly mastered it yet. Perhaps once technology like micropayments becomes mainstream we'll have the infrastructure to distribute small-time games and make them actually profitable; this would also go a long way towards removing the dependence on publishers. Personally I've seen some absolutely incredible games ruined by the lack of exposure and by completely moronic constraints imposed by publishers. The catch for the hobbyist is that without a publisher one has very little chance of "supporting the habit" so to speak.

I'm sure someone will want to object here; the hobbyist is in it for a hobby, not a job, so what's the big deal about making money? This is a bit of a semantics issue but I think it merits investigation. First of all a lot of hobbyists dream about moving on to professional game development, as unrealistic as the dream may be. Secondly we're all human; of course getting paid for our hobbies is an attractive concept! I suspect that if there were a reliable and well-known channel through which small-time developers could release their creations and make money at it, there would be enough money to go around that people could live on selling games through that channel without needing a "real" job. This solves both issues, and also would provide the impetus for more newcomers to take up game development, which of course provides competition and encourages better development from everyone - win/win situation.

Now all we need is someone to back that kind of venture and keep it afloat.
0

Share this post


Link to post
Share on other sites
One of main stumbling blocks with hobbiest developers, is that they get into because of the coolness factor, they have a couple of ideas that they think are cool and want to make a game based on them. Because of this they also tend to loose interest in a project rather quickly after the coolness factor wears off.

As to the diffrence between hobbiest games and AAA retails games, the fact is that that gap is only going to get wider as time goes. Major developers have far more captial and resources to spend developing a game then any hobbiest ever will. Lets face it you can't compare a product made by a company with a multi million dollar budget and a team of 100 working fulltime to what one or two people working in their spare time can produce, and you shouldn't.

If anything if as a hobbiest you want to get yout game out to the public and have it played by large numbers of people, then you shouldn't bother trying to build an engine that uses the latest cutting edge technology. Instead focous on content, devote your efforts to making the game as enjoyable to play as possible and ask your self if you even need a fancy 3d engine. There is a great deal of untapped potiental for games that are driven soley by a crisp well designed windows based GUI.

Finally as hobbiest we really only have three paths to choose from,
1)Attempt to get entry level work at a game company.
2)Developer our own ideas and enter the independent market.
3)Remain hobbiest forever.

0

Share this post


Link to post
Share on other sites
I think one problem with hobbyists is they play too many AAA games and too little independent games. If you're half serious about making games you should play as many indie games as possible just to get to know what can be achieved with few resources.
0

Share this post


Link to post
Share on other sites
I'd actually argue that some indie games compare favorably to similar commercial titles, but they usually aren't first person shooters or real-time strategy games. For example, right now I'm totally addicted to Dominions 2. It's just more fun than the strategy games released by big companies recently (say, Civilization 3) and isn't any worse in the graphics/tech department either. It will probably be quite profitable to the two guys who made it.

So one of the things to think about is picking the right genre. Some types of games are simply more suitable for small teams and individual developers than others. Unfortunately too many people are only interested in making shooters or multiplayer RPG's or other resource-intensive games. I suppose it's because everybody wants to make games that they'd like to play themselves.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by ApochPiQ
I suspect that if there were a reliable and well-known channel through which small-time developers could release their creations and make money at it, there would be enough money to go around that people could live on selling games through that channel without needing a "real" job. This solves both issues, and also would provide the impetus for more newcomers to take up game development, which of course provides competition and encourages better development from everyone - win/win situation.

Now all we need is someone to back that kind of venture and keep it afloat.

Doesn't GarageGames provide all that? You don't have to be using their tools to have a game published by them.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by TechnoGoth
One of main stumbling blocks with hobbiest developers, is that they get into because of the coolness factor, they have a couple of ideas that they think are cool and want to make a game based on them. Because of this they also tend to loose interest in a project rather quickly after the coolness factor wears off.


I think that sums up the post by Kurt Miller, author of Strayfire. He says that the first 90% of creating the game is the most fun, the time that you add features and see the game evolve into something cool. The other 10% is actually 90% of the work as it involves tedious bug-fixing, testing and general tweaking to make things work.

To me, this always seems to be a problem I've had in the past - partially due to the fragmented nature of tutorials and such. If you take a look at my soon-to-be-renovated Manta-X website, you'll see that I spent a whole lot of time on what were quite frankly beautiful particle effects but what was the actual 'engine' of the game like to program on? Horrific. I simply had no clue about how to put a large project together. In fact I could argue that I did, but by trying to do things the way that the 'professionals' would I shot myself in the foot over and over.

Each day on Gamedev I see new starters talk about creating their 'engine' and sometimes it makes me feel geniunely sad. Sad because I know how devastating it is to find that the 'code entropy' (John Carmack) eventually wins. I think that instead of creating your engines (I'm effectively talking to myself in the third person here), you should be creating basic libraries that can be reused over and over. This is essentially the concept of the 'engine' but I think the sights get lost when we try and aim too high. A point of reference that may be useful is Chris Hargrove's Code on the Cob series. It's helping me kick myself back into shape by pointing out the flaws in my code design.

Whilst it is true that a lot of very very clever and talented people reside on these forums (Yann L has been mentioned), there will be a lot of people who come here with dreams. I'd hazard to guess that many of these people probably leave with their dreams in pieces because of the way their projects are designed. The step up from "I've created pong" to "I want to make Doom 4" doesn't seem that great when you have a few excellent tech demos under your belt. But 3 failed Manta-X games later and I can say that the step is very big and very real. What is needed to bridge this gap? Maybe more tutorials in game creation. Taking a game forward with small steps, understanding it completely.

I do feel liberated though. A phoenix from the ashes.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by evolutional
I think that instead of creating your engines (I'm effectively talking to myself in the third person here), you should be creating basic libraries that can be reused over and over. This is essentially the concept of the 'engine' but I think the sights get lost when we try and aim too high.


This is my (new) philosophy too. See CodeDread (my site).

Regards,
Jeff
0

Share this post


Link to post
Share on other sites
Goals set too high for one person with the limited amount of spare time that I have.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Diodor
high != expensive


I think I'm missing your point? Would you care to elaborate a little please? :D
0

Share this post


Link to post
Share on other sites
Quote:
Original post by evolutional
I think I'm missing your point? Would you care to elaborate a little please? :D


It's a higher goal to make a one-week game that sweeps the internet over (play Icy Tower to see what I mean) than to make a below average three years worth of time MMORPG. The former is a higher goal because it requires brilliance and it is much more unlikely to achieve than the latter.
0

Share this post


Link to post
Share on other sites
If you thought it was difficult being a hobbyist game programmer, please spare a thought for those poor people at Eidos, the makers of Tomb Raider, who have recently announce that they are just too small to be profitable in the game industry.

Here's a link to the article.

What a strange industry it is!
0

Share this post


Link to post
Share on other sites
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*
0

Share this post


Link to post
Share on other sites
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.


0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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!

0

Share this post


Link to post
Share on other sites
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 ;)
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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 :)
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites