How long would it take you to make a level of your favourite retro game in Unity?

But again, that is my point. The hard part would to make your ´Mario´ jump exactly as high as the original Mario... not to make a clone of Mario that feels exactly the same as the original. Being historically precise is the hard part, making a mario platformer is easy.

 

Oh I agree. And a person could do that purely for the learning experience. But there is always learning involved I think. I don't know how other people develop but for me every game I see as a learning experience even if it is Space Invaders.

Every game project is an opportunity to try out different ways of doing things. Structuring the overall project differently. Handling details differently. Basically always striving to improve.

I guess it all really comes down to how a person approaches a project.

EDIT: This does bring up an interesting point that I think many people don't consider. When they look at very old simplistic retro games I think they often don't recognize the potential such games have for experimenting and improving.

For example, here is a game from 1982...

Based on many posts I've read I think many people look at such games and think there is no sense in making such a thing. No value to be found there. Mainly because they look at it like how can I quickly throw this together as fast as I possibly can and they already have some idea in mind how they would do it. And they don't give it another thought and dismiss it as not worthwhile.

But that completely looks past all of the details involved. All of the opportunities for experimentation.

There are many different ways to build this game. Some people would draw a single background image and place colliders over that image for each level. Others would build the levels in pieces maybe as floors and ladders in this case. Others would use a tile map. Some would use physics system for all movement. And we have the concerns of player control, how to handle behaviors and so forth.

So the first half of the value is found on the technical side and there are different ways to do each thing. And such a simplistic game is a great lab to experiment in and try different ways to find what is the best & fastest way from a development perspective for that particular person. Because what is best for you may not be what is best for me or someone else.

The other half is the gameplay / fun factor side. The value of this solely as a game. And we can focus on how to make this a better game. Some would say just update the graphics. Others would update all of the presentation visual and audio. Perhaps going on to juice it up to the max. Others would focus on improving the player control. Others may go on to improve the enemy behavior. And other people maybe add more things to do in general. Others may decide well this needs to be in 3D and then they are back to the technical side again.

So this half has value in learning how and what to do to make our games more fun to play.

Sorry for the ramble there... it just occurred to me why I view these games differently than many people do so figured I might as well write it down.

 

It wouldn't be hard at all, it may be a little time consuming tweaking the values to get it to match, but mechanically it's simple replicate.

 

It would probably be a very cool community project and worthwhile @Arowx thread to do one based solely on everyone building their version of a very old simplistic game such as Fast Eddie (or any of the large number of games back there).

Then have each person present their project source and discuss the choices they made on the technical side and the game enhancement side.

The difference in the technical implementations would be great I am sure. As well as the differences on the "make the game better" side.

Just have to keep the point of the thread not be about butchering people's approaches as stupid and other nonsense junk like that. Keep it as there is no wrong approach only differences. And yet I am sure each person would learn something from the others whether they admit it or not.

Unity should do this kind of thing officially. Be beneficial to a lot of people especially newcomers.

 

Your math and threads never cease to amaze...

 

Any suggestions for my next game?

 

You haven't even finished this one yet.

 

Since this has pretty much just become a devlog, moving to WIP.

 

I'm getting in a build test repeat phase so thinking about another project would be a good use of my time.

 

Nothing has changed though. You're still creating games and then quickly abandoning them.

 

Come on guy's just because it use math notation doesn't mean it's complex, it's just mean they use another way to describe it, math (especially their notation) is not my forte but remember what's there when you see derivation is just an interval, speed is a derivative of position and acceleration is a derivative of speed, yall been using hard math all along you didn't notice it LOL

 

There are tons of Game Jams that do exactly this. Recreate a classic game, maybe with a twist.

You learn with every game you create, but I personally don´t think there is much extra value to be learned from being overly precise. You will just waste a lot of time making something accurate, not necessarily better.

 

I think I'm going to draw a line under this here, added rag doll physics and tweaked the WebGL build to try and get some more performance out of it.

I have added the 'complete'* project to as a Unitypackage file so you can have a play with it.

https://arowx.itch.io/doom-retro-remake-level-1

