next »

[Impossible Realms]

I was actually thinking of making a survival-exploration-real time strategy game once, wondering why I haven't seen any. Nice to know that I was wrong and that survival-exploration-real time strategy is actually a thing. Really nice job on this so far, I'll make sure to keep an eye on this one...

[K1lo]

Looking great, and that huge map too. Are you putting that structure creation into C++ code as well? You might profit a lot from including a scripting language like Lua for that procedural generation. And it will allow gamers to extend it, people love modding.

Thanks! I had a nightmare trying to find photo stitching software that would just create that image. I literally lost a couple of hours experimenting with different options, most of the software was trying to automatically compensate for prospective that a real panorama shot from a camera would have so it was a bit of a frustrating experience. In the end I just did it manually with about 30 screenshots in GIMP.

The structure creation is interesting because it is based on prefabs which are placed in the maps directory of the game. When a world is generated the world-wedge (as I call it anyway) is carved, then resources are placed, then sprites and water, then caverns are cut. All of this happens procedurally. Then the world is broken down into a couple of 2D grids (one for above ground and the other for under ground) and there is a low chance that each part of the grid has a prefabricated building or structure placed. This may chance later depending on whether I get the results I'm after with this approach - I'm still testing.

Whilst there are only four different prefab structures at the moment (which are basic shells still too - more to come) there is nothing to stop a modder creating their own - it will be included in map generation as long as it follows the prescribed map format which I've made very simple and can be instantly worked out by just opening a prefab file in a text editor.

Currently it is in this format:

-4                    (map header - file schema version)
14|27|7               (map header - prefab size - x,y,z)
0,0,12,10,0,LN,100    (repeating structure for as many blocks are needed)
...

z pos, x pos, y pos, block type ID, sprite type ID, overlay precalculation, block constitution (amount of damage - 100 = none)

I actually create prefabs currently by switching to a special map editing debug mode inside Isomer and crafting buildings out of a special block type, I then save the game and run a python script which extracts the blocks and creates the prefab file. I'm not sure if this method will be powerful enough for later when structures are comprised of many block and sprite types but we shall see, I've got a couple of ideas how to approach this. If (and this is my intention) I have a robust prefab creation method then I see no reason why I can't include the scripts with Isomer to facilitate modding. I got started making games by modding, making maps for games like Quake and tweaking things so it's something I'm really keen on. 

As for spinning out the procedural stuff into a scripting language, the main reason I didn't do this from the start was concerns over performance. I haven't settled on a max size for worlds, but one of the world generator options creates worlds that are 1024x1024x16, that's 16,777,216 blocks and takes about 12 seconds to generate on my dev machine (Core i5-3210M). I'm sure I can optimise my generation code a bit but I worry about older machines taking an age just to get into the game. I need to do some testing, the problem is I'm the sole developer working on this and the task list is a bit long still . I really like the idea of having bindings to say Python (or Lua, just I've never used it before so I'm not really familiar) - perhaps that can be a post 1.0 feature

I was actually thinking of making a survival-exploration-real time strategy game once, wondering why I haven't seen any. Nice to know that I was wrong and that survival-exploration-real time strategy is actually a thing. Really nice job on this so far, I'll make sure to keep an eye on this one...

Thanks a lot! The initial idea spawned many years ago when isometric style games were more mainstream, the whole project has been really fun thus far. I almost have a child like glee when each big next thing is in Isomer and working so I'm looking forward to releasing it. I'm hoping there will be enough people buying it to enable me to invest more time after release to add all the really cool stuff I want to like day/night cycles, weather, smoke, maybe more player entity classes, more neutral characters dependent on world type etc etc - this is currently my full time job as well as passion

[ananasblau]

Thanks! I had a nightmare trying to find photo stitching software that would just create that image. I literally lost a couple of hours experimenting with different options, most of the software was trying to automatically compensate for prospective that a real panorama shot from a camera would have so it was a bit of a frustrating experience. In the end I just did it manually with about 30 screenshots in GIMP.

