Jump to content

March 2017 »

19202122 23 2425

Recent Comments

- - - - -

An example of a big change in Caveman

2: Adsense

  • untitledbody multiply
  • untitledbody subderm
  • untitledbody displ
  • untitledbody details
  • untitledbody derm
  • untitledbody complexion
  • scrndmp36b
  • scrndmp36
  • savanna grass
  • "instancing" in DX9 - implementation in the game
  • "instancing" with DX9 - closeup
  • "Instancing" with DX9
  • Best bow shot ever - close up
  • My best bow shot ever in the game!
  • And last, but definitely not least - Savanna
  • prairie terrian
  • Improved animal models and animations: Smilodon Fatalis
  • Improved tall grass using the new generic random map.
  • Swamp effect with jungle vegetation

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! <g>).
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

<going off on a tangent>
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.

<end going off on a tangent>

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! Posted Image

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! <g>.

Feb 05 2015 11:01 AM
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.
Feb 09 2015 05:30 PM

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...

Note: GameDev.net moderates comments.