Worklog for impixi
Casual RPG
Return to Worklogs
| ||
| For archiving reasons, here is the latest version of my Heightmap Toolbox. The biggest change is the separation of the LightMap/ShadowMap code into its own class. Since most of the core algorithms are coded in C, Windows users will require MinGW installed. HeightMap ToolBox V0.4.4 hmap04.4.h (required) hmap04.4.c (required) TShadowMap.bmx (optional - for the generation of shadow maps - see test4.bmx example) HMap04.4.bmx (required) test1.bmx test2.bmx |
| ||
| test3.bmx test4.bmx test5.bmx test6.bmx test7.bmx |
| ||
| It has been quite some time since I posted my previous work log but I'm still here and viewing the forums every day. During the past six months I've coded many unpublished algorithms, tools and applications. Some are useful toward my casual RPG, others not so much. I've not found a suitable 3D module, though Max3D has the most potential so far. |
| ||
| I've decided to release the latest HeightMap ToolBox here in my worklog. You'll need a c-compiler... HeightMap ToolBox V0.4.3 {superseded code removed} |
| ||
| {superseded code removed} |
| ||
| I’ve been busy the past two months, more-so with real-life matters than Blitz programming, and have done very little related to my primary RPG project. I’ve coded some mask and alpha-map generation algorithms for use in my texturing system and that’s about it. Consequently my ‘Heightmap Toolbox’ is up to Version 0.4.2 (the version in the Code Archives is 0.3.6), but because it’s mostly C-code now it will remain ‘in-house’. For something different, I decided to take advantage of my Apple developer membership and download the iPhone SDK. After learning Objective C, which is not so bad once you get used to its conventions, Apple’s associated UI frameworks killed my resolve. I just could not stomach the very heavy modern OO design. Perhaps it makes things easier for the current generation of programmers, but my old-school brain can’t hack it. Especially when even basic data types (like ints) must be treated as objects. It seems terribly inefficient to me, considering your target hardware is a mobile phone, given that in every situation I’ve encountered, OO compilation adds noticeable performance overhead. (I should mention that the official Objective C language specification apparently supports the use of C-native data types. However, where the iPhone SDK is concerned this seems not to be the case – I may be wrong?) I do find some object-oriented language features indispensable, like encapsulation and, occasionally, inheritance. I just think you can take it too far, and end up making more work for yourself. A small diversion had me code a text ‘terminal’ that did not require DirectX or OpenGL. The goal was to create a cross-platform component that could be used in a coloured text ‘Roguelike’ game. I planned to code it in C, interfacing with the WindowsXP built-in Terminal/Console control (and the OSX equivalent), and then provide a BlitzMax wrapper. With the help of the MSDN docs I managed to get quite far with the Windows XP version. It was when I fired up XCode on my Mac, logged onto the ADC and started rummaging around, I came to my senses and gave up. Such adventures remind me that, fundamentally, nothing is actually simple in computer programming. So I turned my efforts to MaxGui. I could not base my text terminal on the TextArea gadget because that does not allow individual character foreground and background colourization. (And a brief poke around the gadget code told me I couldn’t be arsed figuring out how to modify it to do so). In the end I created something based on the HTMLView gadget that worked pretty well on XP and OSX. There’s a few little rough edges that need ironing out, but I’m bored with that project now. The other topic I want to write about relates to a thread in the general forum about alternative (to BlitzMax / Blitz3D) languages. I’ve seen quite a few comments in support of things like Unity3D and Shiva. For me, these heavy GUI IDE environments are a real hindrance to development, possibly because my game procedurally generates content at runtime, and these tools apparently provide very limited support for such an approach. I also find myself overwhelmed by the interfaces, unable to find where to put what, and when. I suspect I’m in the minority, but the day simple yet powerful language-based systems like BlitzMax die is the day I quit programming… |
| ||
| In my previous worklog entry I mentioned that I ported a large chunk of my code to C. Well, I decided to go the extra mile and port it to C++. To be honest I'm not impressed. Object orientation apparently adds significant overhead (at least as far as the MinGW compiler is concerned). So I think I'll be sticking to plain old C where optimal performance is concerned. On the BlitzMax 3D engine/module front, I purchased the Leadwerks Engine for evaluation. It's respectable enough, though with some caveats. For starters it's Windows only, and you need a shader 3 capable graphics card. Secondly, I've not been able to replicate my simple Blitz3D engine/viewer using it, because attempts to stretch a texture to match the terrain size results in the jumbling up of the texture. |
| ||
| For curiosity’s sake, I spent the past week porting a large chunk of my BlitzMax code-base to C. It has been many years since I last coded in C, but everything proceeded as planned and I managed to gain a few seconds in the generation of a 1024x1024 landscape. Gains in the generation of smaller landscapes proved less impressive, so overall it seems BlitzMax is reasonably optimised. With regards to my previous worklog, I’ve devised an interesting player/actor stat system. I look forward to implementing it within a full featured engine, as that will be the only way I can truly test its functionality. The quest for an appropriate BlitzMax 3d module continues. At the moment, FLOW looks like a really good option. Of course, Max3d is also on the cards. Unfortunately niether have been released yet and probably wont be for a while. |
| ||
| Progress continues at a respectable pace, though I’ve deviated slightly along the way. Object Placement Algorithms I devised some generic object placement algorithms that produce good, natural-looking results. The system populates a map with several thousand trees, rocks and plants in less than a second. The thing is, it will need to be reworked / customized / or perhaps even redone entirely depending on the 3d solution I choose to go with. Will I need to limit the number of unique objects in the map so as to utilise single surface ‘layers’? Will I need to code distribution filters corresponding to object-pooling techniques? Will shadows be shader-based or use older methods? What about object reflections across water bodies? The answers to these and other questions will depend on what 3D module / solution I choose. And for optimal performance and memory consumption my object placement algorithms must be designed accordingly. So I’ve decided to suspend work on this (and other renderer-dependent systems) for the time being. Ultra Simple Terrain Generator USTG is basically an ‘in-house’ tool that allows me to generate a terrain (heightmap, shadowmap, texture) with a single click. I rewrote version 1.0 from scratch, based around the latest MaxGUI SVN code and my latest algorithms. I’ve been toying with the idea of releasing an improved version to the public, Freeware, but I suspect there would be little interest. Procedural Textures My terrain texturing system generates its results using pre-made texture files, however, I wondered if I could procedurally generate them instead, thus saving on storage space and bandwidth. I spent some time adapting my fractal algorithms to use colour-sets instead of texture files. The results were okay and probably passable but I decided the file-based method produced better looking results. Another downside to the procedural approach is it added about five seconds to the terrain generation time. Orthographic Experiments In my quest for a suitable BlitzMax 3d module I investigated MiniB3d versus Blitz3dSDK. Unfortunately Minib3d lacks a built-in terrain system and I’m not very fond of ‘pure’ mesh terrains because of their high memory requirements and texture seaming issues when chunking, so I decided to experiment with a ‘retro’ 3D orthographic style, set atop a custom flat ‘grid plane’. (eg Ultima 8, except 3d instead of 2d) It was an interesting exercise that let me try out different methods of handling large quantities of scenery objects (eg trees, plants, rocks, etc), trying to find the best one. I tried four methods: single-surface layering, real-time creation/deletion, list-based object pooling and array-based object pooling. The conclusion: any of the later three methods perform equally as well as each other, at least where the simple orthographic map I created is concerned. Probably the best approach is a combination of layering and pooling. Again, this will be dependent on the chosen 3D module. As for MiniB3d versus Blitz3dSDK, they perform similarly on my mid-range PC. Regarding Blitz3DSDK, I’m not keen on the reliance on integer handles. It’s awkward to program for if you’re used to objects. You can code around it by writing wrapper objects, but there are cons to that. Stat / Attribute System Most recently, I’m coding the stat / attribute system for my game ‘actors’ (eg the player, enemies, etc). Currently it’s very generic, suitable for use in a CRPG construction set, capable of run-time modification (eg adding, removing of attributes, skills, traits, etc), but I’m thinking this is superfluous. I’m going to rework it, ‘hard-code’ it, for performance and code-simplicity reasons. |
| ||
| I’ve ‘completed’ a terrain generation system that I’m reasonably happy with. It’s not perfect or ultra-realistic, but the results are interesting and variable. A 512x512 terrain takes five seconds to generate (on my 2.4Ghz Core2Quad processor) and comprises a height map, shadow map, texture map, mini-map, detail textures and skybox. The generator is coded in BlitzMax. However, the viewer/game engine is coded in Blitz3D because I’ve yet to find a suitable BlitzMax 3D module. I’m using Blitz3D’s built-in terrain capabilities – quick, resource-efficient, easy. The downside is I’m not able to code a respectable multi-texturing and texture-splatting demonstration. Here are some screenshots: Terrain 1: ![]() ![]() ![]() ![]() Terrain 2: ![]() ![]() ![]() ![]() Terrain 3: ![]() ![]() ![]() ![]() Next up is the object-placement system (for trees, vegetation, rocks, encampments, ruins, etc). I’ve already created some prototypes that produce natural-looking results, but I need to re-think and/or optimise my approach since they are unacceptably slow. |
| ||
| For years I’ve been designing and coding components for use in a casual RPG. It’s about time I started documenting my efforts. The basic plan is to create a system that can generate a 3D game to be ‘completed’ in 30 minutes. The user plays the role of a lone adventurer sent into an expansive outdoor environment seeking fame and fortune by collecting useful plants, rocks, artefacts and other items, and defeating regional enemies. At the end of the game a score is awarded. The player’s abilities, weapons and tools can be ‘upgraded’, and part of the challenge is selecting the appropriate ones for the current environment. Combat is tactical, turn-based, with possibly an option for real-time, action-orientated combat for a quicker adventure (10 – 15 minutes). Each game is populated with different enemies and objects (some interactive), selected from a pool of hundreds. Terrains are generated using fractals, and significantly variable. Also, one or two random environment events can occur. In combination these factors should provide a good variety of games. The setting will be ‘alien-world science-fiction’, with additional ‘packs’ released later that provide other settings. It will depend on the availability and affordability of media. |