Why not generate it from within your game? My exp with C++ engines is zero but usually I draw on a canvas and those always have a getImageData method or something similar.

As for spinning out the procedural stuff into a scripting language, the main reason I didn't do this from the start was concerns over performance. I haven't settled on a max size for worlds, but one of the world generator options creates worlds that are 1024x1024x16, that's 16,777,216 blocks and takes about 12 seconds to generate on my dev machine (Core i5-3210M).

Large maps, I have this with my cross country running game too, 10,000x5,000 is what I'm aiming for. But I moved this map generation a little so a chunk is only generated when I actually need it. In future that might cause my game's waypoints (which I still create at the beginning) to get stuck in a thick wood but that will only add fun :D

Minecraft is doing the same.

[K1lo]

Why not generate it from within your game? My exp with C++ engines is zero but usually I draw on a canvas and those always have a getImageData method or something similar.

I had thought about that, having a special function which disabled the HUD overlays and moved the screen from one bit to the other and progressively built up an image which it then saved. Not sure why I didn't go down that road in the end - it's a good idea. The thing is I'm not likely to do many of these world panoramas (although I really like how they look) and I can't see it being part of the gameplay so I didn't want to add a nonessential feature I'd have to QA and polish.

Large maps, I have this with my cross country running game too, 10,000x5,000 is what I'm aiming for. But I moved this map generation a little so a chunk is only generated when I actually need it. In future that might cause my game's waypoints (which I still create at the beginning) to get stuck in a thick wood but that will only add fun :D

Minecraft is doing the same.

Initially I had wanted to have infinite worlds which would have required breaking everything down into chunks as per the way Minecraft and others do it. This also has a lot of other advantages like asynchronous generation, loading / saving. I could detect how many logical CPU cores a machine has and spawn worker threads to parallelise these processes, it also reduces the work the game has to do for entities in far off areas.

Even if I don't end up going down the infinite world route I think breaking into chunks is a good idea, the only thing stopping me is the way the game AI currently works. If a section is not in memory or not being ticked, the entities (i.e. creatures and hostiles) would be frozen and not responding to what is happening in the game. I liken it to playing a game like C&C and having a chunk on the corner, possibly with an enemy base and units, not being part of the overall game until they player got close.

When I swap in a chunk I could have it simulate the passage of time since it was last active in a background thread before marking it as active and stitching it back into the active game area, but this would preclude the entities inside from leaving during this simulated time. They would however be able to mine, build and spawn new soldiers - that could work well.

At the moment I'm working on nailing down and improving core elements like inter-entity interactions and awareness awareness processing, pathfinding and AI. Once the core game is solid the next thing is to tackle (maybe increase) the larger world sizes and as part of this I could well end up breaking the world down into sections. We shall see, thanks for the suggestion and sorry if this reply has turned into a bit of a rambling braindump 

[ananasblau]

I had thought about that, having a special function which disabled the HUD overlays and moved the screen from one bit to the other and progressively built up an image which it then saved. Not sure why I didn't go down that road in the end - it's a good idea. The thing is I'm not likely to do many of these world panoramas (although I really like how they look) and I can't see it being part of the gameplay so I didn't want to add a nonessential feature I'd have to QA and polish.

It might be less work than you think, and having pictures is always great, thinking of the endless photos of minecraft I've put into my tumblr.

At the moment I'm working on nailing down and improving core elements like inter-entity interactions and awareness awareness processing, pathfinding and AI. Once the core game is solid the next thing is to tackle (maybe increase) the larger world sizes and as part of this I could well end up breaking the world down into sections. We shall see, thanks for the suggestion and sorry if this reply has turned into a bit of a rambling braindump 

Sounds like a solid plan, and keep on rambling

[impulse9]

Everything looks lovely! Two thumbs up from me! 

[K1lo]

It might be less work than you think, and having pictures is always great, thinking of the endless photos of minecraft I've put into my tumblr.

