Difference between revisions of "User:00zX"

Revision as of 07:30, 21 January 2010

Works in Progress for Unreal Engine 3

Project: Silky (UDK)

Status: Pre-Alpha (prototype)

Perspective/Camera: Top Down
Type/Style: Arcade Shooter

Controls/Movement:

Dodging: Barrel Roll left/right

Afterburner: Extra Speed

Weapons:

Pulse Plasma-Gun: Varying degrees of upgrades, TBA

Missiles: Sidewinder, AMRAAM, SRAAM, etc

Rail-Gun: Assault, Penetrate (slower)

Energy Net: Snare

Description

The idea behind this project was to make something simple, fun and enjoyable. I looked at alot of indy games before coming up with this concept, audiosurf, braid, geometry wars. Eventually I settled on making something similar to one of my favourite arcade games which was macross plus. I remember back then and telling myself there wasnt enough of those top down shooters but honestly even back then perhaps I had ideas mulling around in my skull on what could make a fun top down shooter.
The gameplay will revolve around the player being in control of a fighter jet, much like 1942, macross plus or overkill. You'll pickup weapon upgrades of various types, fly through canyons, through cities and other environments yet to be decided. There will be a variety of enemies you encounter along the way with the traditional boss battles.
I just got bored with the whole "lets make a badass FPS/TPS" coming from alot of people, dont get me wrong I love those games as well but as a developer/modder working on/with those types of projects for over 10yrs it was time to move on and try my hand at something new and perhaps inspired. Maybe that was it, I was just lacking the inspiration which in turn showed on my motivation when working on those types of projects. Ive made major progress in short time (thanks to all your help guys big shout out to the #unrealscript channel, you know who ya are ;) ).
Currently Im tackling the projectile/weapon upgrade system, I'll certainly keep this updated on my progress, being a one man project till this hits anywhere near beta Im hoping things will go smoothly. There wont be any logistical issues with team members, team members leaving and taking their work with them or anything to that effect. Basically this is a one man show and this project was chosen partly because of that, its simple enough that 1 multi-talented person could pull it off in a decent enough timeframe. The only external help I'll need is in regards to sound and music, which I could do myself but Id like to keep it quality and I have a specific sound Im after to keep it within the classic arcade feel.

How Arcade is too much?

Well I really miss those times sinkin 20c or $ coins into mortal kombat, super offroad or hell even tekken 3, fighting vipers and SCUD racer. I really want to grasp that back in a big way with this project, Im going to try for an authentic revist in almost every detail while bringing things into the new age in terms of graphics and technology. One thing I would like to explore from my youth is system link much like the game gears but with bluetooth. Id like to go the whole hog, high scores, demo intro and even an insert coin screen instead of the well known "press START".

Thats about it, like I said I'll keep this page updated with all my code progress ;)

GameDex: Framework (UT3)

Status: Alpha 4 (testing)

Download: GameDex_AllGDP_DodgyAlpha_150909.rar
Download: UT-GameDex-Src-150909.rar

Description

• Okay so I'll just waffle alittle here and see what comes out about what I was trying to achieve with this.

• For starters I was never a fan of the one class/mutator does everything approach as I like to keep things modular and interconnecting, I noticed inherent problems with Unreal Engines mutator system (as you all would have at one point or another) so I went about starting to hook through it and creating a new system which could actually replace the system especially now we have the UDK at our disposal.

• • The initial ideas and concepts from this project came about while I was working on the Newtators mutator pack and Attrition gametype, eventually these projects and some of the major functionality was rolled into Gamedex as it provided a more modular approach and allowed me to reuse alot of said functionality easier.

• • Basically things like the FactoryReplacer class became a foundation class and an intergral part of the Gamedex.

• A Note here about the UDK is that it doesnt contain the Gamerules class.

• Either way this system would need to be implemented at a GameInfo level to provide the appropriate hooks to UT_MDB_GameRules which I achieved through the use of a wrapped class UT_GR_Info which does nothing but send the hooks from GameInfo->Gamerules into the new system.

• Since the new system is totally reliant on Object's I suspect that its better on system performance and will be dealt with by the internal garbage collection system. These objects can be initialized at any time and for any number of actors, for instance since all damage is hooked through one function one can prune the unwanted actors rather than searching for the specific actors you want to apply a rule to. The rules are meant to be simple as in the vampire mutator, which gives players a portion of the damage they deal back in health. Any number of players could be affected by this, for a duration or globally for the entire match. Mutators dont really allow this kind of control, they can but I believe the front end for interfacing with this system would be much more intuitive.

• This is where I hit my first major hurdle as I wanted to provide a UI similar to 2k4's for adjusting mutator settings, maybe even extending that to allow server admins to interface with the modules on the fly whilst connected to their server.

• Im pretty happy with the results so far but its been a slow arduous journey, I recommend you take a look at UTM_BloodLust for an overview in code of what I was trying to achieve through all of this.

-00zX 11:27, 12 January 2010 (UTC)

Project Class Tree

• Interface
  • iObjectList

• Object
  • Actor
    • Info
      • Gamerules
        • UT_GR_Info
      • Mutator
        • UTMutator
          • UT_MDB_GameExp
            • UTM_BloodLust
  • UT_MDB
    • UT_MDB_FactoryReplacer
    • UT_MDB_GameRules
      • UT_MDB_GR_DmgConversion
        • UT_MDB_GR_GlobalDamage
        • UT_MDB_GR_Vampire
          • UT_MDB_GR_Bloodlust
    • UT_MDB_ObjectList

Naming Convention

The over all name for the project Gamedex was a play on words, being part nod to UnCodex and extension from my Noir Highlighter theme code named Redex, which inturn was inspired by Epic/DE's use of Redux in UT2k4.

Basically I see it as a 3rd full revision, with Newtators and Attrition being the first two. Upon closer inspection you'll see it says 'Gamed-ex' :)

It actually took me awhile to settle on a naming convention for these packages and classes.

Eventually I settled on appending UT_ as a prefix to designate that it was a modification for UT3.

The MDB is just an acronym to set the project apart incase I ever have other projects where I have similar named classes.

The beauty of using an acronym for projects is you can have multiple versions/branches of the same project on the same tree without conflicting class names.

Not only that but you can also develop classes and diff/merge the results based on the requirements for such projects.

As in Epic's base source code all classes have fixed names, so while you might be using 1 version of GameRules if that class changes you might get errors which cascade.

With this system you can work from one class say MDB as in the example, yet develop another which we'll call MDA all while keepin on the same class tree.

The UT_GDP designates any package which requires UT_GameDex and UT_MDB.

Project Package Tree

• UT_MDB- This package contains buffers (empty classes to keep the tree clean) and classes which extend UT3's for things like bNoDelete=true spawning.
  • UT_GameDex - Main package containing all the base functionality classes.
    • UT_GDP_Newtators - Is one of my mutator packages.
    • UT_GDP_Mutatoes

Initial Prototypes

Newtators (Mutator pack)

Download: Newtators-v1.9e

Description: Well this started out as just a way for me to make some stuff that I would have liked in UT3 such as a few remakes of Epic's classic muts included across other UT games, acouple were taken from options also. It grew into something much larger, the idea has always been to keep the pack as small and tight as I can providing quality mutators with compatibility between them all.I ended up adding a few customs things after I got done with a few of the remakes and things evolved from there, alot of stock assets have been reused and remixed to create some extended gameplay.

Mutators:
Agile - Adds dodge-jump, wall-dodge-jump and removes the delay on jumps, dodges or jumps with smaller falls.

Bloodlust - Replaces the UDamage with a Red Vampyric version which allows you to suck health from damaged enemies. You are not allowed to pickup health while using this powerup but you can get up to 199 from sucking enemies health.

Booster - Replaces the Berserk Powerup with a new Booster Powerup. It gives the player health every 10 seconds, it raises the health cap to 199/299 and allows you to pickup health to reach the cap quicker. Once it has depleted your health will slowly drip back to normal levels

Dual Enforcers - Gives you dual enforcers on spawn.

Energy Leech - Leeches a percentage of the Shields/Armour from damaged players or vehicles and gives it back to you. (UI)

Extra Self Damage - Players take more damage from their own shots.

Fast Weapon Switch - Weapons switch faster.

Hardcore - Like UT's Harcore option this raises all damages to 125% of their original.

Hoarding - Lets you choose which items players can pickup and which they cant when they already have the maximum. (UI)

No Double Jump - Removes double jumping and adds a single higher jump, wall dodging is still enabled, also allows you to walk so you dont activate the jump boots when single jumping much like UT.

No Health Pickups - Removes all health pickups from the game.

No Super Weapons - Removes all super weapons from the game.

Quad-Jump Boots - Spawns new jump boot pickups which gives the user limit charges to perform quad jumps. This allows you to do many jump combinations like wall-dodge-double-jumps.

Speed Boots - Spawns speed boot pickups instead of jump boots. When picked up these boots increase the players speed dramatically for 30 seconds.

Strong Vehicles - Makes all vehicles stronger vs most damage types. Vehicles are still similarly damaged from crashes and falls.

SuperBots - Will make Bots deal more damage to Human players.

Translocator - Will add the Translocator to Deathmatch or Team Deathmatch.

Vampire - A percentage of damage done to enemies will be given back to you in health. This health is shown on the screen so you know how much you have received. This also allows the option for vehicles to take a percentage of damage from other vehicles. (UI)

Vehicle Replacer - Allows you to choose which vehicles to replace and with what. It also has an option for per map settings which is accessible from the config files. (UI)

Vehicle Team Swap - Allows you to set Red/Blue to use Necris/Axon vehicles regardless of the map defaults. It also has an option for per map settings which is accessible from the config files. (UI)

Attrition (Gametype)

Download: Attrition-v0.5pb.rar

Description: The idea behind this gametype was a war of attrition so everything featured is geared towards that. To win though you have to make a kill with every weapon once, you start with all weapons and they are removed from your inventory as you make a kill with them. Suicides will return a weapon back to your inventory unless it is already full. There is a catch, you have unlimited ammo and all pickups are removed except, Jumpboots, Vials, Armour, Shields and the Keg.

In this gametype frags dont really matter a great deal, except they are a way to get rid of your weapons!

This gametype is best suited for lower player counts, around the 2-4 range is really good but anywhere between 2-8 should make for good matches as it really does depend on the size of the map and how many rounds you want to play.

Features:
Health/Armour Degen - after these are picked up they start to wear in, then over time they wear out and break down. Wear only occurs over 100 health and always on armour.

Round Based Play - at the moment it only supports winning the match by getting to the rounds won, so if you win 3 rounds, in any order first, you are the winner. More victory conditions are on their way though, like playing out an amount of rounds no matter what and the player with the most wins at the end is the winner.

Anti-Camper - This was put in because of the unlimited ammo, keeps people moving and makes the matches faster especially 1 on 1 matches. Since there is no time limit this was almost a requirement.

Tweaked Music - To give more of an action feel the music was tweeked so it ramps up alot more.

Tweaked HUD - Alot of the excess text was removed from the hud as well as tweaking to make it fit with the gametype. I will be updating this so people can customize alittle more and reallow acouple of the default options.

Highlighters

Code Noir Redex Wikimedia Theme

Status: Alpha 9 (testing)

To Install copy the contents of the following page into your own 'User:[name]/monobook.css' page.

User:00zX/monobook.css

| W3C CSS Validator

Features

• Dark Theme
• High Contrast
• Improved Readability
• Highlighter adjustments for UScript and CSS
• Different coloured borders per GameNameSpace
• Curved Borders in supporting browsers

Known Issues

• Edit/Input boxes are still black on white
• interwiki links are wrong blue colour and dont have hoverover colours

Proposal - Replication

Replication

Status: On Hold

-00zX 20:49, 3 April 2009 (UTC)

Replication / Replication_(computer_science)

Concept of servers and clients.(NetMode/Relevancy/Reliability)

• Declaring Replication using the Replication Block
• Function Replication using the replication block?
• Booleans Declared in actor that are useful in replication

http://wiki.beyondunreal.com/Introduction_to_replication#

• NetMode (concept)
• Replication Block
  • Actor Replication (bools bnetinitial eg)
  • Variable Value Replication (using block)
    • Repnotify / ReplicatedEvents
  • Function call replication(UT2004)
• Function call replication(UT3)
• Reliability
• Relevance (actor replication??)
  • Role and RemoteRole
• Info
  • ReplicationInfo
    • GameReplicationInfo (GRI)
    • PlayerReplicationInfo (PRI)
    • LinkedReplicationInfo (LRI)

replication
{
  reliable/unreliable if ( replication condition )
    identifiers;
}

replication
{
   if ( replication condition )
    identifiers;
}

var() float NewEquipTime;
var() float NewPutDownTime;
 
replication
{
	if(bNetDirty && (Role == ROLE_Authority) && bNetInitial)
		NewEquipTime, NewPutDownTime;
}

simulated event ReplicatedEvent(name VarName);	// Called when a variable with the property flag "RepNotify" is replicated
 
/** adds/removes a property from a list of properties that will always be replicated when this Actor is bNetInitial, even if the code thinks
 * the client has the same value the server already does
 * This is a workaround to the problem where an LD places an Actor in the level, changes a replicated variable away from the defaults,
 * then at runtime the variable is changed back to the default but it doesn't replicate because initial replication is based on class defaults
 * Only has an effect when called on bStatic or bNoDelete Actors
 * Only properties already in the owning class's replication block may be specified
 * @param PropToReplicate the property to add or remove to the list
 * @param bAdd true to add the property, false to remove the property
 */
native final function SetForcedInitialReplicatedProperty(Property PropToReplicate, bool bAdd);

var	repnotify	class<Inventory>			InventoryClass< SEMI >		// Class of the inventory object to pickup
var	repnotify	bool						bFadeOut;
 
replication
{
	if( Role==ROLE_Authority )
		InventoryClass, bFadeOut;
}
 
simulated event ReplicatedEvent(name VarName)
{
	if( VarName == 'InventoryClass' )
	{
		SetPickupMesh( InventoryClass.default.DroppedPickupMesh );
		SetPickupParticles( InventoryClass.default.DroppedPickupParticles );
	}
	else if ( VarName == 'bFadeOut' )
	{
		GotoState('Fadeout');
	}
	else
	{
		super.ReplicatedEvent(VarName);
	}
}
 
defaultproperties
{
	bOnlyDirtyReplication=true
	NetUpdateFrequency=8
	RemoteRole=ROLE_SimulatedProxy
}

/** Sets the clients weapon to use the replicated variables */
reliable client function SetWeapProps(UTWeapon W)
{
	W.EquipTime = NewEquipTime;
	W.PutDownTime = NewPutDownTime;
}

/** Gets the times from the weapons and sets them to the replicated variables */
reliable server function GetWeapProps(UTWeapon W)
{
	NewEquipTime = W.default.EquipTime * 0.68;
	NewPutDownTime = W.default.PutDownTime * 0.70;
}

enum ENetRole
{
	ROLE_None,							// No role at all.
	ROLE_SimulatedProxy,		// Locally simulated proxy of this actor.
	ROLE_AutonomousProxy,	// Locally autonomous proxy of this actor.
	ROLE_Authority,					// Authoritative control over the actor.
};
var ENetRole RemoteRole, Role;

if (Role == ROLE_Authority)
{
	// This is the authorative copy of this actor, it was spawned on this machine.
	// It is not a guarantee that we are on the server or in single player!
}
 
if (Role < ROLE_Authortity)
{
	// This is a non-authorative copy of this actor that was replicated
	// from the server. In other words, we must be on a client.
}

	// Physics
	if( (!bSkipActorPropertyReplication || bNetInitial) && bReplicateMovement
					&& ((RemoteRole == ROLE_SimulatedProxy) && (bNetInitial || bUpdateSimulatedPosition)) )

var enum ENetMode
{
	NM_Standalone,				// Standalone game.
	NM_DedicatedServer,		// Dedicated server, no local client.
	NM_ListenServer,			// Listen server, local client+server.
	NM_Client							// Client only, no local server.
} NetMode;

simulated event PostBeginPlay()
{
	if(WorldInfo.NetMode != NM_DedicatedServer)
	{
		// Code here will only be executed on Listen servers and game clients.
	}
 
	if(WorldInfo.NetMode == NM_DedicatedServer)
	{
		// Code here will only be executed on a server.
	}
}

simulated event PostBeginPlay()
{
	if (WorldInfo.NetMode < NM_DedicatedServer)
	{
		// Code here will only be executed on Listen servers and game clients.
	}
 
	if (WorldInfo.NetMode > NM_DedicatedServer)
	{
		// Code here will only be executed on a server or standalone client.
	}
}

// Networking flags
var			  const	bool	bNetTemporary;				// Tear-off simulation in network play.
var			  const	bool	bOnlyRelevantToOwner;			// this actor is only relevant to its owner. If this flag is changed during play, all non-owner channels would need to be explicitly closed.
var transient				bool	bNetDirty;				// set when any attribute is assigned a value in unrealscript, reset when the actor is replicated
var					bool	bAlwaysRelevant;			// Always relevant for network.
var					bool	bReplicateInstigator;		// Replicate instigator to client (used by bNetTemporary projectiles).
var					bool	bReplicateMovement;			// if true, replicate movement/location related properties
var					bool	bSkipActorPropertyReplication; // if true, dont replicate actor class variables for this actor
var					bool	bUpdateSimulatedPosition;	// if true, update velocity/location after initialization for simulated proxies
var					bool	bTearOff;					// if true, this actor is no longer replicated to new clients, and
														// is "torn off" (becomes a ROLE_Authority) on clients to which it was being replicated.
var					bool	bOnlyDirtyReplication;		// if true, only replicate actor if bNetDirty is true - useful if no C++ changed attributes (such as physics)
														// bOnlyDirtyReplication only used with bAlwaysRelevant actors
 
 
/** Demo recording variables */
var transient				bool	bDemoRecording;		/** set when we are currently replicating this Actor into a demo */
var transient				bool	bClientDemoRecording;	/** set when we are recording a clientside demo */
var transient				bool	bRepClientDemo;		/** set if remote client is recording a clientside demo */
var					bool	bDemoOwner;					// Demo recording driver owns this actor.
 
/** Should replicate initial rotation.  This property should never be changed during execution, as the client and server rely on the default value of this property always being the same. */
var const           bool    bNetInitialRotation;
 
/** If true, never replicate rotation */
var					bool	bNeverReplicateRotation;
 
var					bool	bReplicateRigidBodyLocation;	// replicate Location property even when in PHYS_RigidBody
var					bool	bKillDuringLevelTransition;	// If set, actor and its components are marked as pending kill during seamless map transitions
/** whether we already exchanged Role/RemoteRole on the client, as removing then readding a streaming level
 * causes all initialization to be performed again even though the actor may not have actually been reloaded
 */
var const				bool	bExchangedRoles;

Wiki

Contributions

• Using the UT2004 Mod System

Contact Me

IRC

00zX on EnterTheGame

• #beyondunreal on EnterTheGame
• #unrealscript on EnterTheGame
• #unrealwiki on EnterTheGame

Other/Profiles

E-mail 00zX or on

• filefront
• delicious
• Photobucket