next »

[K1lo]

The alpha is available via the Steam and Humble Store widget on the Isomer website and Desura!

Isomer work log

• Game website
• Official forum
• IndieDb page
• Youtube channel with devlogs

Isomer is an isometric realtime strategy with sandbox gameplay inspired by classic XCOM and dwarf fortress style games. It's open ended, designed to be played in a variety of ways with world exploration, survival, crafting and strategy all blended together in a retro format.

You control alien forces hell-bent on conquering enemy worlds for their resources. How long can you survive? What will you build and discover?

The worlds are large, teeming with catacombs and life, procedurally generated with gameplay inspired by classic XCOM and dwarf fortress style games. Each play through is unique presenting different challenges and requiring different tactics.

Current features along with what is being worked on for the next major update can be found on the development status page.

[impulse9]

I like the style, but ... is it just me or is the perspective on some of those screenshots a bit funky? Some tiles on 2nd and 3rd screenshots seem to have illusory perspective (I'm not sure if that's intentional?).

Anyway, wishing you luck.  

[K1lo]

Much older images:

Original post

Ok! I decided to start a weblog to show what I've been working on for a few weeks. I'm still at an early stage but progress is steady so hopefully there will be lots to update this work log with. Whilst the underlying engine and game logic are progressing very nicely, I'm still working with a designer for all the assets, so everything you see is a stand in.

So what am I making? Isomer is a world exploration slash realtime strategy slash survival game presented in a retro isometric style. In terms of influences, the isometric look and combat feel is heavily inspired by the classic XCOM games with a hint of Dungeon Keeper, Minecraft and Project Zomboid thrown in.

The idea is to present huge (possibly infinite later) procedurally generated worlds that the player is dropped on to along with their dropship. This is a oneway trip and whilst mined resources can be exchanged periodically with passing transports and reinforcements beamed down, the challenge is to secure the area around the dropship, survive, build and explore the world collecting resources and battling hostile aliens.

Currently implemented:
- procedural terrain generation
- different world types
- friendly, neutral and hostile entities
- basic path finding
- mining resources
- saving/loading games
- dropship deployment and game over conditions (if aliens manage to destroy dropship)
- Combat
- Building blocks and structures
- Trading resources with passing supply ships and troop reinforcements
- Alien and neutral AI
- Explosions and fire

On the to do list:
- Day/night cycles (including combat and unit perception modifiers)
- Weather (including combat and unit perception modifiers)
- Unit movement and mining animation
- Probably other stuff too

Currently I am working on this full time and my goal is to get all the basic elements working before releasing a 1.0 version. If there is a good level of interest and I manage to sell a few copies then I will continue adding features from my 'nice to have list' along with suggestions from the community.

Although I've been working as a software developer for a number of years this will be my first indie game that I'm hoping to release, so any feedback is gratefully received! I hope to update this worklog on a roughly weekly basis to show my progress.

Some early screenshots with stand in art assests:


Mining example


Dropship placeholder prefab


Example of underground structures procedurally generated

I like the style, but ... is it just me or is the perspective on some of those screenshots a bit funky? Some tiles on 2nd and 3rd screenshots seem to have illusory perspective (I'm not sure if that's intentional?).

Anyway, wishing you luck.  

Thanks! The prospective can look a little funny sometimes in single screenshots when dealing with multiple levels. On my to-do list is the addition of lighting and layer shading which hopefully will address this properly. When looking around the world moving up and down the levels makes it easier to see what is going on.

[K1lo]

Small update today from me. Unfortunately I lost a couple of hours implementing optional walls and floors to existing world blocks. Once I got it working and tested it in game it didn't look or feel right which is a shame.

Still, in the process the surrounding code got a bit of scrutiny and a couple of bugs were squashed. Otherwise I added a few new sprites to the dropship and added lift pads, these will form the basis of compact vertical movement within ships and structures as well as being where reinforcements are transported down to.



That's it for today. 

[zalzane]

I highly recommend applying a darkness filter or something for 'levels' you aren't currently on. What you have in the screenshot is good, but it would be much better if the levels you aren't on were faded black so that you don't get them confused with the level youre currently on

[K1lo]

I completely agree with you, I'm not sure fading levels that are not active will work as well for the world outside though .. this something I will need to experiment with I think.

