Planning and design
 

Ok, I have no active projects so I'm thinking of starting a bot.

This question is mainly pointed towards the people currently working or planning a bot.

What is your design process?
What gets planned first, is there a specific order?

Sorry if these sound dumb but I need a good startpoint.
Don't think I'm a complete idiot though, I know C, C++ and the HLSDK but
I'm just wondering how you all put it together and in what order.

I generally start in the wrong place and hopefully a point in the right direction can get some plans written while I examine some open-source bots and read up on things like pathfinding, ect...

Any thoughts are appreciated.

Re: Planning and design
 

Hmm, it totall depends on what you want. Do you want to write a bot that is an all-in-wonder? You probably start then writing a lot from scratch to make sure the bot is using classes and also is able to work in other mods and such.

If you just want to play around first, i suggest you hack into some existing bot sources.

After that, i'd say:

- work on code structure first
- work on navigation

make sure the 2 above are almost complete. The code structure should be readable, (its hard to keep it readable if you code a lot new stuff) and it should work of course. Then add a simple form of navigation, like using waypoints/nodes/navmeshes/no waypoints (tracelines nav).

once you got a solid code, where you can code from you can expand your bot easier.

In very short order:
code layout/structure
navigation (select goal, make path, walk)
combat (fight, shoot, take cover)
advanced navigation (goals)
advanced combat (flanking, swat behaviour?, outsmart enemy)
fancy stuff ;)

Re: Planning and design
 

All IMHO
Obviously you have to know C (C++, API, ...)

well my design process was :

1. Gather information about coding a bot, find webpages, forum
2. Download many bot source codes
3. Download HLSDK and compile a (someone else's) bot
4. Try to understand the bot code (from HLSDK point of view, Dll hooks ...)
5. Understand the rest of the code
6. Decide if you will be modifiing existing source or you will start from begining
(I started from begining, leaving only SDK and some botman's functions)
7. Create a bot which joins
8. looking, moving
9. buying weapon, speaking
10. navigation - I'm here

Hardest parts (for me) :
- understanding the code
- deciding inner bot representation (C++ classes, 'cause I'm using C++ in my bot)
- deciding better inner bot representation ('cause the first one didn't work :D )

Do not try to understand everything at once. As I approach some problem (for example how bot should talk) I search the bot source code. Then I search the botman's forum. If I am not succesfull I search again and again and after not finding what I wanted I post my question o_O

Do not try to program the best and most effective piece of code for the first time. My priorities :
1. Must work without bugs.
2. user-friendly
3. Has features I wanted
4. Is effective
(It is no good to have an effective, but buggy algoithm)

Source code structure : lots'a comments (like PMB does)

Re: Planning and design
 

agreed. Although the priorities differ for each coder, i do agree on this 'code structure'. Keep the code, nice, clean, but commented.

here a snippet from my own BotThink function (a left over from botmans template actually):

Re: Planning and design
 

Thanks for all of the information and advice - I guess its time to look through bot code and take notes.

Re: Planning and design
 

I'm still new to HL coding and c++ in general (I'm a java guy :]), so my method might not by the best way to handle things.
I started by reading Botman's most excellent readme, downloaded his HPBbot source, messed around with that, got it to work with another mod (SI), continued tweaking and expanding on that, got annoyed by the C style programming so I started almost completely from scratch leaving just the "engine interfacing" code and the waypoint code. My bot is now nicely OO thus making the code alot easier to read and maintain. My bot is structured as followed:
-a global botmanager that adds/removes/updates bots
-the bot class
- a task class
- a bot weapon class (this is just Botman's struct really, but turned in a class)
- a team class

I was planning on doing a complete overhaul of Botman's code, but as I just want a new version out, I'll just modify botman's combat and navigation code.
Getting feedback is always a great way to get you motivated, so don't go for a perfect bot for each version, just release something you're fairly happy with.
I'm staying away from navigation for now, as I really have to read up on that stuff to improve on it. Just start small, it might not be the best way to handle things, but by the time you realise you're going at it the wrong way, you'll have learned quite a few new things.

Re: Planning and design
 

yes, do not be afraid to release a bot with bugs. Bugs are there to be removed, and you can't possibly find all bugs yourself. Hence, i launch WIP's frequently so people give me 'more work' ;)

