Jump to content

  • Log In with Google      Sign In   
  • Create Account

Rise and fall of the hobbyist game programmer


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
66 replies to this topic

#41 Big Sassy   Members   -  Reputation: 310

Like
Likes
Like

Posted 29 June 2004 - 12:21 PM

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*

Sponsor:

#42 ahbonk   Members   -  Reputation: 122

Like
Likes
Like

Posted 29 June 2004 - 05:45 PM

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.




#43 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 29 June 2004 - 07:26 PM

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.

#44 ahbonk   Members   -  Reputation: 122

Like
Likes
Like

Posted 29 June 2004 - 08:01 PM

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!



#45 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 29 June 2004 - 08:19 PM

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 ;)


#46 Chris Hargrove   Members   -  Reputation: 256

Like
Likes
Like

Posted 29 June 2004 - 08:51 PM

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


#47 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 29 June 2004 - 10:15 PM

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 :)

#48 ahbonk   Members   -  Reputation: 122

Like
Likes
Like

Posted 29 June 2004 - 11:07 PM

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...

#49 meeshoo   Members   -  Reputation: 508

Like
Likes
Like

Posted 30 June 2004 - 12:18 AM

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.



#50 rypyr   Members   -  Reputation: 252

Like
Likes
Like

Posted 30 June 2004 - 01:30 AM

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

#51 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 30 June 2004 - 01:39 AM

Quote:
Original post by meeshoo
a game without the newest technology must have an extreme gameplay so players don't abandon it after a single hour of play.


As you say, we have a choice - be the best in technology or the best in gameplay. If this is the case then the hobbyist game programmer is on the way out, at least the lone gunners. There's no way we can focus on both elements and be successful, unless we are lucky and get a great team.

Quote:
Original post by meeshoo
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).


This is one thing I've learned from the COTC series and one thing that's resonating throughout this thread. We have to establish a core base of libraries that are generic enough to be used anywhere, but can be replaced without a headache.

Quote:
Original post by meeshoo
that's why the design is very important.


Does that mean that as hobbyists, one of our main failures is the failure to design our games? The holistic control we have can make us lazy and prone to shooting off at tangents on a whim. There's no schedules, to pressures, no formal guidance for us to follow in our game - we can do what we want, when we want. That's great for innovation, but often proves dangerous as the code entropy fights us.

Quote:
Original post by meeshoo
execuse my bad english

Your English is perfectly understandable :)

I'm thinking now that there are so many areas we have to cover and so many things we have to fight, I have to pose the question - where will the hobbyist programmer be in the next few years? Will it be feasible to create games that people want to play for more than an hour or will we have to forge teams and adopt a professional mindset in order to acheive our dreams?

#52 DrewCaliburClark   Members   -  Reputation: 392

Like
Likes
Like

Posted 01 July 2004 - 07:55 AM

I found this discussion very interesting. I would like to offer up my own game for a case study. There is a 90 second trailer of the game in action available on my website for you to look at and tell me what you think of both our production values, and our engine. The game was written "from scratch" in that we wrote our own engine, and I did all the art work. It is fully 3D, fully multiplayer with up to 16 players, and was made by 2 guys in thier spare time. We now have 4 guys involved, as I have found a musician and sound designer in the last 4 months. Please, tell me what you think and how you feel this fits in the this discussion.
www.reactorinteractive.net
_________________
Drew

#53 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 02 July 2004 - 10:20 PM

Quote:
Original post by rypyr
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.


You're not butting in ;)

Yes, the quote from the blog was correct. The difference here is that previously, I was trying to design a generic 'glove fit' engine that would encompass many generes of games.

The jsInvaders game is *very* focussed and small. It's *not* the software engineering feat I was attempting before. As such, the individual components of jsInvaders aren't portable between projects. But this is where it gets interesting. jsInvaders is totally scripted with the level content pulled from XML files. The game is toally tied into a very basic top-down shooter (textured 2d quads) and probably wouldn't stand up to being a 'real' game. The interesting thing I've found is that because it's scripted, I can very quickly modify the scripts and the textures used to create a different top-down shooter. As a result, I could probably use it to create my initial Manta-X protoetype. As I said, I could potentially develop jsInvaders further, but this remains to be seen.

I guess what I'm talking about here is creating a game with scripted features that has unintentionally alowed be to take things further and be used for something other than it's original purpose. Whereas previously, I was focussing on creating an 'engine' over a game and failed miserably. I wonder if this is how some projects work out?

Thanks for yout comments.

[EDIT]
I posted this in a PM to rypr - I think it gets my point across better :)