I was rather hoping when I finished implementing lighting the levels would be easier to distinguish but we'll see. 

[pluckyporcupine]

When I look at it, what looks funny to me is that there are only outlines on sides that aren't connected to other blocks and are on the top of the block, and even then, only on some. So when I look at it, my mind isn't making the distinction between the side of the block and the block diagonally below that block, it's probably looking for a black line to make a distinction, so it kind of looks like the different levels are blending together.

Without that line, everything would probably blend together due to the "soft" look of the textures, but as-is, you should probably make sure there's a complete outline on all sides to help distinguish due to the angle.

I cut out a small piece of a picture that kind of highlights what I'm talking about below.



In that, you can clearly see the bounds of all of the blocks shown, but it's a bit difficult to distinguish what is what.

You can also see some of what I'm talking about right at the center of the PNG showing the different levels.

EDIT: More lighting might do the trick, yeah.

[K1lo]

When I look at it, what looks funny to me is that there are only outlines on sides that aren't connected to other blocks and are on the top of the block, and even then, only on some.

The outlines I only added to the top back left and right of z level isolated blocks in order to distinguish levels when looking into depressions in the world.



So in the screenshot above it is easy to see beyond the ridge is a section which is lower. Before this it was really hard to see this level distinction.

So when I look at it, my mind isn't making the distinction between the side of the block and the block diagonally below that block, it's probably looking for a black line to make a distinction, so it kind of looks like the different levels are blending together.

Without that line, everything would probably blend together due to the "soft" look of the textures, but as-is, you should probably make sure there's a complete outline on all sides to help distinguish due to the angle.

I completely agree, the more I look at this the more I think there should be a full outline on the exposed top and bottom of each block to make it clear what is going on. Thanks for the input

[K1lo]

First weekly round-up time! 

After resisting the urge to just dump out my commit comments, I had a look at the revisions for this week and by far the biggest change has been in pathfinding. I've added A* pathfinding to the game and it is great to see characters moving around and through obstacles rather than just bumping into things as they did with the previous placeholder pathfinding code.



It did involve pouring over a fair few outputs like this from my pathfinding test harness though



Lots of cosmetic changes and bug fixes too, for once I've managed to cross off more things from the to-do list than I've added, so I'm chalking up this week as a win! 

[Bandreus]

In my humble opinion, you should try to think hard about what you want the game to be exactly about (or tell us if you have decided about it already ).

I see a lot of vague concepts being thrown together for good measure, but very little in terms of a clear direction for the game. Designing and working out lots of things at once might be overwhelming in the long run, unless you have a very strong vision for the project right from the get go and lots of experience making games (and even then, it might still cause issues).

Please, do not think I'm being harsh or anything. I just think you might want to focus and define a good and solid core for your game, especially since it's your first 'serious' indie project. They say it is much simpler (and time-efficient) when you define and flesh out a very limited but clear scope for a game idea, even if that means you end up adding stuff or even dramatically changing your initial concept at a later date.

You might want to make your mind about simple stuff like:
- What's the the player's purpose/goal? (save the princess, retrieve yendor, etc.)
- What are the main game mechanics the game will be about? (hint: the less and the simpler the better. Better focus on a few core mechanics first, you will always be able to add more later on as you see fit)
- What kind of challenges the player needs to face and ultimately overcome? Is the player opposing a specific bad due or faction? Is the player just opposing the environment (and its denizens)?
- I get you have already considered lose conditions. How does the player win the game? Can the game be won at all? If that's the case, how? If the game cannot be beaten, does the player have any strong incentive pushing him to play the game indefinitely?

That's only one of many approaches, but the main point here is trying to establish a very clear core experience for the game, in order for you to be able to develop for and iterate over it in a more agile fashion.

For instance, you might want to cut on any feature which aren't absolutely necessary to fully appreciate the core of your game. As an example, you might want to completely ignore weather, day/night cycles and all that good jazz, at least at in the prototyping stage, if those don't have a key role in how the game works at its most basic level.

If weather only influences combat and other things by altering a few variables to some neglectable degree only, then don't bother with it until the core of the game is solid enough. As a counter-example, the lighting system in Chroma end up playing a crucial role in how its gameplay works.

