Semester 3 - Concept

Semester 3 - Concept



Hey Guys,


So with my BSP production skills advancing heavily, I decided to consolidate some possible ideas that I wish to pursue this Semester.

With having and wanting to develop my game around the original DOOM series - hence the heavy but more refined use of BSP, I came to consider that if I am now able to generate maps faster using BSP rather than the conventional 3rd party process, of developing meshes in a 3D modelling program, such as: Maya, Blender or 3DS Max, that I should now go back to my usual workflow of creating Blueprints in order to accommodate the use of these maps.

An instance that I find rather bespoke of DOOM at its time was the use of a Level Select screen, more importantly it gives the user the choice of selecting their world, but it is also a preliminary action required for our user to show some sort of interest in our project, through the use of simple input to select the level they wish to play. Now this can be altered to facilitate an unlock system, where our user can see their journey ahead of them, giving them the choice to see what they could've missed and in essence making them aware of their overall progress.

Yet the way created in the original DOOM, was upon level completion rather than being in their level select screen, showing the users kills, secrets found, deaths and items collected - again another possible idea for development, the only problem is the need to add global variables that change upon the state of the game, which could be accessed by using the game state: i.e. on player death, item collected, kill added and secret found.




Another possible idea, is to rejuvenate my weapon system from my 3rd Year work
(video above), (which will also result in the need to change my current ammo system, but the newer system does reflect on current systems found in current games, such as; Fallout 4. DOOM (2016)) - although in my previous work there are bugs that I do plan to amend in this version - one in particular arose by the use of widgets in game, where it wouldn't automatically return the mouse input use on our character.


A problem that arises here, is that if the game requires to jump from map to map, that instances will need saving and loading systems in place in order to transfer the data from area to area as I still haven't cracked level streaming, where if it was done via that method all the variables required will all be present in the same instance. In addition without the Saving/Losing system it would otherwise create data loss, but if they managed to do it in DOOM I think there maybe a way that I too can replicate something basic enough to handle this operation.

One note to self - Is to always consider the speed of service with our menus, and that if needed things should wrap around; always make sure that only one instance is available.

Another note - Is to make sure that all interactive menus should always have controller support. 

Comments

  1. Seems you did everything two days ago - according to my blogger feed!
    Are we doing some serious updating here Mr Winbow?

    ReplyDelete
    Replies
    1. Haha I didn't spot this. Well I had a back log of work that needed recording and forgot to change the post date to the actual update date.

      But I am trying to adapt the original maps into something just as interesting, along with the idea to do one fully fleshed level rather than a slice.

      Delete

Post a Comment