Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

TheGrandestine

14
Posts
3
Topics
8
Followers
A member registered Jan 20, 2019 · View creator page →

Creator of

Recent community posts

(1 edit)

I will have to get a working phone before making any claims about the game working on a phone.
my current phone is an iphone 6s, which fits its name with a 6sec battery life. 
meanwhile I have 3 monitors on my desktop.

I am not exactly opposed to mobile versions of things but I have a bias towards extreme complexity and I think that phones inevitably promote the opposite of that by squishing everything into a little box, so, I tend to think of phone games as less inspiring in a way. I would actually like to have the game at higher UI resolution scale with even more info on the screen but I think on a phone the text would start to be too small to even read if it wasn't already.  Probably would have to have a totally new UI design in order for the game to make sense on a phone, similar to how so many websites become mobile-confined or need multiple versions.

shorthand for how I feel:  ~"diablo on a phone?" 
the phone itself imposes design simplification

oh, just to be clear I only abstain from keyboard controls being 'required', which means any/all ideas for QoL keyboard shortcuts are still on the table as viable (and in theory could show up in settings eventually), I just want to avoid a scenario where certain functionality is gated behind keyboard and mandates tutorial instructions for what keys to press or w/e. 

also the toggle workers on/off I consider a minor 'expoit', not really the intended mechanic (need to be able to salvage existing buildings at some point, but before you could permanently brick your own city by building too much of something so the disable toggle was added to prevent that). Disable is also somewhat placeholder, which shows from events disabling a building and you can just enable it again immediately. The actual disable mechanic is supposed to have a little cooldown wheel with dynamic duration, which would mitigate some of the awkward toggle behaviors, make various events more impactful, and allow traits/tech for recovery speeds.

anyway I have a backlog of things to sort through and some other projects starting to divide my attention, but I'll keep these things in mind along the way. At the very least, I would like to add favorites/hidden toggles/filters to the building list at some point, which I did not plan on adding before. I'll probably try to squeeze in a little heart outline and [x] to the building info cards somewhere and use something like the ruins filter to show/hide them (have to be able to show hidden in-case of misclick or mistake). 

mid-run saves vaguely work now, from the latest version (although still need to improve it)
settings I have only a few notes about and will probably wait a while longer to add them. 

military is likely to scale even more in terms of variety and skill expression (ex: tons of specialized units in army building, more tactics, more upgrades variety, more traits, leader on the battlefield, raid boss style threats, white/black teams from affinity, more city stats affecting unit stats and military stat, more intricate triggers for invasion events, more ways to handle them, etc.) so the current form is only vaguely balanced in anticipation of that (currently working on connectivity/morale stats which can affect military, for example).  It might be that I know all the details ahead of time, but it currently feels way too easy, so with more variety it would also require more threats. 

