• Advertisement
  • entries
  • comments
  • views

An example of a big change in Caveman

Sign in to follow this  


An example of a big change to Caveman

I've been playtesting a lot recently.
Drawing objects in an avatar's hands in animations
is the next thing on the todo list - and that's just
eye candy. I'm into gameplay, not eye candy.
So I've been playtesting my long term playtest game,
making note of fixes to be made. I've gotten to the
point where I have 10 bandmembers in my band!
Occasionally I'll stop and make a change necessary
to continue testing. But that is becoming less
and less frequent. I can test for an entire day
with no changes required to continue testing.
That's a sure sign that the game is getting closer
to completion, when everything is working correctly
and no major issues are encountered while testing
for hours or days on end.

I just finished a change that was really required
for futher testing. Permanent shelters have been
replaced by a new type of object, a PLAYERHUT.
Before the change, each bandmember had to create
or takeover their own hut, and they were limited
to one each. Now, each bandmember can create
or takeover as many huts as they wish, and huts
are owned by the band, not individual bandmembers.
So one bandmember with lots of construction skills
can build huts for all the bandmembers.

A description of the changes involved:

#declare object type
defines an ID number for this type of object.

the game tracks items in the world using a
"objrec2", which is an instance of 1 or more
items of a given type and quality at a given location.
lists of objrec2's are used for containers, PC and
NPC inventories, and the world objects list (dropped
inventory items and items built by the player -
such as huts! ).
The game uses a relational database design, with
objrec2's pointing to object type instances in the
object types database, via a object type ID number.
object type instances contain info like name, weight,
and price which are common to all objects of a given

inits the object type's entry in the object types
database. IE sets name, weight, price, etc.
not much here, i set the name and radius but the
code uses neither! :O

PLAYERHUT methods:
in_way_of_drawing // boolean. dont draw plants etc in huts!
in_way_of_moving // boolean. collision check
// adjusts 3pv camera location to hut interior
raid // conducts hostile caveman raid on a player hut

should get_3pv_camera_coordinates be a camera method or a
playerhut method?
it uses both...
continuing along those lines...
should in_way_of_drawing be a render method?
should in_way_of_moving be a physics method?
should add_to_collision_map be a collision map method?
should first_BM_nearby be a bandmember method?

more and more its seems that for loose coupling and tight
cohesion, code ought to be divied up into two types:
1. low level classes that know only about themselves,
2. controling code that uses low level classes.

then the controling code would do something like:
loc2=calculate 3pv camera location from loc
bandmember, playerhut, and camera only know about
themsleves. only locations are passed between them and
the controling code.

world objects list methods:
// checks if a world object is in any player hut
// checks if a bandmember is in any player hut

render methods:

process_input methods:
selected_playerhut // boolean
playerhut_menu // playerhut actions

update methods:
remove_distant_dropped_objects // dont remove stuff near huts!
model_playerhut_raids // calls playerhut.raid if a raid occurs

other methods:
// boolean. checks if bandmember is near a player owned cave, rockshelter, or hut
// boolean. checks if player owns a cave, rockshelter, or hut

The actual changes were pretty straightforward.

permanent shelters used:

and player huts use:

all the code already existed, it just needed to be changed to use
PLAYERHUT world objects instead of a bandmember's permanent shelter.

One prime motivation for this change was the fact that caves,
rockshelters, and NPC huts you can take over now occur at random
locations in a map square (a square 5 miles across). They used to
be at most one of each per map square, and always in the same place.
And if there was water in the map square it was always nearby all
of them - IE everything was near the center of the map square.
Now its much rarer for a cave or hut to be near water and all
rockshelters are more than a mile from the closest water. So
building a hut is the best way to get a shelter close to water,
which is the most frequently required required resource in the
game. And it takes a lot of skills to build a hut. The research
tree is incredibly long and complex. So requiring each bandmember
to go through this to be able to build a hut when their fellow
bandmember(s) already have the skills to do so didn't make sense.
Not sufficiently realistic, needed to be improved. Thus the change.

And now...

I'm off to build huts for all my bandmembers! smile.png

You should see what its like trying to cram all ten of them in one
hut so their mood doesn't go down from being out in the rain! .

Sign in to follow this  


Recommended Comments

Do you write these in notepad with word wrap off it something? Your use of new lines makes your journal really hard to read, as had been pointed out before.

Share this comment

Link to comment

Do you write these in notepad with word wrap off it something? Your use of new lines makes your journal really hard to read, as had been pointed out before.



as a matter of fact - yes! <g>.


but word wrap is usually on, and i just insert carriage returns to make sure the text is not too wide.


not sure why i got into the habit of doing that. something i was posting somewhere tended to botch things if i didn't. so i sort of got into the habit of always doing it everywhere.


i'll try relying on word wrap next time and see what happens.


only now am i beginning to get mixed text and code blocks working. and it still usually takes a few tries.


i guess you might say my experiences with the website's editor have been less than transparent / effortless - whats the term i'm thinking of? frictionless as Johnathan Blow would say...

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement