Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / Boring bits. How do you cope?

Author
Message
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 30th Sep 2003 19:48
I think, unless you're a hardcore coder, coding gets very dull at certain points. For example, collision. I hate collision. I can make nice collision of various types, but I hate doing it. Another thing I hate is modelling and texturing, as it takes so long .... but most of all, I hate collision. I also hate AI, cos it takes ages, but I mainly hate collision. I'm not really a fan of making levels either, as they take a lot of time, and loads of effort to make them look good, but undoubtedly, my main hatred is collision.

All said and done, it's that stuff that stops my projects ever getting done. i get bored, I stop, and then I start something else. The initial buzz wears off, and I move onto another project, so what do you guys do to keep going? I know the vast majority of you are like me, purely because nothing ever really gets finished around here ... but those that aren't or those that get further than me, what are your techniques? I always get the main engine in place, then get bored and give up.

Insiiiiiiiiiiiiiiiiiiiiiiiide!
kingius
21
Years of Service
User Offline
Joined: 16th Oct 2002
Location:
Posted: 30th Sep 2003 20:07
I find that constantly testing while developing is very helpful. If you spend some time on your collision code, testing it as you go, its much more bearable than say spending two hours with nothing but the code and your notes
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 30th Sep 2003 20:29
1. Start the day by doing the thing you want to do least. Everything else after that is a breeze.

2. Set milestones, then you can acheive something every day. Ending the day having acheived nothing in particular is very hard.

3. Do one thing well each time you set aside time for your project. Everything else can go to hell...until next time.

4. "Well" means acheiving 80% of what you set out to do. You can do 80% of the task in 20% of the time. The last 20% will take you 80% of the time, and will kill you in the end.

5. Don't show your work to someone who has no appreciation of what you are doing. They will kill you in the end with their lack of enthusiasm.

BatVink (formerly StevieVee)
http://facepaint.me.uk/catalog/default.php
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 30th Sep 2003 20:36
It's the trivial things that bore me.

If it's hard and a challenge (especially if it's something new to me) I just bash away at it until I've got it sorted. If I don't 'get it', I'll move on and will come back later.
Rob K
Retired Moderator
22
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 30th Sep 2003 20:43
I go and do something else for a bit then come back when I am ready.

Some aspects of coding are boring, but they have to be done.

Ermes
21
Years of Service
User Offline
Joined: 27th May 2003
Location: ITALIA
Posted: 30th Sep 2003 20:50
i hate make a secondary control system, i hate make text on the screen who need the black color to be transparent, the edge are to be refined by handworking methods.
i hate to search the right sound, i hate to set the alienware models to show without light errors (who has designed it, we must cut out his hands) , i hate make instruction screen , i hate make frontends, i hate i have to fight with the dbpro bugs, i hate edit by mysel the icon of the exe, the editor wan't work for this.

i like to write my algorythm for ai, my physic systems control the objects, i like to write the engine of my game who control all the object on sceen, i like to make perfect and fluid control system for the player and the oppos, i like to write maths collision routine.

and i like the music of fallout, great songs , really good works.
do you thing you can give it freeware and license-free???

Free Download for a Free World
Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 30th Sep 2003 21:11
Or you don't cope. You get a cool new idea for a game, and when your current game gets a little too tedious you drop it.

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Yian
21
Years of Service
User Offline
Joined: 16th Jun 2003
Location: Nicosia, Cyprus(the Greek half)
Posted: 30th Sep 2003 21:23
ermes if you have made a maths routine collision could please show it or maybe if u have hotmail we can speak on msn...as for me I'm a Fallout.I hate collision and haven't managed to finish a single game,90% of the times because i need better collision.Especially in racing games, you need excellent collision so that you don't collide with invisible building corners...

-john D.
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 30th Sep 2003 21:34
My way would probably bore you to bits, but I try to make my game on paper before I do any coding. So, there's lots of flowcharts and function abstracts and such in a huge pile beside my computer before I start to code. There's lots of little quick sketches and such.

But the good thing about this is that you can "code" on the beach (except it's october here, and it's freezing now). When you sit down to write, the coding is really fast because it's already been done before, on the beach.

And then you get a very rapid appreciation for the game, as you see it grow.

This also means I can concentrate on what I think are the fun parts, creating the graphics. I'm not a natural coder, and I think coding is a chore, and much more appreciate the graphics side of game creation.