I was also theorycrafting ways to scale building variety without having an endless front-loaded wall of buildings and have designed a vague notion of a blueprints mechanic that would allow naturally forming available building selection to some degree (ex: imagine there are 999 different buildings, and you have to de-select all the ones you don't want rather than drafting ones you do). I'm not sure how the details of blueprints work exactly, and I'm not even sure that I prefer it that way since personally I enjoy the giant megawall of options approach, but it's on the table for another game system similar to prefabs except unlocking new building types (one issue is that balance of progress becomes 10x more complicated if everyone has different building options). I like favorites/hidden or even changing the ordering of things, but not sure yet how the actual implementation would look (prefer not to have keyboard controls required, even if optional ones are added later)

idk if I'll do that yet... stats are the basis of everything else so for today I have been thinking a lot about how to theme more stats, what kinds of influence/scaling they could have, and what level of viability each one has in combination with the doors it opens. ex: connectivity allows concepts like transport/roads to be a part of the city without hijacking some other arbitrary stat. small city has high connectivity by default, and the larger it becomes the more roads/transport are needed to keep the stat high, making the 'spam small buildings' approach less overpowered in an indirect way. Morale has some similar balance impacts, scaling its value from victory/defeat or positive/negative events, which alters the value of all other event chance scaling and makes perpetual defeat-rebuild form of progress reflected in the city stats through morale/trust. This is the synopsis version of what these stats do, so they are taking a while to sort out. (currently involves stat itself, influence mesh, research, icons sync, character trait, governance, events, buildings, etc.)  

with connectivity/morale and more the game becomes even harder, so I'm starting to consider some kind of casual mode, or eventually distributing complexity across ascension tiers. The thing about these city stats is they do not always help you. They are good at high values and bad or neutral at low values, so the more of them there are the more intractable it becomes to have all of them high, which inevitably results in a complex series of pro/con influences. So, while I have no desire to pull any punches or simplify anything, it might be unreasonable to have the most complicated version be the only available option.

It is likely to become an absurd learning curve, if it isn't already. 
(some of this is 'note to self')

(1 edit)

sorry about the automod thing hiding your post, I didn't see it until now. 

Since it was a few days ago, some of this has changed, but I'll take a pass over it for relevant insights along the way. In particular, the military units/scaling/invasions/etc I still view as a prototype, and the balance of individual stat scaling is also valid to call into question. 

I like the idea of having a choice in how to approach a combat scenario, adding more QoL for buildings list (enable/disable is already improved), and some kind of 'favorites/hidden' tags to extend filtering options. I'll think about it more, good notes, thanks.

(3 edits)

I'm glad, thanks. Not sure how long I can keep up the current hyperfocus pace of updating almost every day since I will inevitably get distracted working on another project, but for now here are some vague ideas/synopsis of where it is going: 

- standard 'obvious' things like iterating game balance, UI, QoL, tooltips, settings, saves, and boring tech stuff

- more interlacing system expansions with tendency towards modular scaling lists of things derived from each other

- actual scaling of all proof of concept systems (more stats/resources/buildings/events/units/traits/upgrades/etc.)

- more incentive structures for archetypes, like a mercenary system that uses credits/hr or blueprints from research

- more important leader character/customization, such as having presence in battles, autocast cooldowns, attributes that can influence combat or city performance, and perhaps some kind of leader mastery system that accumulates bonuses across every other system

- dynamic unbounded achievements as an excuse to track infinite stats and incentives to chase higher achievement values with some kind of trophy-point system that accumulates small bonuses based on total achievement points, while being completely adversarial to 'completionist' mindset (in other words: it never ends)

-  some random excuse to add pie charts and graphs somewhere for no discernible reason

- maybe a desktop version (seems possible but managing both for each version could slow updates down a lot)

- probably more if I keep working on it for a while / these are just a few things that come to mind

most notably, I consider the various modular systems as multipliers onto each other, so eventually adding a single new building is a multiplier across 100s of strategies compared to having it in isolation in an earlier version of the game (in a similar way, adding a new city stat like 'health' has had a multiplier effect, allowing the stat on buildings, research, traits, calculations, events, buff/debuff statuses, etc.)

it seems like having tons of event variety would be more interesting that seeing some of them repeat, and I am tempted to add 999 different buildings filtered through a blueprints system or something like that, if only the variety of stats/effects/combinations/themes could handle it (probably could add like 50 more already with current stats, but at a certain threshold the namespace and variety becomes limited).

...oh,
- maybe eventually the game could have a learning curve design where ascension tiers gate some of the complexity so that casual players don't run into a brick wall of endless stats as soon as they start the game. I have no real desire to simplify anything, but this might be an incentive for reaching higher difficulties (although it makes overall game balance 10x more complicated in a way).  

(2 edits)

according to the game's design theory, any best way to beat the ascension tiers would be complex to explain since that would envelop the full spectrum of understanding across every system and how they all interact (not to be pedantic, but 'best way' is a strong phrase from my perspective). 

Aside from that, the military/invasions systems are still relatively new and probably too extreme in terms of their unique capacity to destroy an entire city over time, so the general advice of building a city with a military focus might be the safest approach to attempting ascension.
(for example, some invasions are still overtuned, some are too frequent, some are too punishing, etc.) 

for save data, I wrote about it here: about save data: why it wasn't added yet - gCity - itch.io
basically, mid-run saves would most likely slow down expansion style updates a lot
(but ascension save data seems viable so I will look into adding that)

edit: Prefabs, balance, UI, military overhaul, ascension saves, etc.
I consider this a 'better than nothing' level of save data for now.

(1 edit)

a lot of what I am doing for this project centers around closing the gap between design/iteration/update by removing various points of friction such as hijacking emojis for icons, using custom converter tools, or designing/architecting game systems in a modular way (ex: stats, buildings, events, research, traits, artifacts, governance, military units/upgrades, character classes/packages, and more- can all be expanded in a modular way).

This has allowed an extreme pace of iteration averaging around 1 expansive multifaceted update per day, but it also comes with certain downsides, and one of those is that the 'zero friction' approach is antithetical to having mid-run saves and migrating older save files to new versions along the way. In theory this is technically possible, but at a surface level it is likely to create all kinds of technical limitations and backtracking to micromanage the conversion process of older save files into updated versions of the game, so I have at some point decided to just ignore it in favor of the actual updates - if each update required consideration of old save files, then there would be less of them overall. 

This means the mid-run saves accounting for individual buildings, temp effects, stats, research, traits, etc. are less likely to show up any time soon compared to something like saving overall ascension progression. I am not especially familiar with how the save data will operate in a 'webgame' environment, other than experience in flash in the past where something like clearing browser cache could wipe save data for all flash games at once, and I cannot say for sure if there will be a clean solution to that here, but I will try to add 'something' so that it isn't completely devoid of any save functionality, and if I find an elegant abstraction to save mid-run without needing to micromanage it constantly for every update then that might be added at some point too. 

Since the game balance has changed so drastically across updates, the lack of save data could be seen similar to the way some games will have a new server or reset between seasons or whatever, just on a much shorter time scale. The current game has most features enabled from ascension0, so as an alleviation to the problem it isn't locking entire systems behind longer term progression (for example, if half the buildings and game systems were unlocked after certain ascension tiers this would be a much larger issue overall)

tldr:
micromanaging backwards compatibility of save data migration threatens to stifle updates and design freedom so I haven't even tried to add mid-run saves yet, but saving ascension tier progress seems more viable so I will look into it.  

edit: deepscan savestates, ascension fanfare, balance pass, UI/QoL, tactics, etc. - gCity - planetary city survival sim by TheGrandestine

I agree- the rivals are overtuned and were vaguely intended as a diplomacy incentive but still need a ton of work in order for that to make any sense. The massive difference in their difficulty is likely because they have higher range than the default player soldiers, especially higher than player militia. With military stat improved and soldiers, the soldier vs infantry is only like a 5% difference in range, which sounds fine on paper but in practice it snowballs and becomes unstoppable. 

underlying problem is that longer range essentially becomes 'first strike' and then the units on the winning side pile into a DPS wall (ally units also do this against some short range enemy types which is the same issue reversed, often making it too easy regardless of their other stats).  I would like to allow higher attack range diversity but it probably requires higher health or some kind of unit positioning adjustment which could make the battles longer. I would be ok with longer battles but only if the battles were more intricate (leader abilities, cooldowns, tactical military decisions, etc).

Thematically none of the current invasion teams are the most dangerous, but the ravenous swarm against pollution/affinity is supposed to be pretty high on that list. There is also some possibility that making player units move faster could help, but in either case the invasions are a narrow skill expression until some form of complexity is attached, so it needs more than just the balance I think. 

In an ideal situation, a person complaining 'X team is way too hard' could be told "that's a skill issue". 
no amount of balancing is intended to make the game 'easy', but it isn't intended to be a brick wall either.
(random note: response doubles as my personal notepad - invasions should become a very important feature)


done: UI, filters, overviews, QoL, bugfixes, etc. - gCity - by TheGrandestine


something like this will be added to character traits (and global research tech)

the UI is a little wacky and probably not intuitive, since the numbers at the top are the 'X/day' numbers.
I guess I have just seen it that way for so long that it already made sense and forgot, but the game used to process on a per-day scale until realizing concepts like solar panel oscillations were impossible without faster tick rates themed as x/hr. 

the per day thing is baked into my foundational view of the game so I have to mentally detach from it. One problem you reveal is that there is a constant estimation/conversion process converting from hr/day for production/upkeep. so probably the top bar should show x/hr like everything else in order to be intuitive (maybe I will add per day value in settings for my own view).

workers are a problem early in general (probably need a flat bonus to how fast workers join)

building UI search bar can find some embedded info like production rates but it needs a mouse-only version of that like little filtering/sorting buttons near search, or if you click the top bar resource icon to auto-search for that production

search limitation is how typing 'energy' will find descriptions saying "does not require energy".
(realistically many descriptions/tooltips are redundant from older lack of UI in various places)

It seems like selecting a community hub forum format for a game page supersedes the ability for people to comment, and the 'create new post' connotation is a barrier to entry that places a vice around what can be said by sensible people.

in that case, feel free to use this thread as a dedicated 'random comments' area

as noted on the game page (at the time of writing this), there are possibilities of different browsers/plugins/etc causing overtly janky/broken looking things that you can see but I cannot. If you encounter anything like that (garbled UI, something overlaps, spazzing fonts, flickering elements, objects scaling out of bounds, etc), feel free to complain about it somewhere. 

an example of this is that the game uses emoji icons for visual anchors, but different people will load different emojis in different environments, creating weird situations where certain icons are using 2 emojis instead of one, or simply making the used icon look weird for what it is (in general they should be vaguely relevant, but mine are way cooler) 

realistically, idk how many of these 'compatibility issues' I care to solve compared to just making a more badass game, but if the information about what is broken is laying around already then it's a lot more likely that I get around to fixing it at some point.