Gameplay concept : Objective based skirmish - Page 4

Gameplay concept : Objective based skirmish

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

sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

K I believe I know what I was doing wrong

Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift)

doesn't execute a command or so , it just says , the next active Command is said command. But I don't get it then, who actually executes the command ? I suppose in the case of move and attack it's an onMouseClick() or onMouseRelease(), but what about state commands like Cloak ? Who executes those commands , and how do I intercept the call there ? Any info you can give me on this ?

Bleh I don''t get it agian this was my latest attempt

K I believe I know what I was doing wrong

Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift)

doesn't execute a command or so , it just says , the next active Command is said command. But I don't get it then, who actually executes the command ? I suppose in the case of move and attack it's an onMouseClick() or onMouseRelease(), but what about state commands like Cloak ? Who executes those commands , and how do I intercept the call there ? Any info you can give me on this ?

Bleh I don''t get it agian this was my latest attempt

Code: Select all

function ClickFunc(button) 
	local _,_,left,_,right = Spring.GetMouseState()
	local alt,ctrl,meta,shift = Spring.GetModKeyState()
	local index = Spring.GetCmdDescIndex(button.cmdid)
	if (left) then
		Spring.Echo("active command set to ", button.cmdid)
		Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift)
	end
	if (right) then
		Spring.Echo("active command set to ", button.cmdid)
		Spring.SetActiveCommand(index,3,left,right,alt,ctrl,meta,shift)
	end
end


function widget:UnitCmdDone(unitID, unitDefID, unitTeam, cmdID, cmdTag)
	Spring.Echo("unit command is done",unitID, unitDefID, unitTeam, cmdID, cmdTag)
	--see if cmd is a state command
	local idx, cmd_id, cmd_type, cmd_name = spGetActiveCommand()
	Spring.Echo("active command",idx, cmd_id, cmd_type, cmd_name)
	if (not cmd_id) then return end	
	
	Spring.Echo("active command found")

	local cmdDesc = spGetActiveCmdDesc( idx )
	local isState = (cmdDesc.type == CMDTYPE.ICON_MODE and #cmdDesc.params > 1)
	
	Spring.Echo("isState=", isState)
	-- if state then update state text on button in main window, step one will be finding the right button
	if isState then
		local buttons = window0.children
		local buttonToUpdate
		for i=1, #buttons do
			if(buttons[i].cmdid == cmdID)then
				Spring.Echo("Update button found")
				buttonToUpdate = buttons[i]
				break;
			end
		end
		buttonToUpdate.caption = cmdDesc.params[cmdDesc.params[1]+2]
		window0:RemoveChild(buttonToUpdate)
		window0:AddChild(buttonToUpdate)
	end
end
The idea was to use the unitCmdDone method to find the new text of the cmd and then put it on the chilibutton. However it failed miserably this is my output of the echo statements

Code: Select all

[f=0000156] active command set to , 95
[f=0000157] unit command is done, 1255, 2, 0, 70, 1
[f=0000157] active command, 0, nil, nil, nil
in one frame change my active command is bye bye , oh and the unit command activated is said to be 70 ... WTF I asked for command 95 !
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Gameplay concept : Objective based skirmish

Post by Google_Frog »

Spring.SetActiveCommand sets the command on the mouse cursor iirc.

I think what you want is Spring.GetOrderToUnit(unitID, cmdID, params, opts). This executes any command.

Although I don't quite understand the question.
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

Google_Frog wrote:Spring.SetActiveCommand sets the command on the mouse cursor iirc.

I think what you want is Spring.GetOrderToUnit(unitID, cmdID, params, opts). This executes any command.

Although I don't quite understand the question.
Well my problem is the following. I have put all commands of a selection of units in a chili window as chili buttons. Commands like attack, stop, move work as they should. Then you got the commands like cloak and fire state. If I press those buttons, the commands gets executed as it should, but the button doesn't change name. It should go from uncloacked to cloaked for instance. I understand this is the programmers responsability to let this happen. But I don't get how to do it in the spring lua structure.

In java I would have done something like this

Code: Select all

JButton button = new JButton("uncloacked")
button.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
				textField.setText("cloaked");				
			}});
What happens is that , when I press this button the eventthread gets an event, it finds this actionlistener, triggers the actionperformed and changes the text on the button redraws the button. From what I understand I'll have to do this all manually in Lua. So far I understand a few things