I'm not versatile enough to be a part of a team, so I need to make everything myself. I've just started with I/K and animation and such. But I can make killer static graphics! ;-D

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
Ian T
22
Years of Service
User Offline
Joined: 12th Sep 2002
Location: Around
Posted: 30th Sep 2003 21:46
I go code another little aspect of the same project until I've gotten it done. If it's something preventing me from developing other aspects, I just keep hammering away at it until it's fixed. If I can't fix it (sadly 30% of the time these days), I get annoyed and go play games for a few hours...

--Mouse: Famous (Avatarless) Fighting Furball
Read It: http://www.angryflower.com/itsits.gif
Learn It: http://www.angryflower.com/bobsqu.gif
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 1st Oct 2003 05:28
I'm the same Microman. I get it all planned properly. I work out all engine aspects, algorithm, math formulae etc on paper first, and that's why the games come together quite well, but I just never get past the engine. Maybe that's where the reality of being a single developer wanting to make a game in a few months, rather than being a large team with a few years, strikes home.

The engine is always fine, but as a single developer, I'm never gonna be able to finish my games, cos they're always too optimistic - especially seeing as I'm at uni, I teach, and spend lots of time drinking (although, that's really included under "being at uni"). I think it'd have to be a full time job for me to ever get anything done.

Insiiiiiiiiiiiiiiiiiiiiiiiide!
Ermes
21
Years of Service
User Offline
Joined: 27th May 2003
Location: ITALIA
Posted: 1st Oct 2003 17:35 Edited at: 1st Oct 2003 17:36
@John Darkeye

the routines i use are different for each game, most time i read the range between the two pivots of the objects, then if they're near enought, they collide.

i'm working, as entry for alienware, a game who need static collisions in dbpro, i make an array who has the coordinate of the space, (0 no building, 1 building height 100, 2 building height 200, ecc) , then i read the xyz pos of the player, i trasform it in array index and ceck if there is an object to collide at.
what you see on the screen, is a rapresentation of the array i have created. so ceck the array for collisions, not the object.

example:

this is maparray(5,5)

1 2 3 4 5

1 0 0 0 1 0

2 0 0 0 1 0

3 0 0 1 1 1

4 0 0 0 1 0

5 0 0 0 0 0

now estimate each grid is a 100x100 3d unit.

you have a world 0f 500x500 3d unit.

place an object like a cube of 100x100x100 when you have a 1.

read player pos and divide by 100.

the formula xarray=1+(xpos/100) yarray=1+(zpos/100)

value=maparray(xarray,yarray)

if value=0 no collision

if value=1 yes collision

and so on for the height of the player.

Free Download for a Free World
MicroMan
21
Years of Service
User Offline
Joined: 19th Aug 2003
Location: Stockholm, Sweden
Posted: 1st Oct 2003 18:23
I don't know if I really buy the saying that it's impossible for a single developer to make any kind of decent game. Again, it depends on the type of game I suppose.

I'm pretty pleased with my present project, for instance: "Dark Castle". I think it is a fairly advanced piece of coding. Given its nature, I think it would stand out from the crowd.

What takes time, however, isn't the coding, but the modelling. Perhaps THAT is the single impediment there is to a single developer. Not the coding, but the modelling. You can only preplan the modelling so far, and you'll still have to spend perhaps a week or more on each single model, no matter how small, to get it to work well and look good. Since there are dozens or even hundreds of little models...

Then you have landscapes, snd so on. I think it can take perhaps a month to write a fairly decent game algorithm, but the year bit comes with the modelling.

This, of course, is true if you use only Dark Basic (pro or classic). If you need extra DLLs and wrappers and such, it's going to take longer.

-----
They SAID that given enough time a million monkeys with typewriters could recreate the collected works of William Shakespeare... Internet sure proved them wrong.
-----
Yian
21
Years of Service
User Offline
Joined: 16th Jun 2003
Location: Nicosia, Cyprus(the Greek half)
Posted: 1st Oct 2003 21:02
Ermes your code only works well for cuboid shaped objects right?

-john D.
Kevin Picone
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 1st Oct 2003 22:30
- "what are your techniques?"