When I was creating the Manta-X game, I was very keen to create an engine - something that I could reuse over and over in many different game types. As a result, I was trying to cover as much ground as I could in what I thought would be the most professional way. Many things were abstracted out (probably needlessly) and I was trying to make things as generic as possible. Even with the overall Manta-X game in my mind, I still wasn't doing enough to focus my efforts towards that project. I was focussing on creatin a technology, not a game. I'm not sure why, perhaps I felt brainwashed by the community as a whole focussing their efforts towards engines.

So with jsInvaders I sat down with a very specific goal - to create a scriptable space invaders style game. As a result, I had a very focussed project and I was able to commit myself totally into it's development (it's about 60-70% done). Rather than spend weeks making the core engine with no real results to be seen, I was able to get the basic jsInvaders prototype up within a week an see the results. Something that took me by suprise, however was the fact that because the game is scriptable and uses XML to load it's data, I can very easily change a few files and make the game behave very differently. Space invaders becomes galaga, which becomes a different top-down shooter and so forth. Not exactly what I had in mind for my Manta-X game, but because of this I could make a quick prototype with hardly any additional effort. In essence, I have inadvertantly created an 'engine' (although very basic) from a focussed game idea.

In a couple of months, after jsInvaders is complete, I could potentially start Manta-X (again) from the core of jsI - allowing me to see results immediately. Or I could start again with the same idea, create a focussed game without the general idea to make it an engine.

As you say, it seems to contradict what I was saying, but I think the difference is that rather than focus my efforts on making a generic engine, I indavertantly created something I could use again by becoming very focussed in a new area. The difference was that I had a different mindset and adopted a totally different methodology.

As Chris Hargrove said, things improve over time - you eventually learn essentially by accident, taking things that were right and scrapping the things that were wrong. As a result, you get better. I think that's starting to happen with me.

[Edited by - evolutional on July 3, 2004 4:20:00 AM]

#54 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 02 July 2004 - 10:30 PM

Quote:
Original post by DrewCaliburClark
There is a 90 second trailer of the game in action available on my website for you to look at and tell me what you think of both our production values, and our engine.


and...

Quote:
Original post by DrewCaliburClark
The game was written "from scratch" in that we wrote our own engine, and I did all the art work.

We now have 4 guys involved, as I have found a musician and sound designer in the last 4 months.



Needless to say that yout game looks fantastic - the music seems very star-wars like though ;)

I think you could contribute well to this discussion - you mention having a team and creating yout own engine. Maybe you could offer up some information about how you went about designing your game?

Were you aiming from the start to get it published? Was it a hobby project that evolved into something bigger?

When creating yout engine, did you attempt to create a technology that could be used everywhere you could, or did you specifically design the features and capabilities for this game?

Taking into account the comments made by Chris Hargrove, what do you feel you've learned from this experience? How would you change it for next time? What would you keep the same?

Do you have any advice for us who needlessy overdesign our software and fall over so many times?

Thanks :)

#55 CGtech   Members   -  Reputation: 123

Like
Likes
Like

Posted 03 July 2004 - 11:15 AM

I just read the first post and honestly I just skipped over everything else, so forgive me if I am going off topic (or back on topic).

When I create a game I initially get a very basic storyline. Then I decide all of the interactions that are necessary to fulfill the initial concept. Usually by then I have countless crazy ideas, that are clearly set far above my reach. Luckily I have sleeping trouble so at night I just open up a new package of paper and work out how my concepts can be recreated using more realistic methods. I take the most crazy impossible ideas first and I work out how I can create them or alternate methods that create an almost identical outcome. I am proud to say that I have yet to have an idea that I was unable to simplify to my ability level.

I have knowledge in multiple languages, but at the rate that ideas come in to my mind I don't bother with 3d graphics or other time consuming benifits. I try as hard as I can to create all of my games in internet languages. This allows creating an entire game inteface to take very little time (with simple HTML and javascript). Although, my prefered language is perhaps a bit weak in the opinion of many others of all of the languages which I know of, javascript is my favorite. (I love it even more than C/C++)

I make my games for fun and it isn't only playing the game in the end that makes me enjoy it, but also the whole problem solving process (the problem being: How can the features that I'm aiming for be achieved in a realistic way using an extremely basic set of functions?) I get more pride in taking a complex and "impossible" 3d game idea and turning it into an easily doable project without losing the game's effect, than having a bunch of completed games at my fingertips.

#56 DrewCaliburClark   Members   -  Reputation: 392

Like
Likes
Like

Posted 05 July 2004 - 11:15 AM

