[Kawa]

All you need to know
"At that rate, come up with your own IP." -- Hendricks266
"Challenge accepted." -- me, though not in as few words.

The characters
Rock Sockem - Yet another generic 80's/90's action hero. Basically "Duke in all but name", as opposed to "Duke in name only". Wears a sweater.
Mesa Granada - Player two. Not "the chick", this girl is hard as nails and at least as physically imposing as Rock. Redefines not having time to bleed.
Further characterizations as yet undefined.
The villain - I have no idea

The plan
To somehow get these two in a game or two, be it a Duke2-like platformer (only because of those sprites) and/or a BUILD game (even if it's just a Duke3D mod), so we can honestly say we produced a classic Duke Nukem game without actually having Duke in it.

The progress

• Got an almost-complete spritesheet for Rock, missing only a few frames that Duke had, and a single design sprite for Mesa.
  
• Got the start of a dedicated, classic-like platform game engine in C#, despite my personal fears and doubts holding me back for literally years. Open to rewrites, torch passings, whatever.

(Classic-like: doesn't use Box2D or whatever, but proper entity-to-tile collision detection.)

The pictures



Frisbee. Discuss.

[Micky C]

Looks interesting! You're writing your own engine from scratch?

[Kawa]

I am indeed. Though I'd like to reiterate I'm open to giving that task away.

Now then, who should be the halflife opposing force?

Also, clunky DN2 status frame, Keenish panel in the corner, ye olde bar on the bottom... or option D whatever that is?

Also also, percieved color depth?

[K1n9_Duk3]

Kawa, on 07 December 2016 - 02:19 PM, said:

Also, clunky DN2 status frame, Keenish panel in the corner, ye olde bar on the bottom... or option D whatever that is?

I would prefer floating stats, either at the top or at the bottom of the screen. Let the players see where they are going. The big fat HUD in Duke 1 & 2 had to be used due to technical limitaions. The small game window made drawing faster and "clipping" easier.

[MrFlibble]

Kawa, I quite like your idea, but I think it needs to be pointed out that if you really want to create your own IP, you should start by designing your character completely from scratch. The current Rock Sockem sprites are very obviously edits of the Duke Nukem character from Duke Nukem II. Pretty sure this counts as a derivative work and may constitute copyright infringement.

Also don't forget that Duke Nukem II is a DOS VGA game, hence the sprites are actually taller when viewed in the game with proper aspect ratio. Here's a screenshot of the game in "raw" mode (image size doubled for visibility):


And here's the same screenshot corrected to 640x480 (using the method described here):

It is easily noticeable that in the corrected image, Duke's body is proportional, while in the uncorrected screenshot he's kind of "squished" vertically. Since you most probably intend your game to run in a higher resolution than 320x200, you'll need your sprites to generally correspond to the corrected original image.

[brullov]

To be honest I do not like Duke Nukem 2 at all. The graphics is terrible, my eyes start burning because of this contrast. I can't see where is the main character and where is the background or enemies.

[Micky C]

MrFlibble, on 08 December 2016 - 01:35 AM, said:

you'll need your sprites to generally correspond to the corrected original image.

But shouldn't he leave it as it is if he wants it to be original?

Brullov, I kinda see what you're getting at. I think the art is pretty rad though.

[OpenMaw]

MrFlibble, on 08 December 2016 - 01:35 AM, said:

Kawa, I quite like your idea, but I think it needs to be pointed out that if you really want to create your own IP, you should start by designing your character completely from scratch. The current Rock Sockem sprites are very obviously edits of the Duke Nukem character from Duke Nukem II. Pretty sure this counts as a derivative work and may constitute copyright infringement.

I think they'd lose that battle, considering that the Duke Nukem 2 sprites are derivative.

[Kawa]

To be fair, it does say "concept" in the spritesheet.

[Kawa]

Does this still count as obvious derivative?

[Kawa]

It's just over half infringing now. How's the contrast btw?

[MusicallyInspired]

I like that! Reminds me of Hocus Pocus.

[Kawa]

Thanks. I was thinking btw, as long as they can be held like that, one could have separate weapon sprites. This shotgun, some kind of laser gun, whatever, and the player character would actually visibly hold them. It's a technically easy thing to implement.

Again, though, who has ideas regarding the opponents?

[K1n9_Duk3]

Kawa, on 08 December 2016 - 08:37 AM, said:

Ahh... much better.

And for the enemies: Mutant-Nazi-Robot-Alien-Monster-Zombie-Terrorists. That should cover all the bases.

[Never Forgotten]

K1n9_Duk3, on 08 December 2016 - 03:04 PM, said:

Ahh... much better.

And for the enemies: Mutant-Nazi-Robot-Alien-Monter-Zombie-Terrorists. That should cover all the bases.

Mutant-Nazi-Robot-Alien-Monter-Zombie-Demon-Terrorists... there ya go.

[Kawa]

Okay but seriously?

[Shawneth]

If you're using C# to make this, I wouldn't forking this for a browser version (I use Libgdx) as long as you have good commented code!

[AP Dukefan94]

I'm really surprised. Your concept art looks great.

As for opponent(s):
1) An evil scientist named Dr. Frederick van Atomgetrieben, a nuclear physicist who is out for world domination and creates horrible radioactive minions and nuclear power cell robots.
2) Some sort of mafia type organization. Think of that '90s action movie "Harley Davidson & The Marlboro Man".
3)Zombies-maybe something like "Zombies Ate My Neighbors" on the good'ol Super Nintendo.
4)Mutant gargoyles that resemble Vern from "Rampage World Tour" on the N64.