Not bad for about 5 days work off and on, about 40 hrs. So well over budget and lacking a lot of details in the original.

If you can figure out how to get a good smooth fast input system working let me know as wasted a lot of time trying to tweak this aspect of the game?

* minus Unity Sfx'r and a nice Skybox (asset store free) I lo-resed for the game.

 

I do't think that's true, in trying to be accurate you learn nuance you can then expend on. Even more when the system look only simple on the surface, redoing it expose the sophistication. Pac man is a good example of that, the ghost have quite interesting design behind them.

 

Oh my god another abandoned project.

 

PS The PC Build has the lock cursor code in it so best in full screen and Alt-F4 to quit, it was a quick addition so people can try it with above the WebGL crawl speed, it seems to run at on my PC.

 

All game projects are abandoned once they are finished, people only keep them around if they can pay the rent.

 

Your games might actually stand a chance of doing that if you actually finished them more often.

 

LOL @neginfinity COPYRIGHT DUDE, @Murgilod Finish the Clone of DOOM (1993)!

That's probably my best attempt at an FPS, and glad I worked on it but the market is saturated with FPS games. Why add another one.

The aim here is to brush up my skills and have some retro fun along the way.

So far one 2D proto-RTS and one of the first 3D FPS games, what's next???

 

I already said max payne, make the first level of that one, its a third person shooter with bullet time. I dont know why you wouldnt spend another 200 hours just polishing this one though

 

To similar to the last one, and still dark. Just spent 5 days in Doom's first level of Hell maybe something more fun!

 

I'm not saying that you need to make the entirety of Doom's shareware release, I'm saying that your current effort is a goddamn travesty and you should be ashamed to call it complete. Even basic things like your character controller aren't ready for a made-for-TV movie release, let alone prime time. What you've done is made a mess that superficially resembles E1M1 in a sandbox and called it a complete project.

 

Here are 5 old games... all done in 2D simulating 3D... I figured you liked 3D better so that is the reason for choosing these.

All of these you could knock out fairly quickly I think and then spend 1 to 2 days just enhancing them and then 1 to 2 day s polishing & juicing them.

 

I apologize. "Fair use" is not the term I should be using.

BUT, I stand by my assertion that you have the right to make whatever the hell you want so long as you do not distribute it or use it for commercial purposes.

 

The thing is it runs nice and smooth in the editor without hiccups, but build it to WebGL and it's a mess? I've tried massively reducing the the setting to boost fps but still every now and then it seems to spike out. I'm presuming the GC or some other threshold is being reached as I believe that WebGL is mainly single threaded at the moment.

The unity project is packaged so if you can figure out how to get it to work without the controller glitching let me know.

Try the PC build that should run smoother.

The map is based off this plan.



Which looks accurate and is probably generated from the level WAD file. I even have working lifts (j) and secret area (h).

source -> http://doom.wikia.com/wiki/E1M1:_Hangar_(Doom)

What I managed to get into the game in 5 days:

• Pistol
• Shotgun
• Pistol Ammo
• Shotgun Ammo
• Box Pistol Ammo
• Box Shotgun Ammo
• Armour x 2
• First Aid x 2
• Armour Helmets - lots
• Zombie Troopers + Loot Drop
• Shotgun Guys + Loot Drop
• Imps with Fireballs
• Elevators x 2
• Doors x 6
• Switches x 2
• Trigger Pads x 2
• Light pods.
• Gibs
• Water Pool
• Acid
• Two hidden areas
• Barrels x 2*
• Reverb Zones
• Rag Dolls for Imps/ZTroops/SGuys

What I did't get in:

• Separate room textures e.g. computer room / acid room.
• Candelabras
• Transparent walls
• Exploding Barrels
• Steps (I used ramps)

 

I have just spent 5 days in the first level of hell, with Unity and I'm back to tell you all about it...

I'm retro remaking one level of some classic games to test/boost my game development skills.

What surprised me was the very first level of the original DOOM (1993) (E1M1):



It is quite complex and has doors (Orange Double Line F, G), trigger pads, switches, and elevators.

