PDA

View Full Version : Let's make a game on the fly, no docs, who needs those neway



BojZ
19-02-2003, 12:21 PM
Making games can be hard or easy, fast or enslaving, depends on what you're trying to make...

But as a free-time game developer I suggest you make a plan of your game first. And then get people to help you do it.

Start making your game documentation. Write in it everything you want your units/menus/bullets/background/whatever_you_choose to be able to do. Then write down all states and co-relations between these objects. Then, when you're finished writing the document (3-X months later) start making the game by getting at least 2 more enthusiasts to help you along.

My experience as BojZGames programmer
--------------------------------------------------
SpacePirates Chapter 0 : Revange (current project)

I told my friends that it would be about time for us to make a game, something easy, a space shooter. I wrote the "stuff" that would be in the game on a sheet of paper in 15 min not knowing what a game plan really is. It was October 2002, I think.

So we decided to make it, everyone got his/her part in the development process, I am the programmer, Crt is making the 3d gfx for rendering, Dex is drawing the GUI, Uzo and DejZ made the music. We also have one more programmer, who is currently learning C# and DirectX, he's not actively working on this project.

I took us about,.. well it's almost 5 months so far but the game is still not finished.

I could be, though, if we made a REAL PLAN in the first place. But nooooo, why should we, we're super-brainiacs,heroes,fill-in-the-gap. We don't need paper, we need code and 1s and 0s!

We'll just get the ideas and "rules" along the way. And we did. And we rewrote/fixed the code about a zbilionity times so far. What happened was that the code wasn't prepared for all those neat little add-ons that we decided to pack into our game.

And at the n-th code rewrite I've decided to arrange meetings for the whole team to gather on a weekly basis and discuss the progress of the game. It helps. A lot. We're patching the "game plan" at those meetings. Everyone "reports" their progress and we so far managed to stay afloat. It doesn't look our ship is sinking, and I think it's the meetings that got us here.

The team still has what it takes to make a game from the beginning to the end. The goal of our first game is to finish it and to learn how to evaluate everyone's capabilities, as an individual and as a team member.

The next game we're making will be an isometric Commandos-scroller game. Anyone had a C64? :D

What I see as "profit" that you get from spending time on the plan is the team coordination, everyone know what needs to be done on their part.

If we knew what enemies and items will be in the game, Crt would be able to draw all the gfx regardless of my programming progress. The same goes for music and so on...

So DO make a plan before you plunge yourself into programming the game. I know WE will. =)

The result of our work so far can be found at
http://redpoint.no-ip.com/bojzgames
(the page is NOT updated, but the game files are)

Direct download link is
http://redpoint.no-ip.com/bojzgames/spacepirates/files/spacepirates0.zip

I hope it works on you computer... =)

Karaman
19-02-2003, 05:16 PM
Plans are very good thing, especially if one does not want one's brain to explode 8) 8)

I never make plans, I just follow my ideas. If I make a plan it collapses :)

BojZ
26-02-2003, 12:13 PM
Plans are very good thing, especially if one does not want one's brain to explode 8) 8)

I never make plans, I just follow my ideas. If I make a plan it collapses :)

Yup, planning is an art, allright, one only learns it with experience, really. =)

P.S. My plans collapse, too. The one for this game did, as we keep on adding stuff to the game on the fly in a "caotic way", but it will get better with the next project(, and the one after that,...:roll: )

Alimonster
26-02-2003, 10:58 PM
It's ramble time!

Hmm. The complete design process is very long (at least, if you do it the "proper" way for general software). Here's a doc I wrote a while ago for someone else (some bits may be missing because it was done from memory): http://www.alistairkeys.co.uk/design_process.htm.

If you follow the design process carefully, it's possible to get very good results. In particular, the requirements spec, the candidate class list, the class diagram and the state transition diagram can result in some pretty unexpected, but good, design decisions.

Of course, it takes a lot of discipline to see through the "proper" way. I've had a couple of good results so far (for a Monopoly game written in VC++ 6/MFC --spit spit spit!, and for a 3d game in Java3D).

I'm of the opinion just now, though, that a lot of the stages are reasonably generic and can be re-used through different projects. Many of the candidate class list items were pretty repeatable for various projects (e.g. "screen", "image", "file", "input", and so on, crop up all the time). I think that it's probably possible to create a reasonably generic framework, and to use that through most projects. If you use the state design pattern then a lot of the state transition diagram becomes generic - you'll end up with roughly the same flow through your system game-to-game (e.g. intro->main-menu branching off to demo, high score table, story, options, etc).

In other words, at the moment I'm doing bottom-up "design" (writing any code that comes to mind as handy :roll:) and slowly forming it into a generic game framework. This is pretty satisfying, although it's definitely not the most productive thing in the world. Nonetheless... sometimes you need to do the monkey work to appreciate the design stages ;).

I heard some good advice a few days ago somewhere: aim to do a very small game that will take you a week. You'll probably get it finished in a few months, but you *will* end up finishing it. I'm not sure how long Traveller's balloon popping game took, but look at what's happening now: he has a product at the end, and has been getting a lot of feedback. This seems like a good approach -- it's much simper to embelish a simple game from user feedback than to fit it all in at the start. Once it gets too large and messy, just finish it and start on version 2.0 :).

I've tried the proper design stages before and had a couple of reasonably good results. Now, it's time to convert *everything* and see what pops out at the end! :) In defence of this, it is a recognised design pattern (http://www.laputan.org/mud/mud.html) :P.

However, using the proper design process does *not necessarily* guarantee a proper solution. For my Honours project (the Java3D crap) I did some design, then piled in to the coding (since I neglected it for all but the last two weeks of the allowed time :). I put in over 48 hours without sleep in the last few days). I retrospectively wrote up some of the UML, "hacking" the candidate class to get the desired classes popping out the other side for the class diagram (and stripping out approximately 19 pages worth of functional requirements from the rqeuirements spec). It turns out that my initial thoughts on the system were pretty much a good fit with the "design process recommended" stuff - I had an idea of the wanted design, implemented it, and when I went back, I found no major surprises from doing it the proper way. This argues for or against doing the design process; I do keep in mind that my other project (a team project doing Monopoly) resulted in some "interesting" design decisions that would almost certainly not have been made, and I do think that it helped.

I remain utterly unconvinced about the worth of Use Cases, though. They're handy for acceptance testing, but as a part of the process by themselves... they simply lack any relevance whatsoever, IMHO.

The big question in my mind: does the design process produce good results in and of itself? I think that it doesn't really; I think that it's simply a product of having a formalised system that lets many people look on a set of ideas. It provides a system that can focus a team's attention, and I think that it's simply the prolonged discussion that is the major benefit. Hmm.

About your game BojZ: I tried to download it but there was a server error. I'll try some time later on.

TSmithwick
14-03-2003, 12:12 AM
Oh, Alimonster - what a reference! Big ball of mud indeed! I can only admire a scholarly article that includes a Dilbert cartoon!
I saw a suggested methodology once that was quite similar, in reference to writing an article (or novel, etc.). Long lost the reference.

1) Write an intro that describes what you will write.
2) Throw this intro away. Wait a minimum of one day.
3) Rewrite the intro, and keep this copy.
4) Write the article.
5) Throw the article away. Wait a minimum of two days.
6) Write the article again.
7) Refer to the saved intro. If the article does not fit, modify either the intro or the article (just jot editing notes).
8) Rewrite the article, taking whole paragraphs as desired from the last copy.
9) Present to a reader and start real rewrites.

Oh, well - the original was shorter and much wittier.