Very true! I don't think I've put them anywhere, but I have a folder of lots of screen grabs from Minecraft sitting on my harddrive.

Everything looks lovely! Two thumbs up from me! 

Thanks impulse9 - Love what you're doing over on your Secret of Ox worklog!

[K1lo]

I've overhawled and properly implemented lighting now. All that is left to do is enable the building/placing of light emitting objects in the world to light up areas without natural light streaming in - that's what I'm up to at the moment.

This is a quick demo of the shadows created when blocks are added/removed outside, I'll do another showing insides of structures/caves once the placeable lights are working.

By the way this isn't how things are built normally - I'm using the in game debug terrain editing mode

[K1lo]

Wow, quite a lot achieved today. Behold, dynamic placeable lighting for internal and subterranean lighting

[impulse9]

I like it. Although I think it would come better off as white light instead of yellow. Just a suggestion.

Also those shadows are sexy. But how do you explain floating ground? Or is that just for testing?

[Impossible Realms]

I'm assuming that its only for testing, due to the fact he said it was created in debug mode.

That being said, yes, those shadows look very nice. The lights might look better white instead of yellow, but they still look wonderful as-is...

[K1lo]

I like it. Although I think it would come better off as white light instead of yellow. Just a suggestion.

That being said, yes, those shadows look very nice. The lights might look better white instead of yellow, but they still look wonderful as-is...

Thanks guys!