- Mock-ups and quick and dirty prototypes might still be a good way to get a feeling of how you want different things to look and work in the game. But as long as coding-in new features and producing assets go, stick to what's most important first. -

Focus on what's absolutely important for your game, add the rest later. If you think a lot of different elements all equally play a role in Isomer, find ways to cut those down and have the game focus on only a few of them instead. Design by subtraction first, add more stuff in later on.

You might very well just ignore all of this nonsense, or maybe I'm just offending your intelligence cause of lack of knowledge about you and the project on my side. If that's the case, I beg your pardon in advance!

Cheers and good work

[Chris Polus]

...I just think you might want to focus and define a good and solid core for your game, especially since it's your first 'serious' indie project. They say it is much simpler (and time-efficient) when you define and flesh out a very limited but clear scope for a game idea, even if that means you end up adding stuff or even dramatically changing your initial concept at a later date.

I can only second Bandreus' thoughts. In our project, we're also fighting with feature creep It's important to focus on the most important things first and make them fun to play, then add the eye candy and more atmosphere. We defined an area of the game and only create what's necessary there for the first chapter of the game. Only the necessary spells, only the necessary animations and creatures. Everything else we can do once we have this first part really polished.

I don't know why that is, it seems everybody needs to go through that phase once, the valley of tears, hehe, and experience this for themselves. I guess that's just part of it. I read so much about keeping the scope down, but in the end I think our scope is far too big for our first game. But we're a bigger team (currently about 15) so I hope that'll help. We'll see how it comes out.

Good luck! And if anything, keep at it. If continuing the game becomes a habit that's good. Otherwise there's too much distraction.

[K1lo]

In my humble opinion, you should try to think hard about what you want the game to be exactly about (or tell us if you have decided about it already ).

I see a lot of vague concepts being thrown together for good measure, but very little in terms of a clear direction for the game. Designing and working out lots of things at once might be overwhelming in the long run, unless you have a very strong vision for the project right from the get go and lots of experience making games (and even then, it might still cause issues).

Hi Bandreus, although I have now drastically simplified the core ideas in the interests of actually getting it done within the timeline I have set myself, a lot of the initial vagueness in project direction arouse from me prototyping lots of ideas inside the evolving shell of Isomer. I don't think I've really explained the overall idea properly up to now - my fault, a pitfall of working as the solo developer I think

It is quite tempting to fiddle with direction or add features as you go along, so I tried to do all this early on and I think for the most part it was a good way to go. After a fair amount of fiddling I ended up drastically simplifying the core ideas and cutting back on elements which were not essential, although some have made it on my 'nice to have' list which I'd like to revisit after releasing the 1.0. That said, these 'nice-to-haves' don't fundamentally alter the core game, they just add a little more depth both in mechanics and in the environment.

So let me describe the direction I'd like to take Isomer in. I want to create something that is both open ended to appeal to more creative gamers whilst also providing a concrete set objectives and aims. When a new world is generated and a player dropped along with their troops, the choice is theirs whether they begin fortifying their position or whether they start exploring the world. The aggressiveness of the enemy will up to a point depend on the actions of the player: whether they are aggressively securing resources and attacking hostile installations or focusing more on exploration and development. In each world there will be hostile bases, some hidden and some rather fortified but it is down to the player whether they want to raid them and how. If they manage to destroy the power core of the primary hostile installation (when they find it), they 'win' the game. If the hostiles manage to destroy the player's dropship power core the game is over without the option to reload.

In order to achieve this, the main mechanics involve defending the dropship you start with, keeping your troops alive (and enhancing their abilities), hunting for resources to build defences or equipment (or trade with passing supply ships for extra troops and equipment), exploring the world to destroy hostile outposts and bases.

Please, do not think I'm being harsh or anything. I just think you might want to focus and define a good and solid core for your game, especially since it's your first 'serious' indie project. They say it is much simpler (and time-efficient) when you define and flesh out a very limited but clear scope for a game idea, even if that means you end up adding stuff or even dramatically changing your initial concept at a later date.

No not at all, I really appreciate you taking the time to give me honest feedback and pointers 

That's only one of many approaches, but the main point here is trying to establish a very clear core experience for the game, in order for you to be able to develop for and iterate over it in a more agile fashion.

