Outpost [3] Development

Outpost [3] Development

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Outpost [3] Development

Post by Zhall » 19 Jul 2014, 13:14

Hey everyone,

I represent the outpost community over at http://newterrancommandsite.com/

We have been working on an Outpost 3 mod for over a decade, many have tried and all have failed.

I am hoping that the Spring engine is the final solution to get us moving in the right direction once and for all.

Our development progress thread can be found here
http://newterrancommandsite.com/forums/ ... ead#unread

-Reserved for later use-
Last edited by Zhall on 23 Jul 2014, 03:32, edited 1 time in total.
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 19 Jul 2014, 13:20

First off is the issue of mining via cargo trucks.

Picasino requested this example of how it works in outpost 2.
Attachments
Mining.gif
Mining.gif (1.41 MiB) Viewed 1961 times
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10199
Joined: 24 Jan 2006, 21:12

Re: Outpost [3] Development

Post by PicassoCT » 19 Jul 2014, 14:16

Code: Select all


function gadget:GetInfo()
  return {
    name      = "TransportSystem",
    desc      = "Allows to fill Transports with (rare or not rare) Ore",
    author    = " Picasso",
    date      = "Sep. 2014",
    license   = "GNU GPL, v2 or later",
    layer     = 0,	
	version = 1,    
    enabled   = true,
  }
end

	--some notes:
	-- your trucks need the functions that are called by the gadget for example HideLoad
	--same goes for the buildings
	-- your unitnames need to be the same in the gadget or the gadget wont recognise

	if (gadgetHandler:IsSyncedCode()) then

	local REFINERYDISTANCE=90
	local MINEDISTANCE=90
	
	local TransportByTeam={}
	local RefineryByTeam={}
	local MinesByTeam={}
	
	local teams=Spring.GetTeamList()

	local teamIDToNumber={}
	for i=1,#teams, 1 do
	teamIDToNumber[teams[i]]=i
	TransportByTeam[teams[i]]	={}
	RefineryByTeam[teams[i]]	={}	
	MinesByTeam[teams[i]]		={}	
	end
	
	local UnitDefTransport= UnitDefNames["AddyourTransportNameHere"].id
	local UnitDefRefinery= UnitDefNames["AddyourRefineryNameHere"].id
	local UnitDefMine= UnitDefNames["AddyourMineNameHere"].id
	
	local UnitsThisGadgetsCaresAbout={[UnitDefMine]=true,
									  [UnitDefTransport]=true,
									  [UnitDefRefinery ]=true			
									  }
	
	
	

	 local spGetUnitPosition=Spring.GetUnitPosition    	
	
	function gadget:UnitCreated(unitID, unitDefID, teamID)
	
			if UnitsThisGadgetsCaresAbout[unitDefID] then
			
				if unitDefID==UnitDefMine then
				x,y,z= spGetUnitPosition(unitID)
				MinesByTeam[teamID][unitID]={x=x,y=y,z=z}
				end	
				if unitDefID==UnitDefRefinery then
				
				x,y,z= spGetUnitPosition(unitID)
				RefineryByTeam[teamID][unitID]={x=x,y=y,z=z}
				end	
				if unitDefID==UnitDefTransport then
				TransportByTeam[teamID][unitID]=unitID
				end
	
			end
		end

		
		
	function gadget:UnitDestroyed(unitID, unitDefID, teamID, attackerID, attackerDefID, attackerTeamID)
		if UnitsThisGadgetsCaresAbout[unitDefID] then
					if unitDefID==UnitDefMine then
					MinesByTeam[teamID][unitID]=nil
					end	
					if unitDefID==UnitDefRefinery then
					RefineryByTeam[teamID][unitID]=nil
					end	
					if unitDefID==UnitDefTransport then
					TransportByTeam[teamID][unitID]=nil
					end
		
		end
			
	end
		
	
	function gadget:GameFrame(frame) 
	--How often to update
			if frame % 15 == 0  then
				for teamid, unitid in pairs(TransportByTeam) do
				if teamid and unitid then
					refineryID =IsUnitNearRefinery(unitid,teamid)
					if refineryID then
					callRefineryForAnimation(refineryID,unitid)
					callTruckToShowLoad(unitID,"oretype")
					end
					
					mineID =IsUnitNearMine(unitid,teamid)
					if mineID then
					callMineforAnimation(mineID,unitid)
					callTruckToHideLoad(unitID,"oretype")
					end
					
				end	
				end	
			end
	end
					function IsUnitNearRefinery(unitid,teamid)
					x,y,z= spGetUnitPosition(unitID)
					unitTable=Spring.GetUnitsInCylinder(x,z,REFINERYDISTANCE,teamid)
					table.remove(unitTable,unitid)
						for i=1,#unitTable do
						--if the list of units around the truck contains a reffinery return true
						if RefineryByTeam[teamid][unitTable[i]] then return unitTable[i] end
						end
					end
					
					function IsUnitNearMine(unitid,teamid)
						x,y,z= spGetUnitPosition(unitID)
					unitTable=Spring.GetUnitsInCylinder(x,z,MINEDISTANCE,teamid)
					table.remove(unitTable,unitid)
						for i=1,#unitTable do
						--if the list of units around the truck contains a reffinery return true
						if MinesByTeam[teamid][unitTable[i]] then return unitTable[i] end
						end
					end
					
					function callRefineryForAnimation(refineryID,unitid)
						local env = Spring.UnitScript.GetScriptEnv(refineryID)
						if env then
						Spring.UnitScript.CallAsUnit(refineryID, env.RefineryLoadAnimation )		
						end
					end
					
					function callTruckToShowLoad(unitID,oretype)
						local env = Spring.UnitScript.GetScriptEnv(unitID)
						if env then
						Spring.UnitScript.CallAsUnit(unitID, env.ShowLoad, oretype )		
						end
					end
					
			
					
					function callMineforAnimation(mineID,unitid)
						local env = Spring.UnitScript.GetScriptEnv(mineID)
						if env then
						Spring.UnitScript.CallAsUnit(mineID, env.MineLoadAnimation, unitid )		
						end
					end
					
					function callTruckToHideLoad(unitID, oretype)
					local env = Spring.UnitScript.GetScriptEnv(unitID)
						if env then
						Spring.UnitScript.CallAsUnit(unitID, env.HideLoad, oretype )		
						end
					
					end
	end
	