Evolutional, I'd be happy to share any thing you'd like to know about our experience. Take a seat, its story time.
This project originally began when a group of about 5 guys approached me in college about making a videogame. They had heard that I was majoring in multimedia production and hoped to go into the game industry after college. I had some experience with game creation before getting to college, and it was key to this whole project, because of course, the game they planned to make was huge MMO-type perpetual universe where a player could go anywhere/do anything. The first thing I did after meeting them, was make it clear that I would not be involved in this type of project, since the odds of it ever reaching completion were nill. I felt, that the key to making games as a hobbyist, is to be honest with yourself and the scope of your project. I told them to drastically scale down thier vision to something that could actually be completed. So many people start out to make a game, and try to make something they can't realistically complete, which is a huge team-killer. Well, our project fell apart anyway as soon as I began to do some real project management (my major was production and project management, and now my day job is an IT project manager) because the other members saw that making a game is not all fun and good times, but it is hard hard work that takes real discipline and time management, mixed with a good dose of sacrifice. Well, one guy stayed with me, and I soon discovered he was a gifted programmer (HanSolo here on Gamedev). Once we saw the pace he could work at, we did expand our vision a little, to something we thought could actually pass as a decent demo of a publishable title. Our goal is absolutely to go mainstream and leave indy status behind. We are entered in several major contests, including this year's IGF, and have sought to leverage some corporate contacts that we had at Caligari and elsewhere. It has now been 3 years since my programmer and I got serious about this project, and hopefully soon we will see some fruits of our labor. We are very serious about making games, and have made countless sacrifices over the last 3 years to see this project get finished. Good scheduling and self-imposed deadlines have been the key. Once we had something worth showing off, getting a few more people on board to help finish this off was easy. Our musician from www.gamenoise.com is fantastic, and finding an additional programmer to take over some of the "grunt work" has been a welcome addition as well. So far, everyone has kept the milestone structure I've setup on schedule, and I've done my best to keep everyone clear and on-track with our vision. We have legal representation now to ensure the IP rights of everyone involved, and to ease any worry from team members over going very public with our demo and ideas. We have found several LAN party organizations to schedule beta-testing events around us, and thier feedback has been invaluable. By the end of this summer, we will go public with beta testing, and give the LivePitch contest a shot as well, to try and get in front of some real potential publishers, and get our feet wet in that aspect as well. There are so many aspects to this project that I have had to manage that many people take for granted. Its not enough to have a great idea, and even make a playable game around it. You have to have a vision that you believe in, can market with enthusiasm, and most important, be able to sell your dream to others and make them share your vision. Everyone has ideas and games they would love to make, so getting everyone involved to share the same vision and goals has been key. We'll see this fall what we can make of it. I hope this helps, and I hope its relevant to those who are frustrated by the difficulties of pulling an indy team together and getting them motivated to accomplish something more than themselves. sorry for the long post, but this is actually the short version. Ask anything you like, I'll do my best to answer,

#57 Ryan Buhr   Members   -  Reputation: 1010

Like
Likes
Like

Posted 05 July 2004 - 12:15 PM

Hi Evolutional,

To answer your questions about our engine:
This game engine is actually my first major programming project other than high school C++ type of work. I have always had an interest in programming, but even more so, I have always wanted to make games. This has been a learn-it-as-we-go experience for me, but in the end I am very proud of the engine I have created. It is very extensible, albiet in my own inexperienced way, and our core features (netplay, sound, music, input, graphics, etc) could service most any type of 3D game. We are lacking some features at this time, such as level geometry and shadows, though these will be added in the next 2 months. We have kept our schedules, and disciplined ourselves and have learned so much, and we owe it all to a driving desire to make the kind of games that we would love to play.
Most of our game's features come from our original vision: To make a fully multiplayer space combat game that would appeal to the First Person Shooter player. Keeping with this vision, we designed a twitch based space game, that would have depth, with ease of play and very little learning curve. We wanted this game to give FPS players a change of pace, while keeping what they love about deathmatch and team play shooters in tact. Looking at our project now, I feel we have kept our goals, and our schedules and the final product is something that fulfils that vision very well. We will be spending the next few months trying to take this vision to the industry.

[Edited by - HanSoL0 on July 5, 2004 7:15:15 PM]

Ryan Buhr

Technical Lead | Sector 13

Reactor Interactive, LLC

Facebook | Twitter


#58 evolutional   Moderators   -  Reputation: 1069

Like
Likes
Like

Posted 05 July 2004 - 11:17 PM

Thanks for your response guys.

I'm interested in this section of what Drew said:

Quote:
Original post by DrewCaliburClark
I felt, that the key to making games as a hobbyist, is to be honest with yourself and the scope of your project. I told them to drastically scale down thier vision to something that could actually be completed...

Well, our project fell apart anyway as soon as I began to do some real project management (my major was production and project management, and now my day job is an IT project manager) because the other members saw that making a game is not all fun and good times, but it is hard hard work that takes real discipline and time management, mixed with a good dose of sacrifice.


