Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kyzrati]

Gee, thanks guys!

Once you get to the point where you want more players/exposure, you should do another contest for players like you did at the beginning.

And I'm not just saying that because I want to sweep several more award categories. 

HA, I am totally going to do that again, because we all had a lot of fun with it (besides, it's good marketing!). The after action report has already tripled in size, so there's a lot more data to create awards from.

This time around maybe I should create a specific award for "Earned More Awards Than EuchreJack" and give it to everyone who manages to pull off that feat

[EuchreJack]

Gee, thanks guys!

Once you get to the point where you want more players/exposure, you should do another contest for players like you did at the beginning.

And I'm not just saying that because I want to sweep several more award categories. 

HA, I am totally going to do that again, because we all had a lot of fun with it (besides, it's good marketing!). The after action report has already tripled in size, so there's a lot more data to create awards from.

This time around maybe I should create a specific award for "Earned More Awards Than EuchreJack" and give it to everyone who manages to pull off that feat

Challenge accepted!

[Kyzrati]

Anyone who played the 7DRL (many of the people following this thread, no doubt) will be familiar with this list:

Spoiler: PARTS! (click to show/hide)

It's going to be completely redone (with a lot more thought put into it), especially given all the new mechanics.

This is from the latest post on data-driven development.


Edit: Might as well throw this up here, too, a gif of a point defense utility in action (one mechanic I was just working on today):

Spoiler: Shooting down an incoming volley of missiles (click to show/hide)

I've already covered all the new propulsion and weapon mechanics on the blog before, but only just now working on implementing new utility mechanics. These are the interesting features that take a bit more work and therefore never made it into the 7DRL, stuff like point defense systems, remote shields, mobile recycling units, drone bays, plus a bunch of other more "mundane" additions that tweak existing variables. Ah, one implemented idea was a suggestion from the 7DRL thread: A utility that cannibalizes damaged/broken parts to partially repair others of the same type.

[tompliss]

Point defence is only personnal, right ?
Or would it be possible to have an ally specialized in destroying missiles while you attack enemies ?

[Kyzrati]

It's most certainly not limited to yourself! In keeping with the theme *every* unique ability is enabled by a part, so if you attach the part (and activate it) then you can do it, otherwise... nope. Enemies and allies alike can have a point defense system. In the 7DRL, actually *no* enemy was equipped with missile weapons so it would be completely useless there. Missiles are quite dangerous but there will be at least one type of enemy that carries them in the new game. You probably won't be aching for an anti-missile system in most cases though. I added them to the game mostly for certain enemies, since you're the one usually blasting away with rockets and missiles

[Kyzrati]

Long-ish design-oriented post about the player character himself: Cogmind.

[Kyzrati]

Working on the item list now. Posted an overview of the item types and many sub-types. A few of the sub-types are new since the 7DRL, but the core item list is very similar (I think the original played out pretty well).

[Kyzrati]

I made some joke box art to go along with the latest post about devs playing their own game:



Some of the content talks about tweaks being made to the part data since 7DRL. Hovering and flying will be a lot more viable (if you recall, they were virtually impossible before).

[sambojin]

I'm so looking forward to the day we can play your full game. I might have to jump in quickly to the 7drl for a bit and refresh myself so I can pip an award or two when the time comes.

Cogmind has come so far. From being a 7drl based off the x@com engine to being your major project, I can't really see how this won't be successful. I dare say that there's plenty of people that give this post a read from time to time, just waiting for an inkling of a release schedule. It's probably not as easy for people to give opinions/input/feedback on something like Cogmind as opposed to x@com, but we will in time. It looks like you've already got an excellent roadmap planned out, now it's just hard work and time. I'm looking forward to seeing what you do with the content and areas. The basic (or not-so-basic) mechanics sound like they're coming together really well.

Anyway, keep up the good work Kyzrati

[Kyzrati]

I remember last year... or year before last, I forget which, flight units were near-useless. They allowed you to have, at most, a gun and a light reactor.

Yep (year before last... been a while ), they weren't balanced properly and only predefined enemies could use them effectively.

Hover will be a *lot* more usable now, and generally your best "fast" option. Yesterday I played a game relying mostly on hovering, maintaining a supply of hover units by downing programmers. It'll be an option to seriously consider now since treads and legs have been slowed.

Full flight will be possible, but still often limiting in terms of mass support, as it should be. The problem before was that your average power source generated just enough power for the flight units required to support them, so you couldn't do much else effectively. I added those light versions of reactors and weaker weapons specifically for flight-capable enemies, but for Cogmind they're not good enough since you can carry so many parts by comparison. Now you'll be able to support more parts, but an effective flying build will probably require stealth-related parts like ECM to escape combat more easily, unless you have allies to fight for you.

Anyway, keep up the good work Kyzrati

Thanks sambojin! Haven't seen you around for a while. This game's going to put the 7DRL to shame. You'll definitely recognize a lot of the parts and general gameplay, but with dozens of robot classes, larger maps, and a whole slew of themed side branches to explore... I can't wait!

I'd like to give a more specific release schedule, but I need to get past the initial content development stage to reach the point where the game's ready for a sprite version and soundtrack. Not feeling rushed just yet is a good thing because that means better quality.

The first public release will come some time this year.

I'm sure it'll be "successful" in that the target audience will enjoy it, but not necessarily in the business sense. It is rather niche, after all We'll see. I don't mind making the investment even if there's no profit at the end--just something I want to do!

Now back to adding parts...

[sambojin]

Actually, speaking of sprites, any clues to the format you'll be using for tilesets? I know it's graphical ascii, but dimensions of sprites/effects available/animatebility(I know it's probably not a word), etc would be handy. You know my love of "projects-I'll-never-complete", but mucking around in the x@com engine was fun. The range of Cogmind's underlying engine should be just as good to play around with to see what can be represented in a stylistic sense. Will this have moddable graphics/effects in the long-term?

It might prick a few other ears up to the game if that's the case.

edit: although I do understand if graphics mods aren't on the list of moddable items. It's better to have a clear cut goal to achieve rather than wasting time on not regularly used bells and whistles. I'd rather a good release than features "for my own amusement". I think that x@com may have been bogged down by this (amongst other issues), but fortunately Cogmind will be the better for it because it's a similar engine. But maybe "every goddamned feature" shouldn't be a priority.

[Kyzrati]

Not to provide you with another of those "projects you'll never complete" , but yes, Cogmind will be fairly moddable.

Probably not quite as extensible as what X@COM provides, mostly because how the world is generated and some story-related encounters will be somewhat hard coded. Other than that you can of course add/change robots, parts, sounds, animations, art, and some mechanics. I'm not focusing too much on making the game extremely moddable, but it happens to be that way because of how I develop games.

The sprites I mention will use the same style as the 7DRL: re-colorable monochrome icons with support for alpha transparency. I plan to include 10x10, 12x12, and 16x16--at least that's the tentative plan because I would have to talk it over with the (yet to be searched for) artist.

[sambojin]

Cool. I'll have a play with the 7drl and see how it goes. The grey-scale->coloured style gives it a fairly unique look, even the ascii version of it.

With transparencies, I'd recommend having each tile type being able to be a two or three layer composite graphic. It just makes it easy to add effects (flyers, different door/wall types etc) and adds some variation to enemies that is easily recognizable. Red body layer with green weapons? It's a tough cannon wielder. Plenty of different body/weapon/effects tiles to fit lots of enemies, but easy identification is a good thing. It also fits into the "build up" nature of the game, as well as giving easier colouration options (each layer doesn't have to be colored the same, letting colour coded enemies be a thing in both the graphical and ascii version, without excessive spriting to be done). Ten different base, weapon and effect tiles that mesh well and can be independently coloured might be easier to do than twenty different enemy tiles that are grey-scale coloured for enemy variation.

It's probably just my fascination with paperdoll spriting though (damn you DCSS). Whatever's easier on the artist and fits the aesthetic is the best way

[Kyzrati]

I, too, have the same fascination with paper doll sprites, *also* after playing with the DCSS set! Hehe. I even doubled the size of the DCSS set with my own pixel art some years ago for a game I was working on but never released.

Maybe one day I'd add layering, but it doesn't fit in with the whole "emulated terminal" architecture of the engine, which doesn't have a way to hold enough information for displaying anything more than a single image. Not impossible to do, but it would definitely get slower.

In terms of enemies they always have the same loadout for a given class variant, so it's not too essential to add paper doll visuals there. For Cogmind himself the concept is sound, but you can eventually add so many parts of so many types that it's not too meaningful.

[sambojin]

Yeah. I'd leave Cogmind as the ever useful @ symbol. I don't know if it would be too hard on the CPU doing a layered paperdoll. You could even mesh the layers together at startup, with the 3 pieces taken from the raw-file enemy descriptions, and add rotations and all, dump them in memory as specific enemy sprites and use them like normal sprites. From a graphics coding standpoint it's pretty simple (says the guy who hasn't coded squat in ten years). A little bit of memory overhead/footprint and startup time, but no actual difference in speed during play. The pieces could all be one colour, but they wouldn't have to be. But if it doesn't fit the style you're going for it'd be pointless. The Cogmind look and feel is already very cool and distinct.

Anyway, it was just a thought. I wasn't sure just how many enemy types and variations you were planning on in the end (there has been some mention of themed branches etc).

I might do a few grey-scale mockups in any case, because I'm not feeling overly active  today. Incidently, I did the same thing with the DCSS sprites, except mine had the same level of "stuff", but with 5 frames of animation for each. Wtf was I thinking? It was SO monotonous.

edit: have you ever noticed how every one of my suggestions, whilst feasible and possibly good, requires extraneous coding that would only slow down project development? Honestly, just ignore them. Iz trying 2 help. Never let me do that