All lighting is white light at the moment (I have some early code to handle light colour and blending but that's not used currently) - the cave lighting screenshots were from a desert type world hence the yellow colour.

Here is what it looks like in each of the three types of worlds currently in the game. I particularly like the ice world on the bottom as a deep crevasse was randomly generated - it's really fun to see what crazy worlds are generated 

But how do you explain floating ground? Or is that just for testing?

It's just for testing, whenever a block is placed/removed in the game lighting is recalculated for each block in the column. Using the debug mode to directly edit the terrain was the quickest way of making sure the shadows were correctly being dropped and muted by surrounding light.

[K1lo]

Wow it has been a while since the last devlog update.. it's been a busy few days (weeks? eek) but lots of progress has been made.

So, new stuff:

 - Periodic supply ships. Every few minutes (exact times are random and change constantly) friendly and neutral supply ships enter beaming range of the player dropship. Each supply ship can offer between two to five trades types ranging from reinforcements to resource exchanges. Different trades will cost varying amounts between supply ships, some will be a bargain and some will be more expensive for those ... more desperate times.

 - Ore rocks, found inside caverns and collectible by walking over them. Yields considerably fewer resources than mining but is also quick and easy to collect when found.

 -  Prefab construction/editing from within Isomer! This was discussed earlier in the thread, buildings and set pieces can now be constructed fully inside Isomer, saved and used when building worlds by the world generator. This makes it much much easier to construct prefabs like buildings and bases. It will be something that is left in the finished game to enable modding, although it will likely need to accessed with some command line switch to enable.

 - Vertical motion between levels supported where lifts exist in world. This allows for proper multilevel structures.

 - Animation support to game engine. Some tiles like lifts use them, more to come.

 - New sprites and resources (although majority are still dev placeholders)

 - Lots of back end code enhancements

We're finally getting close to an alpha with only a small number (3 by my last count ) of features still placeholders. In the background the artwork and polished sprites are well under way.

[Impmaster]

Lookin' good! 

[Impossible Realms]

Nice to see more progress on this. I really like the trade ship idea BTW...

[K1lo]

Nice to see more progress on this. I really like the trade ship idea BTW...

Thanks! It has been part of the design since the beginning but I though it would be just an extra element. The more I play test it the more it feels like a core part. It presents the quickest (if most expensive) way to get new units.

The other way is to build a unit spawner (which is actually one of the last mutations on the support branch). The unit spawner however only creates new workers (which can be mutated into any other type) whereas the supply ships currently 'stock' Workers, basic warriors, scouts and engineers so it balances the player choices nicely I think. 

[K1lo]

Yikes, another couple of weeks have shot by!

Here is what's new in Isomer:

- Building
The last big part of the game is now complete, you can now craft a number of block types and light sources using units with building abilities.

- Advanced mining / building commands (!)
Now instead of having to select each block you want a unit to mine or build individually you can queue groups of blocks.

- Selective transparency in world
If things were behind a wall of blocks it wasn't possible to see them previously. Now when the mouse box is behind blocks they become partially transparent.

- More natural entity motions
Rather than jerking from one angle to another, when a unit or create turns to looks at something, they move through the range of angles (e.g. looking north -> east is now : north, north east, east etc) which gives them a much more natural appearance.

I've also posted the first gameplay video over at IndieDB to show a few minutes of gameplay.

The exciting thing is that almost all of the core parts of Isomer are now finished. Next comes polishing and adding more creatures, items, loot, options to world generation etc etc.

[K1lo]

Have a great Christmas everyone!

[K1lo]

First update of 2013! I hope everyone had a good break

Lots of under the hood changes the last couple of weeks. Work continues and I'm hoping we will reach an initial alpha by the end of Jan or early Feb. Once more art has been completed I'm going to detail the various units you can mutate in Isomer plus some neutral and enemies that can be encountered. Until then, here's a work in progress version of the initial worker alien you can command.

I've been wanting to explain how units work and the stats that underpin the game for a while so here we go. Every unit in Isomer has the same set of attributes, they are shown on the newly (literally today) added stats screen.

Every unit has a unique set of base attributes depending on their type. On top of these, progressive veterancy gives fixed bonuses shown by the lighter part of the bars above. Experience points are gained by almost everything - mining, building, killing and looting but in different amounts.

The higher levels really reward careful leveling by adding new abilities like recovering health from looted bodies on top of the stat bonuses.

Here is a complete breakdown of all the stats and how they are used.

Health
As the name suggests, this attribute governs how much damage an entity can take before dying.

Energy
Every action in Isomer ( e.g. moving, mining, shooting etc ) has an implicit energy cost. When this drops below a quarter there are implications such as a temporary halving of the entity weapon accuracy.

Stamina
This attribute governs how quickly an entity recovers energy.

Accuracy
This is a percentage attribute used to calculate where a weapon fired by the entity hits the intended target. Other factors like range are taken into account but this attribute is the most important part of the calculation. For entities without combat capability (i.e. engineers) this can be zero.

Speed
How quickly the entity moves around the world.

Attack
The maximum amount of damage this entity can effect to a target. If a shot fired connects, the actual amount of damage dealt is calculated as a random value between 1/2 the attack and the full attack value. The damage is also mitigated by defense (see next).

Defense
This is a percentage attribute which deals reduces the damage done by a weapon blast by a fixed percentage.

Perception
Governs how far units without orders will scan their surroundings and automatically engage enemy forces. Measured in blocks.
This is the only attribute that is not enhanced by veterancy.

Mining ability
Percentage attribute which governs how quickly a unit will mine a block. If the unit is unable to mine due to other mutated specialisations, this will be 0.

Building ability
Percentage attribute which governs how quickly a unit will build an object or block. If the unit is unable to build due to other mutated specialisations, this will be 0.

Biorecovery
Some units are able to recover an amount of the important biomass resource from killed friendly and enemy units. This percentage attribute governs how efficiently they do this.

[K1lo]

The focus of work in the last few days has been replacing the existing placeholder combat system with something that would support all the features we wanted. I'm pleased to say that the work is now complete (minus some little polishing work and projectile impact effects) easily supporting many hundreds (actually I've not reached an upper limit yet  ) of different types of simultaneous weapon blasts in the world at a time.

These blasts can now miss, hit friendly targets or damage and destroy parts of the world as well as enemy kill units. Currently there are four different weapon types, a standard and heavy damage version for both friendly and enemy units, with plenty of scope for more to be added in the future! Also planned is to distinguish weapon types by rate of fire but this is planned for the next build.