- you create a ChiliUi control and with OnMouseDown = {ClickFunc} you specify the function ClickFunc needs to be triggered (in analogy with java actionperformed).
- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)
- Some post action commands run to clean stuff up , I found this one widget:UnitCmdDone(unitID, unitDefID, unitTeam, cmdID, cmdTag)

Well in the unitCmdDone I'm trying to find out what the new text of my button will be, by fetching the last active command and getting it's desc, update the caption of the button, redraw the button (aka take from window , put back on window). But it seems unitCmdDone gets another command , then the command I asked to execute.

My question is now why is that a different command, and am I right to try and do my text change at this location ?

==============

Well I got a sollution now but I'm afraid I picked a rather expensive one

Code: Select all

function drawPanel(unitSelection)
	RemoveChildren(window0)
	if (#unitSelection ~= 0)then
		local commands = findUniqueCommandsFromSelection(unitSelection)
		table.sort(commands,function(x,y) return x.action < y.action end)
		local rowcount = 1
		local step = 1
		for cmdid, cmd in pairs(commands) do
			rowcount = createMyButton(window0, commands[cmdid], step, rowcount) 
			step = step + 1
		end
	end
end

function widget:CommandsChanged()
	Spring.Echo("commandChanged called")
	local selection = spGetSelectedUnits()
	drawPanel(selection)
end
each time a command changes it redraws my entire command panel... it works , but ... how often will widget:CommandsChanged be called ? I allready noticed once I deselect a unit , it gets called twice for some reason ...
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

ok little progress update on this WIP

http://www.gravegast.be/~sunspot/temp/test.png

as you can see the ui is comming along. There are a few things I still like to do, a status bar below , that shows unit info when you hover over a unit

Things done
- commands seperated in 3 windows
- build commands became image buttons
- score and unit limit now in teamcolour
- implemented chili chat but with a twist, you open the chat window with enter and it stays unless you press the X button in the top right. I made this as an option so the old functionality still works if you want it to. Config is in the script though not a config file as it should be
- implemented chili resource bars but I removed energy since I don't plan on using energy

Things to do
- balance units
- implement a real map with a config file for my gametype
- find a name for the game
- implement a statusbar for hovering over units
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

Little WIP update,

Accomplished
- Implemented a status bar when hovering over units showing hp, and weapons damage, range
- Wrote 2 tutorials for chili

Things to do
- balance units
- implement a real map with a config file
- find a name for the game
SpikedHelmet
MC: Legacy & Spring 1944 Developer
Posts: 1948
Joined: 21 Sep 2004, 08:25

Re: Gameplay concept : Objective based skirmish

Post by SpikedHelmet »

This is similar in concept to BT I am working on, in that it is based on multiple CTF with ticket drain to determine winner, no base mechanics (we use a single permanent indestructible building), revolving around tactical play and using various forms of "special bonus features" for flag capture points (some have guns, some unlock units, some unlock abilities etc).

Check out Battletech Legacy subforum in one of the feature threads and you can see if there's anything you'd like to use.

Sharing is, after all, caring.
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

SpikedHelmet wrote:This is similar in concept to BT I am working on, in that it is based on multiple CTF with ticket drain to determine winner, no base mechanics (we use a single permanent indestructible building), revolving around tactical play and using various forms of "special bonus features" for flag capture points (some have guns, some unlock units, some unlock abilities etc).

Check out Battletech Legacy subforum in one of the feature threads and you can see if there's anything you'd like to use.

Sharing is, after all, caring.
Well seems we had the same idea. In the long run , I'de like to have aircraft factories as objectives to give air units, or some kind of first aid station that will give repair bots. Those units would give another advantages to the player at the cost of more unit limit. But that is still in concept phase. My first priority is getting my 3 types of units working. I'll take a look at the code for your flag capturing to see if I missed a use case. But to be hounest I'm wrapping up my code work atm. It seems to be working now and is ready to be tested. However I need to find a fitting map to implement my system on. I was thinking some kind of "tug of war" type , with the objectives in a more or less straight line towards eachother. Dunno I'll see whata I'll do with it
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Gameplay concept : Objective based skirmish

Post by Google_Frog »

- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)
Are you sure this step works for state toggle commands?

Aside from that why do you need to use unitCommandDone? You should know what the new state of the button should be when the button is pressed.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Gameplay concept : Objective based skirmish

Post by knorke »