It's the elevators that are the problem, Unity's navmesh system is static, so it's a real cludge to get critters to turn off their Navmesh agent and while the elevator moves and then back on again when it stops.

So how much better could Unity be if UT developed retro remakes of one level of existing games as a way to test the game engine.

They could even invite some of the classic developers to do the remakes in Unity and get some publicity from it.

Also UT could present tutorials/frameworks/lectures on game design and development of classic titles.

As the saying goes the devil is in the detail and that is very true of the classic DOOM.

PS Elevators are just sliding doors on their side.

 

With the upcoming NavMesh System (Due in 5.6) you can having moving NavMeshes (A NavMesh bakes into the object that the 'NavMesh Surface' component is added to). I haven't tested in a scenario of an Elevator but theoretically it would work!

 

I'm quite certain that original Doom did not have pathfinding. Even if some sort of pathfinding was present, it was minimal and did not require nav mesh agent.

For elevators and area transitions, there's an OFF-mesh link component. Use it.
https://docs.unity3d.com/Manual/class-OffMeshLink.html

 

Here's my full DOOM level in a package -> https://arowx.itch.io/doom-retro-remake-level-1

There are two elevators big and small, the big elevator has imps on it and the elevator code is Door (Elevators are just Vertical sliding doors) turn of the isElevator flag and try your NavMesh Surface.

PS Could you get the WebGL performance guys to look at it as I'm getting really bad performance and it seems to be from the controller in WebGL?

 

This one you've overscoped. Doom AI was walk towards player and shoot. That's it. The AI never used any elevators.

Please go download and play one of these games before you start trying to remake it.

 

DOOM generated BSP, binary space partitions of the level geometry, which it probably used as a basic 'navmesh' for the enemy AI.

I though Off Mesh links are for jumps and ladders, not moving platforms like elevators and moving platforms. Do you have a link on how to use them for elevators/platforms as the best info I could find was turning off the NavMeshAgent while the elevator moves and back on again when it reaches it's destination. You also have to build navmeshes at each floor so the navmesh agents have a floor to work with.

 

DUDE I've just spent 5 days on level one and you think I don't know it like the back of my hand now!

Go to 1:35 see the enemy on the high platform.
Go to 2:03 see that dead enemy on the down elevator platform!

ELEVATOR in DOOM with Enemy ON IT! <Appropriate Sound Effect Here>!

There are other videos where the difficulty setting is higher and two enemies occupy that platform and come down when it does.

 

The enemy at 1:35 spawned on the platform. At 2:03 the enemy simply stays on the platform when it lowers.

At no stage does this say 'I need a navmesh which handles elevators'. All you really need is rudimentary physics that keeps an object on the floor.

 

As far as I know, BSP was used for invisible surface removal only and nothing else.

The enemy movement behavior was errorneously follow you using straight line and occasionally wander right and left. They also attacked each other. There are levels where you're massively outnumbered, and total enemy hp is significantly higher than total amount of damage you can deal with ammo you could possibly have at this point. If those guys had pathfinding, you'd be toast.

There's a basic routine that prevents walking enemies from falling off the platforms, but that's it. No pathfinding.

Yes.

I think you need to put your project on hold, play doom on Ultra-Violence, finish it without cheats, and then revisit the project again. If you do that, the end results will be much better.

 

My main point is if Unity were to recreate in house one level of some classic games it would IMHO improve their engine.

For instance what if Unity were to remake, from scratch just one level of:

• A 'classic' flight simulator, it might encourage them to work on asset streaming of larger worlds.
• A racing car simulator.
• An FPS game.
• An RTS game.
• An Adventure game.
• A classic platform game.
• A MMO (just one level they need to do it).

And they should make 2D and 3D games to ensure both sides of the engine get some TLC.

I think instead of Unity needing to make it's own games it can prove that Unity can make great games by remaking them.

Also the act of remaking the games would work as a test of Unity's editor features.

For instance Unity could have a rescale and reposition tool that only rescales the current gameobject and repositions without rescaling the children (I only thought of this when I needed to rescale the DOOM level).