* Write re-useable code. Say it 100, no 1000 times.. Virtually all my DB projects use the same collection of libraries, regardless of style. These libraries are completely self encapsulated. This approach can be overkill initially, but will simplifying all of your projects in the long run. As new programs can be written in a fraction of the time. So being lazy is a good thing


* Design software that suits your libraries and your know how. The biggest risk to development stalls are the lack of technical knowledge. So avoid projects where your constantly doing research/development in order to progress. Nobody likes banging their head against the wall all of the time. So why do it ?


* Proof Of Concept first. Before you get the artists/sound guys churning out content, at least establish a demo that shows the raw "GAME" is within your grasp. This means, the player, some actors, basic environment/scene with interactions. Once you've established it's a goer, and if your still into it, then jump in.


* Limitations. From the proof work, you should be able to see out what the game is and isn't going to be capable of. Knowing your limitations is vastly import from an art / sound, and program design standpoint. So your content / environments / Character interactions in the game are designed to fit the evolved proof, not the other way around.


* Tools. Find as many off the self tools as you can to create/edit your raw content. For the game content, write an editor that can edit the levels (import/convert the various content) from stand alone program. The tool doesn't have to be fancy, or even remotely attractive. Just enough so it's easy to use. Then your artists/designers can rapidly flesh out / tweak worlds, while you write the game core. Make as many of game settings external as possible, so the game can be tweaked by anybody in the team and not just the main programmer.


* Communication. Make sure those who are involved know what their doing, how their to do it, when etc. The clearer everybody an communicate the faster the process becomes. Don't be afraid to make executive decisions. If you the buck stops with you, and the art/designers want to include feature ABC, and it's beyond the projects scope. Then say no. There's always room for a sequel


* Avoid Feature Creep. The worst thing you can do while in the middle of your project is continually add new ideas to the feature list. This is death. First write your program to your specs/initials features. Then evaluate if any extra features are in fact needed. The focus in on finishing..

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Ermes
21
Years of Service
User Offline
Joined: 27th May 2003
Location: ITALIA
Posted: 2nd Oct 2003 17:46
@John Darkeye

yes, only for cuboid. you can make a platform game like 'crok' using this tecnics!!

i see your lack is collision!!!!

Free Download for a Free World
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 2nd Oct 2003 19:33
Never try and develop your engine/game from that beta that is slopily coded and buggy. Starting afresh gives you the chance to organise your code - the more organised your code - the more chance there is that it'll get finished. The apps I've done all share the same style of GUI - which is sorta like a library of gui commands that are called through a text string, buttons have the corresponding gui text string and positions stored in an array, dropdown menus etc can all use the same gui text system - this lets me add commands and features with minimal fuss. You might thing that a gui is only a small part - but really it's the glue that holds your app together. Similar techniques should be considered for other projects, like RPG's for instance.


Van-B

My cats breath smells of cat food.
kevinthekangaroo
21
Years of Service
User Offline
Joined: 4th Jun 2003
Location:
Posted: 5th Oct 2003 22:15
Ok. Assume I make a game engine, a very good one. Then there's the task of making the levels. The only option I have to make levels is milkshape. I can't make levels in 2d perspective mode, I can't stand it it's so boring. If darkbasic had object making tools, (make object 1, add vertex 1, position vertex 1, make face out of vertex 1,2,3 flip face 1.Texture face 1, coodinates of an image. Save as db0.) stuff like that then I could built a real time level editor. But I can't so I get bored and the game stays unfinished and I think damn, it'd have been so good if I'd been able to finish it.

Then there's the other problem with not being smart enough to make a game engine and that's just frustrating as you try combo after combo of code and nothing works so you can't make your idea.

I have _never_ finished a proper game with darkbasic/dbpro in my life.
Yian
21
Years of Service
User Offline
Joined: 16th Jun 2003
Location: Nicosia, Cyprus(the Greek half)
Posted: 6th Oct 2003 00:16
and how many have you started?

Jeriko The Slyz,Yian The Craft,The Mechanist,The Lost One,Master Of Dots,Bambos O Bellos,Zolos O Kolos
Wik
21
Years of Service
User Offline
Joined: 21st May 2003
Location: CT, United States
Posted: 6th Oct 2003 04:00
I hate positioning things!
I can't do it very well

The rock has rolled!

Login to post a reply

Server time is: 2024-09-20 14:35:16
Your offset time is: 2024-09-20 14:35:16