Funny you should mention agile, it is probably rather overkill for a single developer project but I've broken down all the tasks into incremental goals and allocated them to various milestones. I've found in the past if I try to get everything perfect right from the start I grind to a halt under the weight of all the outstanding tasks. Consequently I've been focusing on getting everything I can working even if it is only partially functional to get a feel for how things are fitting together. Plus it's fun and motivating to be able to play with the cool stuff that's there already even if it is a rough early draft. Taking this approach has let me evolve and refine my overall idea too which is a good thing.

Cheers for the input  

[K1lo]

I don't know why that is, it seems everybody needs to go through that phase once, the valley of tears, hehe, and experience this for themselves.

Eghhh, yes I've come across this when working in the industry before. Managing upwards doesn't work all the time .. 

I read so much about keeping the scope down, but in the end I think our scope is far too big for our first game. But we're a bigger team (currently about 15) so I hope that'll help. We'll see how it comes out.

Tell me about, in retrospective I think I'd have prefered to tackle one of my smaller scoped game ideas first but hey, a trial by fire if you will. I always seem to throw myself in at the deeper end 

Good luck! And if anything, keep at it. If continuing the game becomes a habit that's good. Otherwise there's too much distraction.

Thanks! Yes, I'm determined for better or for worse to finish Isomer before moving on to future projects. I'm keeping my fingers crossed that the final game is sufficient to plaster over my inevitable rookie mistakes along the way - the coding is the easy part

[verticalvertex]

Looks good, but I would like some more images of the procedural terrain generation.

[Chris Polus]

Tell me about, in retrospective I think I'd have prefered to tackle one of my smaller scoped game ideas first but hey, a trial by fire if you will. I always seem to throw myself in at the deeper end 

Same here, same here We'll never learn.

Thanks! Yes, I'm determined for better or for worse to finish Isomer before moving on to future projects. I'm keeping my fingers crossed that the final game is sufficient to plaster over my inevitable rookie mistakes along the way - the coding is the easy part

True thing. We're actually thinking of breaking out one aspect of the game and make a smaller separate pet project to have something that's finishable in less time just to get some experience with publishing and getting our name out. We'll see.

[K1lo]

Looks good, but I would like some more images of the procedural terrain generation.

Once I figure out how to stitch a number of screenshots together properly I'll post something, I just tried using Autostitch but didn't get too far , the result was amusing though..



The worlds are so big it's quite difficult to really show them off without taking a huge number of screenshots and creating a large image from them. The only other idea I have is to record the game panning through a section of land and upload it to youtube...

I'll see if I can find a better utility, I'd really like to create a couple of zoomed out  map style images - but doing this by hand for (literally) hundreds of screenshots from a single world would be a real pain.

[K1lo]

True thing. We're actually thinking of breaking out one aspect of the game and make a smaller separate pet project to have something that's finishable in less time just to get some experience with publishing and getting our name out. We'll see.

Test runs are always good, I guess it would depend on the type of game and platform but it sounds like a good idea.  

[K1lo]

The last couple of days have been quite busy, however as a result early combat mechanics are now in place. Entities can shoot at (with appropriate LOS checks), do damage and kill each other. Lots of polish still required (including calculating alternative laser paths for shots that miss) but I'm pleased with the progress.

Here's a screenshot of one of the shooting galleries I used for testing, poor creatures . Oh and ignore the "Missed" text, each entity has the ability to say things and this is going to be used in the final game however for now it's a handy way of debugging their states  

EDIT: Oh, I forgot to mention I made changes to the way in which the world is rendered in order to hopefully address the prospective issues raised earlier in this thread. Here is a layer by layer chunk of the world from the bottom to a layer above the dropship. I think this is about as clear as I can make it before the lighting code goes in.

[Chris Polus]

Hehe, K1lo, consider to post your failed panorama shot in the "Beautiful Fails" post, hehe.
http://forums.tigsource.com/index.php?topic=26727.0

 

[K1lo]

Hehe, K1lo, consider to post your failed panorama shot in the "Beautiful Fails" post, hehe.
http://forums.tigsource.com/index.php?topic=26727.0

 

Ha! I was looking for that thread - I was sure I'd seen one on this forum but I couldn't remember what it was called