sunspot wrote:Things to do
- balance units
- implement a real map with a config file
- find a name for the game
Are you going to use the TA unit models or make/get new ones? It would seem like a waste to use TA models after all the custom stuff you did.
If you chose a theme there it would help also with finding a name. (do insects fighting over picknick food!)

For the maps, you can probally find something suitable on http://springfiles.com/spring/spring-maps
There are literally tons of maps, most not really well known, so they would still appear "fresh" and unique.

If you want your game to be played (and not just a techdemo) it might also be helpfull to make sure that it can be played with odd player numbers in FFA fashion. Realisticly, players will mostly be BA players who just check out new stuff between matches. (at least for start. maybe your game gets lolfamous, who knows)
So if ie 3 players can nicely play 1v1v1 instead of having to wait for a fourth player that helps to start games quicker.
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

Google_Frog wrote:
- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)
Are you sure this step works for state toggle commands?

Aside from that why do you need to use unitCommandDone? You should know what the new state of the button should be when the button is pressed.
I've tested it extensivly with state commands , cause those where the once giving me headaches. It does work , but indeed I would have expected to know what the next state was after pressing the button. But if I query the new state of the cmd at the location of pressing the button, the state didn't change. Maybe I was doing something wrong or some other voodoo was going on. I noticed that on the next frame after the setActiveCommand was over, the state was actually different. I've tried several approaches, but in the end calling CommandsChanged seemed the better sollution to me. There is one thing I don't like though, you trigger that method twice after issuing a command. So it's certainly not perfect ! If you see an improvement here I'm all ears. I've spent about a day or two on this problem.
knorke wrote:Are you going to use the TA unit models or make/get new ones? It would seem like a waste to use TA models after all the custom stuff you did.
If you chose a theme there it would help also with finding a name. (do insects fighting over picknick food!)

If you want your game to be played (and not just a techdemo) it might also be helpfull to make sure that it can be played with odd player numbers in FFA fashion. Realisticly, players will mostly be BA players who just check out new stuff between matches. (at least for start. maybe your game gets lolfamous, who knows)
So if ie 3 players can nicely play 1v1v1 instead of having to wait for a fourth player that helps to start games quicker.
Well tbh when I first started this I had a mechwarrior 4 theme in mind. But someone is allready doing a BT style game (SpikedHelmet) so that would not be that nice to do. Then again I'm no artist, let alone modeller. K I might still be able to get away with the modelling, I modelled some mean looking "shadow cat" (untextured) in Rhino back when I was still making units for TA. So if I'm to use different models I would have to find an above average modeller (wouldn't settle for less hehehe) and texturer. For the first testing TA models won't be that bad.

The idea is that you can play it with as much allied teams as the engine allows and as many players as well. Each player is limited to a unit limit of 20 with some units costing more then one unit limit (well one for now the artillery unit). Each team will have a counter that needs to reach x (have 500 in mind). If the engine allows it, drop in and drop out functionality would be nice. It's real intended purpose is to have at least 2 teams of 5-8 players fighting eachother. But I'm not dellusional , I know it will be hard to get even 4 players playing it. Unless I get really really lucky and people will enjoy this type of game a lot :)
User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Gameplay concept : Objective based skirmish

Post by Niobium »