Ideally Unity would only remake the best in class games and every game that has been released is arguably retro (no longer new).

The idea being that any reusable elements could be made available with the engine as assets and learning resources.

 

PS Think of the boost to QA recruiting alone, when the QA team spend most of their time making games!

 

If the idea of your Doom project was to make Unity improve the engine, I'd advise to apply your effort elsewhere and instead do something for yourself.

The games you listed, in their "classic" sense used some incredibly clever tricks, and there wouldn't be much point in recreating them in unity.

For example, a classic flight sim did not feature any asset streaming.
Classic racing did not really feature a 3d road for quite some time.
Classic fps are essentially 2d games.
Etc.

Also, I don't think unity need to "prove" anything or "test" editor. It works already. You can make any of the games you mentioned. You can write extension for anything that is missing. Hell, the whole thing was in development for eleven years.

Basically, once again, you seem to be thinking about some sort of magic tools, etc.

Imagine that you're building a bird house. You could wish for a magic "bird house building machine", or "test construction tools". Or you could just grab a saw and a hammer and just make the damn thing. Unity is that "saw and hammer".

That's not what QA is supposed to be doing, though.

 

Doom ai for sure has no pathfinding whatsoever, they have a simple calculation on sectors height. Maps are subdivided in sectors, each sector has lines that gives them a shape the sector info saved other than texture is also height of each line perimeter and what is after it to the next sector.

Monsters do one thing, they are dormant, when you awake them they start walking around, they do have line of sight and will start using attacks accordingly to what they can use, if the player gets away they will pick the last direction of the player and start fiddling around that direction, but they have no clue how to navigate the level, once they hit a wall they simply go to another random direction to break free, if a door is in the way they will automatically open it. Is common that some mosnter get stuck in some room trying to break free from walls to keep chasing you.

They can't use elevators in the sense that if they see the player on a higher floor they are going for the elevator to reach you, they have no idea of that, it could happen that they end up in a elevator by pure luck.

The reason they don't fall down high places is because they test against next sector if is too high their actual sector perimeter is considered as a wall for walking so they will keep bouncing around. Thats the reason why doom mosnters can't stay still a second once awakened.

 

So for AI pathfinding Unity could remake FEAR or an RTS game like Starcraft, one renowned for it's enemy FPS AI the other it's RTS AI and pathfinding.

 

Improved DOOM L1, following improvements:

• There is a spiked drop in FPS due to Unity loading shaders mid game, fixed with Graphics settings.
• Reduced polycount some models.

Much better performance in the Edge Browser.

 

OK Next Up A Blast from the past game I used to love:

Should I make it in retro 3D e.g. 3D game presented in low resolution/low poly or 2D from sprites?

Anyway going to have some fun making a level/mission from this.

B4N!

 

The performance is indeed much better in desktop mode. Probaby it requires some specific optimizations to run well on WebGL, but I have no idea which exactly.

 

Before I ever post in an @Arowx thread, I have to give a good bit of consideration whether it's something I really want to do. I'm pretty sure you're a good bit smarter than me, Arowx, but sometimes I feel like intelligence is a limited range signed int variable that when incremented past its max, ends up being a hugely negative value instead. That is to say, you take these high-level concepts and overthink them into asininity.

Isn't one of the most valuable skills in game development the ability to find the simplest implementation that solves the problem? Instead of simulating realistic physics for every strand of hair on a character's head, we just have a little mesh of a few dozen vertices that animates loosely representing how hair kinda actually behaves.

Instead of having massive pathfinding systems that can handle any situation, isn't it much better to have generic systems that handle a lot of situations, and when specific needs arise that aren't met by those implementations, solve for that specific problem? And isn't it better that individual developers create those solutions themselves, rather than pulling resources from the engine dev team, who could better focus their efforts on core features that are useful to the Unity user base as a whole?

Discussions are cool and all, but I have to wonder if you truly believe many of your ideas are actually good and worth implementing the way you suggest.

 

I think this would have been a great addition to the Unity assets. Having some examples I'd actually be interested in checking out would have gone a long way I think to have helped me to get into Unity.