Transport Truck Code.. Have fun.. if you have drawings maybe i want to modell one or two buildings..
0 x

Google_Frog
Moderator
Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Outpost [3] Development

Post by Google_Frog » 19 Jul 2014, 18:24

I recommend that you first try to get a general understanding of lua in Spring. In practice the 'features of Spring' fall into one of the following categories:
  • Features which Spring implements engine-side.
  • Features which have been implemented via lua.
  • Features which could easily be implemented with lua but have not been done yet.
Spring implements most basic RTS features and in some cases it does quite a bit more. Unit selection, command handling, line of sight, pathfinding, weapon AI and general unit physics are all things done by Spring. Navy type things as well as planes and helicopters are well supported in addition to the 'basic' unit type which walks along the ground. There are also many distinct weapon types and properties. This type of using Spring involves looking at the wiki pages which hold the behavior tags and experimenting.

Behaviour which is not so standard will have to be implemented with lua scripts. Firstly do not get the impression that lua is perched awkwardly on top of Spring. It is well integrated and has hooks to control almost everything that goes on in your game if you so desire. The current games implement a lot of their behaviour with lua so if you want a feature it is good to ask around. You still need to know lua because these lua scripts are rarely written with modularity in mind so will at least require tweaking to fit into your game.

If nobody else uses a feature which you want then a script which implements that feature will not exist. In this case you have to write it yourself or convince somebody else to do it for you. It is better to write your own lua (because you will will be better able to modify in it the future) but when new it is useful to ask for guidance on the forums. So don't "go dark" but also don't expect us to have already built all the features you need for your game.

Good luck and ask for clarification on more specific things.
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 19 Jul 2014, 21:49

Picasso,

We will need that smelter and ore mine pictured in the gif of the harvesting operation I posted.

We don't have any design drawings for that, so you will have to extrapolate what you can from the sprites.

--

I will definitely look into learning some lua before diving into spring more.
0 x

User avatar
yuritch
Spring 1944 Developer
Posts: 1018
Joined: 11 Oct 2005, 07:18