Re: Planning and design
 

This is a bad attitude to have as a developer!

I worked for 4 years in serious software testing before writing any code.
(testing things like backup software that fortune 100 companies used to back up / restore their databases / file systems / operating systems...)

This served me very well in my career as a developer. I saw the large amount of wasted time caused by developers releasing code they didn't even really test.

Strive for perfection from the start, as much as reasonably possible and then you will be in a better position to fix the myriad of bugs that will arrive anyway.

IMHO!

Re: Planning and design
 

Thanks for the last few suggestions, I will not write one line of code until I have written out a general idea of what I want to accomplish.

Implementing it is no problem for me, its the figuring things out part that takes the brainpower.

Re: Planning and design
 

I agree that you should test your piece of code before continuing, but you can't be perfectionist if you are developing some code for the first time

(example : you are going to write a pathwalking algorithm for your bot. When you start coding it, you will find that your waypoint representation is not very good for this algorithm. Thus you have to rewrite waypoint representation. Next time you will be making waypoints, you will already know this problem and you will do it 'pathwalking friendly' before you code pathwalking)

I am talking about experience. If you don't have a good experience with coding a bot, you can't be perfectionist, 'cause you don't know whay lies ahead.

You can't optimize code for something you don't have experience with (can't optimize waypoints for my pathwalking algorithm if I haven't created one yet)

Re: Planning and design
 

lol @ Austin. I do test my code, don't be afraid. Like the last build, i got screenshots of bots planting the freaking bomb. And what do people say as a bug "they do not plant the bomb"... the problem with this is, there are several factors where the problem could be:

1) bots simply always meet and therefor fight and die
2) bots simply do not want to plant the bomb (because personality value is very low)
3) ct bots are higher skilled then t bots, so 1 ct takes out 2 t's.

etc. THe bomb code works, the defuse code works... yet i need people to test it out for me.

Don't be afraid, i never give a dll away without playing it for atleast 5 minutes myself! :)

Re: Planning and design
 

Austin, I know exactly what you are talking about :)

Most of the problems with software can be fixed before they even happen by coding in a "safe" way which lowers significantly the probability of errors from occuring. I found that you can do safe coding much faster than ad-hoc coding, and you can still have very efficient and readable software, ie there are no real disadvantages, only advantages. You can even create code that tests itself by doing comprehensive internal integrity checks, such as the NULL pointer test that has become common in C/C++ coding.

Re: Planning and design
 

i will never regret my comments! :) Everything i code is atleast workable, re-read and thinked-twice before i even begin writing. I do understand your pov Austin & botmeister, but my comment was of course meant in a funny way. :D

Re: Planning and design
 

Stefan, your released code seems to very stable to me so you're obviously getting along quite well. My comments were not directed at anyone, just chatting about coding technique, which is a topic I enjoy discussing.

Re: Planning and design
 

i understand ;) thanks for the compliment btw ;)

Re: Planning and design
 

What is the difference between nodes-based and waypoint-based navigation ? Or is it the same ? o_O

Re: Planning and design
 

It's pretty much a question of vocabulary. Depending on the meaning you put behind both. For example, almost everybody agrees that waypoints are "points", i.e. vector locations in the virtual world. Some may call waypoints nodes, but some also use the term "node" to describe a more generic concept, basically a leaf in a pathfinding tree. With my bot for example, which one uses a navmesh, the nodes are not points, but polygons on which players can walk. These "navnodes" can extend over 200 units length and width in the virtual world, depending on how the map was made and how it was compiled into the BSP tree.

The difference between the concept of "points" (waypoints) and "nodes" in the meaning I give them, is that for me, these walkable faces describe much better the shape of the world to a bot than what waypoints do. You have to imagine what a bot see. Where you, as a player, see walls, staircases, rooms and alleys, all a waypoint-based bot sees is a constellation of stars in the void, each star being a waypoint.