sunspot wrote:
Google_Frog wrote:
- In ClickFunc you need to say to Spring engine next active command with Spring.SetActiveCommand(index,1,left,right,alt,ctrl,meta,shift). Incase of a move or attack command , this command seems to be bound to the mousecursor, incase of a statecommand it seems to execute either at the end of the current frame or the beginning of the next (I'm not sure about this)
Are you sure this step works for state toggle commands?

Aside from that why do you need to use unitCommandDone? You should know what the new state of the button should be when the button is pressed.
I've tested it extensivly with state commands , cause those where the once giving me headaches. It does work , but indeed I would have expected to know what the next state was after pressing the button. But if I query the new state of the cmd at the location of pressing the button, the state didn't change. Maybe I was doing something wrong or some other voodoo was going on. I noticed that on the next frame after the setActiveCommand was over, the state was actually different. I've tried several approaches, but in the end calling CommandsChanged seemed the better sollution to me. There is one thing I don't like though, you trigger that method twice after issuing a command. So it's certainly not perfect ! If you see an improvement here I'm all ears. I've spent about a day or two on this problem.

Code: Select all

local updateRequired = true

function widget:CommandsChanged()
    updateRequired = true
end

function widget:DrawScreen()
    if updateRequired then
        updateRequired = false
        ... Update buttons etc ...
    end
    ... Normal :DrawScreen code ...
end
This is the pattern to use, especially for when commands are changing many times in a single drawframe (could be many commands, could be low FPS). Note that this will fix your state problems, and there's no need for any additional command related callins. Also you should be caching buttons where possible, i.e. the build unit buttons which never change.
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

Niobium wrote:

Code: Select all

local updateRequired = true

function widget:CommandsChanged()
    updateRequired = true
end

function widget:DrawScreen()
    if updateRequired then
        updateRequired = false
        ... Update buttons etc ...
    end
    ... Normal :DrawScreen code ...
end
This is the pattern to use, especially for when commands are changing many times in a single drawframe (could be many commands, could be low FPS). Note that this will fix your state problems, and there's no need for any additional command related callins. Also you should be caching buttons where possible, i.e. the build unit buttons which never change.
Thanks for this one, I'll implemented it in the next update. I've had a talk with JK about caching the buttons. If I understood him correctly , it seemed it wasn't to big a deal , to let the control instantiate itself each time. My first idea was to make some kind of Cache class that would hold several caches by id/name that lives somewhere globally and could be called in every script. But that might be a bit overkill. So caching the buttons on script level might not be a bad idea.
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Gameplay concept : Objective based skirmish

Post by Google_Frog »

Be aware that assuming the state of a command will change one frame after it is toggled will not work due to the way multiplayer is synchronised. The gamestate is synchronised by computers sending all commands to each other and executing them within the same frame. This means the commands you give to your units cannot be applied instantly even locally. So the old command state is still active in the frame which you give the change state command and the state will only change a frame later if you have no latency which makes things that depend on fast command changing poor solutions for real games.
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

Google_Frog wrote:Be aware that assuming the state of a command will change one frame after it is toggled will not work due to the way multiplayer is synchronised. The gamestate is synchronised by computers sending all commands to each other and executing them within the same frame. This means the commands you give to your units cannot be applied instantly even locally. So the old command state is still active in the frame which you give the change state command and the state will only change a frame later if you have no latency which makes things that depend on fast command changing poor solutions for real games.
I see so whats for me a one frame update now, in a real game can be several frames later , untill all players have recieved the message and ack they are ready to update. But this design pattern Niobium just wrote , will solve that problem won't it ?
User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Gameplay concept : Objective based skirmish

Post by Niobium »

sunspot wrote:But this design pattern Niobium just wrote , will solve that problem won't it ?
Yes.

(:CommandsChanged fires when commands change, not when they are sent, so latency etc isn't an issue. The problem is that :CommandsChanged is fired just before spring decides to update the command descriptions, so the best you can do is flag it, then check the flag on the next callin into the widget, for what you're doing :DrawScreen works fine)
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

Small WIP update, I roughly implemented a real size map, pathway_v2. Next up was balancing the units.

But tbh I have no clue what I'm doing with it. How do I decide how much armor I will give it, how does one value of damage relate to one real ingame value of damage. How big are ranges actually etc... So it' not really that easy.

I realised there is still one case I have to prevent. The objective structures can be captured and then self-destructed... this should be prevented somehow. After that I believe I can wrap up the big programming and just do tweaks for bugs.

Next I'll probably gonna need some testing. I'm also looking at the challenge of writing an AI that can play the gametype ... and tbh that seems to be the hardest thing to do of all.

ok well carrying on ... 2 more days of work and then 2 weeks vacation ... can't wait
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Gameplay concept : Objective based skirmish

Post by smoth »

Check the wiki docu on unit tag I think we have a way to disable that on a per unit basis
sunspot
Posts: 104
Joined: 09 Jun 2011, 12:17

Re: Gameplay concept : Objective based skirmish

Post by sunspot »

smoth wrote:Check the wiki docu on unit tag I think we have a way to disable that on a per unit basis
Idd , there is , thnx that saves me some code :)
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10454
Joined: 24 Jan 2006, 21:12

Re: Gameplay concept : Objective based skirmish

Post by PicassoCT »

You could deactivate selfdestruction? Its just a tag..

Oh, and game names... make something with A at the start so its top of the list
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Gameplay concept : Objective based skirmish

Post by knorke »

you probally also want to disallow transfering ownership of the captured unit: (h key ingame, if you didnt know)

Code: Select all

function gadget:AllowUnitTransfer(unitID, unitDefID, oldTeam, newTeam, capture)
	if (blabla) then return false end --no unit transfer!
end
Post Reply

Return to “Game Development”