Re: Outpost [3] Development

Post by yuritch » 20 Jul 2014, 18:08

As far as I know Outpost II (I played quite a bit of singleplayer in it), it's perfectly doable in Spring. Most required features have already been done by one spring game or another, and the rest look simple enough.

The only thing I don't see how to replicate is the Robot Command Center. Basically it's a building that, when built, improves pathfinding for player's units.
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 21 Jul 2014, 01:57

I actually said "Is that what it does?" outloud.

I never understood the robot command center, I always thought it was just useless.

It also seems like a useless feature so I won't be missing that.

Biggest concerns are

Tube system
Cargo truck hauling
Morale system

Other than that it's a pretty standard rts at it's core
0 x

User avatar
yuritch
Spring 1944 Developer
Posts: 1018
Joined: 11 Oct 2005, 07:18

Re: Outpost [3] Development

Post by yuritch » 21 Jul 2014, 09:31

How to see what robot command center does: bulldoze a long road, set some vehicles to move near it. With RCC enabled they will use the road (turn a bit from the shortest route to travel the road which is faster). With RCC disabled they just go the short route, even if it's not bulldozed = slower.

This doesn't mean much in actual games of course because properly placed smelters make long travels for trucks unneeded, and armed units are better directed by hand.

Tube system: AFAIK Zero-K has some kind of energy grid which can be reused for this purpose.

For those not familiar with Outpost, most buildings there must be connected to a Command Center building (or some other building that is connected to a Command Center) by tubes (buildable by special vehicle) in order to function. Interesting thing is that the tubes are apparently NOT used to transfer power and metals (there can exist several separated tube networks and resources are available between them), but a disconnected building just turns OFF. There are some other effects to tubes, IIRC turrets do more damage if connected to Command Center and maybe something else.
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 21 Jul 2014, 12:58

Excellent description of the tube mechanism.

It's definitely just for the transport of people with the colony.

Tubes also connect buildings up to the DIRT (damage reduction) system, reducing the amount of damage they take from attacks and disasters.
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10199
Joined: 24 Jan 2006, 21:12

Re: Outpost [3] Development

Post by PicassoCT » 21 Jul 2014, 13:15

I think tubes should be 3d modells- if you want to add baked lighting. Or damage models or changing landscape, tubes will so much more flexible..
What if you want to be able to build them over canyons all of the sudden, like they exist on red_mars v2 or all the other maps?
More expensive in the short run then decals but worth it in the long run.
0 x

Google_Frog
Moderator
Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Outpost [3] Development

Post by Google_Frog » 21 Jul 2014, 13:51

You would be able to use ZK Overdrive for your tube system but it would need a lot of modification. Overdrive does a lot more than you want because the pylons have long range connectivity whereas you just want to consider touching tubes connected. Overdrive also does less than you want, for example I imagine you want the model of the tube to change depending on its neighbours. If I had to write your tube system I would start from scratch.

I have a question about how attached you are to the grid based aspect of Outpost. From your gif it looks like the game occurs on a fairly coarse grid, much like Warcraft 1 or 2. Do you want to have a large grid for your game or does it not matter?
0 x

User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Outpost [3] Development

Post by CarRepairer » 21 Jul 2014, 17:29

Towers connect if built as a grid.

https://www.youtube.com/watch?v=PQL4aGvqqmk

Done entirely in the unit script (this might not be the optimal way). They look for nearby towers and show their NSEW pieces accordingly.
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10199
Joined: 24 Jan 2006, 21:12

Re: Outpost [3] Development

Post by PicassoCT » 22 Jul 2014, 00:03

Image

Dunno witch look you prefer..
Attachments
outpost.jpg
(29.57 KiB) Not downloaded yet
pipes.7z
(489.11 KiB) Downloaded 4 times
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 22 Jul 2014, 02:31

Google_Frog wrote:You would be able to use ZK Overdrive for your tube system but it would need a lot of modification. Overdrive does a lot more than you want because the pylons have long range connectivity whereas you just want to consider touching tubes connected. Overdrive also does less than you want, for example I imagine you want the model of the tube to change depending on its neighbours. If I had to write your tube system I would start from scratch.