A complete DOOM-like FPS game, a complete Gradius style scrolling shmup, a complete Double Dragon style scrolling bmup, a complete scrolling Gauntlet style game, a complete scrolling platformer game etc.

By complete I mean have a title screen, info screens, game over screens(s), 2 levels and of course all of the gameplay, scoring, items, stats display etc.

Would have made a hell of a difference seeing as how weird Unity is compared to every other thing I have used. And having interesting examples like this would have really pulled me in more.

Plus I think @Arowx is correct in that if they made such games they would be able identify things that need to be improved in the engine. Places where they needed a small handsaw and only had a chainsaw available, places where they needed a specific size wrench and unfortunately had 4 other sizes only.

At the very least it would be interesting to see how they worked around such things.

 

There's absolutely a benefit to the creator of a tool (in this case, the Unity engine) using it to actually build something as a means of determining how the tool could be improved.

But if the company is in the business of manufacturing and selling chainsaws, shouldn't that be their focus, rather than trying to make a mutli-tool that can cut twigs and trunks using the same blade? If I had to, I could probably fashion myself a handsaw. I could not make my own chainsaw.

There's probably not a right answer to that. More a matter of opinion.

 

I am a fan of recreating old school games for learning purposes, not sure how I'd feel about it as a way of improving the engine, though.

The idea isn't thaaat far of from the scenario testing already done inhouse. https://blogs.unity3d.com/2017/01/03/a-look-inside-scenario-testing-at-unity/

 

I'd prefer faster 5.6 release to this. Demos are cool to play. They are not incredibly useful when you need to make something.

 

This implies that Unity (the engine) is intended only for certain types of games. Which I'm not disagreeing with because it certainly seems to be better suited to some kind of games (particularly 3D) than others (such as more simplistic retro style).

Of course it can be used. I know that. I've made such games with Unity. But what I am saying is the normal Unity Way of development is not the way to do such games. As @Arowx found during his Doom remake and as I ended up completely throwing out near everything and using Unity as only a way to load content, display it (visual) and play it (audio).

If it really isn't intended to be used for such games it would be great to just add that to the front page. Just a little Note: Unity is intended for the development of modern 2D and 3D games. For retro style games there are alternatives available elsewhere.

I don't believe that is the case though. And certainly people have made such games with Unity and generally fought against the built-in systems and just not used them.

It's this kind of thing I am talking about where it would be incredibly useful to see how Unity (the people) intend the engine to be used for games that don't rely on the built-in physics systems, the nav system and so forth... without having to fight against the systems due to the way it is all engineered.

 

I guess I think of it differently. Unity can be used to make any kind of game. Certain toolsets of the engine are more practically intended for specific types. For everything else, there's just plain ol' code.

You've correctly identified that for the retro type games you make, Gar, that you don't need a lot of those tools. Instead, you write the code yourself. That's not to say you're drawing no benefit from Unity, though, right? You're still getting the great asset management pipeline and everything. You definitely could have built Atlantic Crisis using just Visual Studio (or Python or something), but you saved time and effort by using the core elements of Unity.

That's the root advantage I find in using it: I can write code that interacts with these tools so that I don't have to figure out how collision detection works, how physics are calculated, or something as basic as making rendering calls to the GPU. The tool is there, and it's got a certain level of guarantee that it works correctly. If the tool doesn't do exactly what I want it to, it's my responsibility to make it work, find an appropriate tool, or create my own handsaw.

I'm not positive of the point I'm trying to make. I'm getting hungry and having difficulty focusing.

 

@Jacob_Unity @Andy-Touch @zombiegorilla OK Which moderator linked my new general thread about this topic to my WIP thread.

1. OK this has become a WIP thread as I'm the only one working on remaking retro games with Unity.
2. The potential for Unity to test and improve its tools by recreating existing games is IMHO a good idea. Furthermore their existing rather weak attempt at making a bit of a game get's nowhere close to the work and detail they would need to recreate a level of an existing game.

So can I please have my WIP thread back or do I need to restart my general ideas thread and a new WIP thread?!