Quote:
Original post by HanSoL0
We have kept our schedules, and disciplined ourselves and have learned so much, and we owe it all to a driving desire to make the kind of games that we would love to play.


That seems to resonate with something I touched on before - I mentioned that being a hobbyist, you have full creative control over your project and as a result, you can often shoot off on a tangent and become lost. I did this with my 'engine' design instead of the game. But I think that it's starting to highlight the fact that now, even hobbyist game projects need managing. It was easy to plod along with creating yout game, but now we need to finely plan and manage the project in every capacity.

A major management decision (I've been involved in Project Management before, too) is to ensure that the project is correctly scoped out in terms of the requirements and the capabilities of the team. So I'm guessing that now, in this environment of bigger, flashier games, we need to take on more of a managerial role in our projects - even if it's just one person completing a relatively small project.

I sincerely wish you guys the best in this project, I like the way you're approaching things and it's certainly helped me think - as has most of this thread. I hope it's helping other people too.

#59 JohnSKX   Members   -  Reputation: 122

Like
Likes
Like

Posted 07 July 2004 - 08:03 AM

I don’t know if this is relevant to your discussion but here’s some of my thought to the case. I also have the problem of revising the engine over and over again. And one day, I came to realized that, it is not ‘game programming’ that I’m interested but I’m simply addicted to it. Literally. That is, I seem to be using ‘solving game programming problems’ as a drug to get high. To archive a short term happiness and excitement that many of us are looking for unconsciously. As in the feeling of winning gold medal after a long losing streak. I came to realize that I had the ‘feeling’ every time I solve a component that I set to archive for the engine. But as the drug addicts, the next dose will need to be much stronger for me to feel any change. So, after overcoming depression (side effect of a sudden happiness), I look at the big boys and say, I want that piece in my engine. So I set out for a painful and long straggle and research to accomplish the task. I like this ‘pain’ unconsciously because unconsciously, once I archive that ‘piece’, the high will be so much rewarding.

You see, speaking for myself, my theory is that some of us do game specific programming because it is the only programming industry that allows us to get the ‘fix’ once in the while. And, I came to realize it is not about releasing the game or making lots of money but just getting the reward after a long and painful seek. After that ‘awaking day’, I was sure that I’m a hobbyist and I would never release a complete game since I’m only seeking what I can’t achieve. That’s the only way I can get the fix.

I think to overcome the notion of hobbyist, you can’t think of game programming primary as an art but, as many implied, as a business. We must see it as a gold mine and just ‘take’. But many of us are not here to just ‘take’. I think that’s part of the problem.

(Btw, I’m not substance abuser. But if you think about it, we are all basically addicts addictive to ‘happiness’. And there are just many way to achieve it.)

[Edited by - JohnSKX on July 7, 2004 2:03:26 PM]

#60 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 14 July 2004 - 06:04 AM

Quote:
Original post by abstractworlds
Quote:
Original post by Run_The_Shadows
You work for years trying to learn what you need to know to get at the /start/ of creating enjoyable games, and by the time you have anything to show for it, you're another year or two behind the technology of the times.


This isn't always a bad thing. If your aim is to produce a downloadable game for the casual gamer then this should even be one of your design goals. Another design goal for this market is a quick download, which usually rules out too much fancy media in your game, so don't worry about your lack of FMV cut scenes, etc.

Casual gamers don't necessarily have the fastest PCs, the latest, fastest and largest memory graphics cards with the latest drivers, the latest versions of DirectX etc. Designing a game for your target market will hopefully mean that more people can enjoy your game, and you don't have to worry about being behind the times with the technology. Some would argue that downloadable games for casual gamers should be even more than 2 years behind the times in terms of the PCs they can run on. Some of your target market may have bought their family home PC 4-5 years ago, perhaps one that wasn't even a hot gaming machine when it was purchased new.

With this area of the market, the minute you start adding something fancy to your game (e.g. DX9 shaders), or start trying to imitate the best AAA retail games effects, you will either fail, or even if you succeed, you will then rule out a large percentage of your target market who dont have the PC specs to run your game anymore.

For downloadable games for casual gamers just remember that it is your intended audience of casual gamers that you are trying to impress, not necessarily the fellow developers here at gamedev.

Excuse my rant about downloadable games for casual gamers, but I do believe that this is one of most feasible game market sectors that hobbyist game programmers can aspire to. You make a simple game, set up a website, promote it on download sites, you get a good feeling knowing that people around the world are playing with your creation, if you're lucky you get some good feedback, if you're very lucky a few people might show their appreciation by purchasing your game. What more could you ask from a hobby?


test




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS