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
type.
init_object_types_database
--------------------------
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:
------------------
build
inspect
repair
demolish
in_way_of_drawing // boolean. dont draw plants etc in huts!
in_way_of_moving // boolean. collision check
add_to_collision_map
// adjusts 3pv camera location to hut interior
get_3pv_camera_coordinates
first_BM_nearby
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,
and
2. controling code that uses low level classes.
then the controling code would do something like:
loc=bandmember.get_location
loc2=calculate 3pv camera location from loc
playerhut.adjust_3pv_cam_location(&loc2)
camera.set(loc2)
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
worldobj_in_playerhut
// checks if a bandmember is in any player hut
BM_in_playerhut
remove_stuff_nearby_playerhut
render methods:
---------------
draw_world_objects
draw_local_map
draw_world_map
process_input methods:
----------------------
selected_playerhut // boolean
playerhut_menu // playerhut actions
takeover_abandonded_hut
update methods:
---------------
remove_distant_dropped_objects // dont remove stuff near huts!
model_playerhut_raids // calls playerhut.raid if a raid occurs
model_playerhut_weathering
other methods:
--------------
// boolean. checks if bandmember is near a player owned cave, rockshelter, or hut
BM_near_shelter
// boolean. checks if player owns a cave, rockshelter, or hut
owns_shelter
The actual changes were pretty straightforward.
permanent shelters used:
bandmember.has_perm_shelter
bandmember.perm_shel_quality
bandmember.shel_mx
bandmember.shel_mz
bandmember.shel_x
bandmember.shel_z
and player huts use:
worldobj.active
worldobj.qual
worldobj.mx
worldobj.mz
worldobj.x
worldobj.z
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!
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! .