This has inspired to go back and make concept art, story board, and other stuff for hybrid shooter I thought about since high school. Thanks kawa👍

[Kawa]

I like #1 and #4. Maybe a little of both?

[K1n9_Duk3]

I might be able to help you with the game engine. If this is your first attempt at doing something like this, you'll probably need some help at some point.

You know, this reminds me of a Commander Keen fangame project I got involved in back in 2007/2008. Back then, I had no idea how to write a program that would draw pixels or images to the screen. All I had done before were Delphi GUI applications. Luckily we had somebody who came up with a relatively simple sidescroller demo and shared the source code with us. The code was written in BlitzMax, a programming language I had never heard of before, but I was soon playing around with the codebase, adding debugging output and customizable resolution (the original demo ran in 320x200 pixels in fullscreen mode, which most modern graphics cards don't support anymore). That eventually evolved into KEENGINE, which is still a pretty solid game engine (at least I think it is), even though the fangame it was originally created for still isn't finished.

I learned a lot while working on KEENGINE, both in terms of how to create a side scrolling game engine and in terms of trying to emulate the look and feel of an existing game. Without that, I would not have been able to create ReDuke. And I've learned a lot more about the design of classic DOS platformers since then.

Then again, I was learning by doing. I didn't study game design or game programming or something like that. I'm sure that there are people out there who know a lot more about this stuff than I do.

[Kawa]

It's hardly my first attempt. I had one engine that was just great, made in C with SDL, which I unfortunately lost the code to. It had properly sticky moving platforms for crying out loud! I lost it some time after failing on slopes.

I then switched to C# with XNA, and got fairly far with a second attempt that went to shit trying to fix it. Again, some time during slopes IIRC.

Then I tried a different tack; bitmapped environments with sets of bounding boxes, like a somewhat simplified Box2D setup in some way. Still C#/XNA. Years later, I'd take that and adapt it into a tilemap-based engine.

That was three days ago.

You can understand why I'm reluctant to even consider adding slopes.

Fun fact: I still know how to do moving platforms. Or rather, how to make entities on them stick.

[K1n9_Duk3]

Kawa, on 09 December 2016 - 04:09 PM, said:

You can understand why I'm reluctant to even consider adding slopes.

Yeah, slopes can be a pain in the ass. There are ways around that, though. For example, Hocus Pocus and Duke Nukem II don't have any sloped tiles, but will let the player walk up "stairs", which may look like slopes in-game.

Kawa, on 09 December 2016 - 04:09 PM, said:

Fun fact: I still know how to do moving platforms. Or rather, how to make entities on them stick.

We eventually got support for moving platforms working in KEENGINE. The fact that our implementation used object pointers/references destroyed the savegames at first, but I ended up rewriting the save system to save and restore such references correctly.
(Imagine my reaction when I played Rise of the Triad 2013 and found out it simply won't allow you to quicksave while staning on a moving platform.)

[Kawa]

Obvious solution for saving platform passenger lists: save their indices and make sure you rebuild the primary entity list in the correct order. Like wallpointers in Kenbuild's revolving doors.

[K1n9_Duk3]

Kawa, on 09 December 2016 - 05:31 PM, said:

Obvious solution for saving platform passenger lists: save their indices and make sure you rebuild the primary entity list in the correct order.

That's also pretty much how my implementation works. The same routines were later used for the quicksave/quickload feature in ReDuke (the save system I wrote did a lot more than just keeping references alive).

[Kawa]

Upgrading the sprites continues.

Today, I've been mostly wasting time unsuccessfully trying to find or otherwise implement a post-process shader to apply a given palette to the game screen. That way, one could have translucent sprites without breaking the 8-bit asthetic, like Build can. Luckily, this isn't nearly as important as literally anything else.

Unless you like Gameboy. I can do Gameboy.

[DNSKILL5]

I really like this. I would suggest changing the city backdrop to something else not from DN3D, but that's just a suggestion.

Also for enemies, maybe it could be characters from alternative dimensions that somehow fused together to create a roster of enemies like a medieval knight with an Uzi, and stuff like that lol.

[Kawa]

Tristan, on 10 December 2016 - 10:14 PM, said:

I really like this. I would suggest changing the city backdrop to something else not from DN3D, but that's just a suggestion.

That seems kind of an obvious thing to do.

As for enemies, I was thinking of zombie robots. Just zombie robots. Dead meat animated through technology.

[Player Lin]

Why so many game must has zombie or something undead in it?

[Kawa]

Because it was suggested.

[Kawa]

Well, I got that color grading thing to work. Somewhat. I could probably use a better map (this one seems a bit blurry between cells) but here's a comparison:



I learned a lot here, even if it's ultimately useless.

Edit: using a larger palette map without blurry edges certainly does help! For fun, I put the Virtual Firrhna palette on there -- that's Shadow Warrior with one of the greens replaced with pink, and what I use on the source images -- and changed Rock's opacity to 25%. With no shader, the gray barrel of the gun turns a grayish blue as you'd expect. With the shader enabled, it turns into a light blue not unlike what you might expect Build to do.