Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

999255 Posts in 39205 Topics- by 30615 Members - Latest Member: AlecKelley

April 22, 2014, 11:39:31 PM
TIGSource ForumsFeedbackDevLogsIsomer [XCOM / dwarf fortress / open world sandbox] new build 0.8.4.1
Pages: [1] 2 3 ... 8
Print
Author Topic: Isomer [XCOM / dwarf fortress / open world sandbox] new build 0.8.4.1  (Read 11532 times)
K1lo
Level 1
*



View Profile WWW
« on: September 28, 2012, 08:11:13 AM »


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


Isomer work log


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.




Older images:



« Last Edit: April 04, 2014, 08:46:25 AM by K1lo » Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
impulse9
Level 5
*****



View Profile WWW
« Reply #1 on: September 28, 2012, 01:04:51 PM »

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.  Hand Thumbs Up Left Smiley
Logged

K1lo
Level 1
*



View Profile WWW
« Reply #2 on: September 29, 2012, 02:16:05 AM »

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.  Hand Thumbs Up Left Smiley

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.

« Last Edit: October 07, 2013, 08:10:56 AM by K1lo » Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
K1lo
Level 1
*



View Profile WWW
« Reply #3 on: October 02, 2012, 09:01:45 AM »

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

Isomer worklog
Web: Ionising Software
Doing this game making thing.
zalzane
Level 5
*****


View Profile
« Reply #4 on: October 02, 2012, 09:18:30 AM »



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
Logged
K1lo
Level 1
*



View Profile WWW
« Reply #5 on: October 02, 2012, 09:37:15 AM »

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.  Who, Me?
Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
johnki
Level 8
***


Invisi-wizard


View Profile WWW
« Reply #6 on: October 02, 2012, 04:10:38 PM »

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

K1lo
Level 1
*



View Profile WWW
« Reply #7 on: October 04, 2012, 06:33:22 AM »

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 Smiley
Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
K1lo
Level 1
*



View Profile WWW
« Reply #8 on: October 05, 2012, 05:39:17 AM »

First weekly round-up time!  Smiley

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 Wink



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!  Hand Thumbs Up Left
Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
Bandreus
Level 3
***


View Profile WWW
« Reply #9 on: October 06, 2012, 03:22:27 PM »

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

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 Beer!
Logged

Chris Polus
Level 2
**



View Profile WWW
« Reply #10 on: October 07, 2012, 12:58:14 AM »

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

http://about.me/chrispolus - my website, music, sound design, videos and services.

I'm the
- sound designer of Son of Nor (Devlog) at stillalive studios
- sound designer of the Arcan Chronicles
K1lo
Level 1
*



View Profile WWW
« Reply #11 on: October 08, 2012, 03:03:18 AM »

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

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 Smiley

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 Smiley

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  Hand Thumbs Up Left
« Last Edit: October 08, 2012, 03:12:28 AM by K1lo » Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
K1lo
Level 1
*



View Profile WWW
« Reply #12 on: October 08, 2012, 03:10:40 AM »

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

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  Shrug

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 Wink
Logged

Isomer worklog
Web: Ionising Software
Doing this game making thing.
verticalvertex
Level 1
*



View Profile
« Reply #13 on: October 08, 2012, 04:19:15 AM »

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

It's all good.
Chris Polus
Level 2
**



View Profile WWW
« Reply #14 on: October 08, 2012, 08:55:10 AM »

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  Shrug

Same here, same here Wink 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 Wink

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

http://about.me/chrispolus - my website, music, sound design, videos and services.

I'm the
- sound designer of Son of Nor (Devlog) at stillalive studios
- sound designer of the Arcan Chronicles
Pages: [1] 2 3 ... 8
Print
Jump to:  

Theme orange-lt created by panic