Progress on Dirk Headstrong and the Martian Madness is progressing very well, with the main hub area of the game now in place and the first puzzle set up.
Creating a game in 3D Construction Kit has turned out to be far simpler than I expected. Back in the Nineties, I built a game in 3DKC but found it took an awful lot of time and effort to get anywhere with it. Now (possibly thanks to having already planned out how the game should look and what it will be about, because that really does help) I’m enjoying the process far more; and getting good results a lot sooner!
This is good progress but there is a lot of the game still to be put together, so I hope you’ll continue to join us as we construct the game further in future episodes.
As always, you can download the game code as it stands at the end of this episode by clicking here.
Thanks for posting another entertaining 3D Construction Kit game creation video, taking me back to my childhood memories!
As you have realised by now, there is no need for you to make efforts to conserve memory – the 14k is plenty. The C64 has only 5K free and that was enough for 20-30 areas. If memory was an issue, then there are plenty of techniques for conserving it – using globals for reusable objects in multiple areas, and using procs for reusuable conditions across areas.
Instead, I think priority one is normally performance. Performance goes down in relation to the number of objects that drawn on the display. 3DCK doesn’t know if objects are full behind other objects so it draws everything that might be visible on the display. For this reason, I recommend creating more areas with less objects in them rather than creating multiple rooms in a single area.
As Patrick mentioned, it is worth going through every object to ensure that all sides that will never be seen are shaded INV for performance reasons (not memory reasons). In the hub, it might be worth turning the global floor off.
Each new area uses global area (area 255) object 129 for the floor. It’s worth taking a peek at the global area 255 objects (one by one to avoid object overlap) to examine what is available. They are very useful for reusable walls. Unfortunately the walls are cubes rather than rectangles, which are slower to draw. It might be worthwhile creating new rectangle objects in area 255 for reusable global floors and walls that can be used in any areas. One thing I would definitely recommend is shading the floor object 129 in area 255 to ensure that all but the top side of the floor cube are shaded to INV for a performance boost in all areas.
As for the non-clearing of the Bondak message, it’s weird – printing in other areas immediately clears (you may want to use a delay 100 statement to give the player time to read the message for picking up the key). Maybe the Bondak message lingers because the textcol uses colours that are not of that area, maybe the sensor ifsense kicks in after the destructuion of the Bondak. Drawing and clearing messages on the viewscreen is a puzzle that I never mastered, so I resorted to printing outside the viewscreen, over the border graphics. These messages remain unless you print over them with a message full of spaces. This can be useful for an itinerary, for example a “you have a key” message can be left permanently on the border during the game. I don’t know whether you are planning to create your own border graphics, or use the defaults that come with the kit. Did you know that there are two defaults. The one you are using is called kitscr. There’s an alternative Driller-like border called drillscr. Might be worth investigating. Good luck with the game, regards, Steven
Hello again, I forgot to mention the caution that should be taken if you use 3DCK globals. There are bugs that can crash, or worse, corrupt your game. The golden rule is to save before messing with globals, and avoid deleting any global objects at any cost, because there is risk of permanently corrupting your game. Adding and editing objects in the global area 255 should be fine. Don’t add entrances or sensors to the global area as I believe that crashes the editor. Best regards, Steven.
One more thought, I’m wondering whether the deleted sensor actually might have no effect on the ifsensed # command, such that you are still being sensed! You could test by adding a sound after ifsensed # to see if the sound can still be heard after the Bondak is destroyed. In which case, you could change if “sensed # then” to ifvis [bondak head] and ifsensed # then”. I think this might be THE explanation! Good luck!
And if the above solution works, then a more efficient solution (that avoids unnecessary ifsense computations) would be: ifvis [Bokdak head] then else end endif ifsensed # then …
If this works then you will no longer need to print the blank message 2 over the screen.
Best regards,
Steven