I have a question about how attached you are to the grid based aspect of Outpost. From your gif it looks like the game occurs on a fairly coarse grid, much like Warcraft 1 or 2. Do you want to have a large grid for your game or does it not matter?

Honestly, freeform tubes could be an option, although it may make connecting them a pain.

I like the one on the left picasso!
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10199
Joined: 24 Jan 2006, 21:12

Re: Outpost [3] Development

Post by PicassoCT » 22 Jul 2014, 08:16

ahem?
Then use it?
Its in the pipes.7z, together with the textures.. sorry for not renaming properly.. was tired yesterday..
Dunno about the Concrete Block in the middle though- might be slightly out of place.
Dosent solve the the problem though on how your pipe system overcomes terrain slopes.. might add some optional Airlock Component in which to hide angled connections when i get home..

ps: Im also entangled in another project and my game and exams, so yeah.. tight schedule there..
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 22 Jul 2014, 08:32

No worries, there's a lot happening, so I'm busy elsewhere.
0 x

Zhall
Posts: 46
Joined: 19 Jul 2014, 02:21

Re: Outpost [3] Development

Post by Zhall » 22 Jul 2014, 12:26

I'd hate to take on too much at once, but there are two more mechanics that will need to eventually be figured out.


First is the loading/unloading via docks at some buildings (show in the image of the trucks)

Will the units be able to travel below the ground... somehow? The trucks break into two and the back half descends into the ground.

Secondly there is the issue of building statuses.

I believe this could be achieved using glowing disks at the right location on each building, but I'm unsure of how to implement such a thing.

Image
0 x

User avatar
Anarchid
Posts: 1379
Joined: 30 Nov 2008, 04:31

Re: Outpost [3] Development

Post by Anarchid » 22 Jul 2014, 12:41

Generally, try to decouple animation and game mechanics in your mind.

On idleness:

Graphics-wise, there are animation hooks for building states, and you could get much more creative with displaying whether the unit is animated, e.g spawn particles, rotate things, etc.

If those are insufficient, you can also trigger arbitrary animation states from your LuaRules script.

Alternatively you could display this with an UI element. Or, if you're feeling advanced, you could also get shaders, like BAR does.

Mechanics-wise, you just need a gadget (synced, game-rules-defining, addon script) that would be either setting the engine's activation state parameter, or your own customized UnitRulesParam (probably better in the long run), on appropriate events (e.g, creation or destruction of relevant player building types).

---

On docks unloading:

Mechanics-wise, you'll need to write another gadget to control resource delivery and such, including telling the robot trucks where to go.

Animation-wise, i think it would be best to make the truck two actual units - the actual truck, and the attached trailer.

Units can be placed underground easily enough in multiple ways: attaching them to a transporter's piece that moves (most relevant to your gif), propelling them with MoveCtrl, setting their positions in synced gadgets, and probably some more.

---

Practically, i'd first try to get the rules part working, and then work on prettying it up.
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10199
Joined: 24 Jan 2006, 21:12

Re: Outpost [3] Development

Post by PicassoCT » 22 Jul 2014, 12:50

Anarchid wrote: On docks unloading:

Mechanics-wise, you'll need to write another gadget to control resource delivery and such, including telling the robot trucks where to go.

Animation-wise, i think it would be best to make the truck two actual units - the actual truck, and the attached trailer.

Units can be placed underground easily enough in multiple ways: attaching them to a transporter's piece that moves (most relevant to your gif), propelling them with MoveCtrl, setting their positions in synced gadgets, and probably some more.

---

Practically, i'd first try to get the rules part working, and then work on prettying it up.
Wrong, Sir, wrong. If you would have peaked at my gadget, you would have noticed that the factory gets when its load or undload is called, handed the id of the vehicle.
So it can set MoveGals, and even get the MoveCtrl, thus it can do with the thing whatever it wants..

At the same time the truck gets the info to unload, so he can trigger his animation.
0 x

User avatar
Anarchid
Posts: 1379
Joined: 30 Nov 2008, 04:31

Re: Outpost [3] Development

Post by Anarchid » 22 Jul 2014, 13:03

Right; strike the "write another gadget", replace "use picasso gadget" :)
0 x

Post Reply

Return to “Game Development”