ness Aug 10, 2014 3:03 pm
Subject: Singlepayer scenario

Hi all,

I've been playing around with alzi "menu_refactoring" code branch, and hacked a singleplayer scenario editor.
That means you have a new menu entry in "singleplayer" games called scenarios, next screen will list available scenarios found in maxr/scenarios, next screen you are in the game with ennemy players ! Ok for now all is static, so you are going to attack a static player not moving, but all sentry are activated so watch out for turrets !

How it works, each scenario is a text file that describe the game, it features:
- Choose the map
- Choose game settings
- Add 1 to 7 opponents
- Add Buildings, units and landing units

It misses (for now...):
- Clans selection does not work on human and on ennemy landing units
- Handle unit upgrades
- End of game conditions
- Load/save

Here is an example of scenario file, it is scripted with Lua language :
DownloadSource code (Text):
  1. scenarioName = "Assault : destroy ennemy base"
  2. description = "Watchout for anti aircrafts"
  3.  
  4. settings = LuaSettings()
  5. settings:setBridgeHeadDefinite(true)  -- default to mobile (no landing mining station)
  6. game:setSettings(settings)
  7.  
  8. human = game:getHumanPlayer()
  9. human:setLandingPosition(35, 60)
  10. human:setClan(0)
  11. for i=1,6 do human:addLandingUnit("bomber") end
  12. human:addLandingUnit("awac")
  13.  
  14. mapName = "Iron Cross.wrl"
  15. game:loadMap(mapName)
  16.  
  17. billy = game:addPlayer("Billy")
  18. billy:setClan(6)
  19. billy:setLandingPosition(50, 37)
  20. for i=1,8 do billy:addLandingUnit("missel") end
  21. for i=1,10 do billy:addBuilding("block", 43 + i, 33) end
  22. for i=1,10 do billy:addBuilding("block", 43 + i, 43) end
  23. for i=1,10 do billy:addBuilding("block", 44, 33 + i) end
  24. for i=1,10 do billy:addBuilding("block", 54, 33 + i) end
  25. billy:addBuilding("radar", 49, 39)
  26. billy:addBuilding("gun_aa", 45, 34)
  27. billy:addBuilding("gun_aa", 53, 34)
  28. billy:addBuilding("gun_aa", 45, 42)
  29. billy:addBuilding("gun_aa", 53, 42)
  30.  
  31. -- Start the game
  32. game:start()

I attached a few demonstration scenarios.

To make this run, you will have to compile the "scenario" branch from git (once I'll have find out how to push the code!).,
add the scenario directory into your maxr directory and that's it.
Note: this is still work under progress and is based on menu refactoring branch of alzi (we encoutered some SDL crashes at least on windows);
Testing is welcome as it will test both branch all toghether Smiling

After all this is set, I'll try to make the scenario more reactive by scripting unit movements and attacks !

Have fun !
Attachments:
scenarios.zip (Filesize: 2.82 KB)

alzi Aug 10, 2014 6:39 pm
Subject: Re: Singlepayer scenario

I realy like the idea!

And I'm curious to see the code and test it out.

Have you read the following old thread where we had a litle discussion on implementing an event system with lua?

https://www.maxr.org/showtopic.php?id=650

About access to the git repository: I think you have to talk to beko here. But you could just attach a patch file here for now.

ness Aug 10, 2014 7:51 pm
Subject: Re: Singlepayer scenario

Here is the patch, it applies on 51a346910372febd61aba6b5edcdefd3e00f80ac
(maybe no problem on more recent, but it depends what you changed ^^)
It contains 3 commits:
1. QtCreator project file to build directly from QtCreator
2. Lua library
3. The maxr code patch that implements scenarios

The code still has lots of "todos" but demonstrates what is possible.

No I did not read the older thread before; I also added a C++ binding that is called "Lunar" and does not requires boost.
The ideas are the same, on maxr events (start turn, end turn, enemy in sight, ...) lua functions is called, maxr add "context" to lua function call (visible units, map, etc...) and lua code can operate the units (move, attack, etc).

Thanks
Attachments:
scenario.zip (Filesize: 150.34 KB)

ness Aug 27, 2014 11:08 pm
Subject: Re: Singlepayer scenario

Just a little word to keep you informed that this is going further step by steps:

It is handling end of game conditions, and ennemy is moving it's units (greeat isn't it ? Tongue )

Sal Aug 28, 2014 10:50 am
Subject: Re: Singlepayer scenario

Sounds great ness, thanks for the update. Hadn't a chance to try it out yet, but hopefully soon.

ness Aug 28, 2014 12:40 pm
Subject: Re: Singlepayer scenario

I will provide an update when a few more things will be done.
Maybe it is easier if I give a full compiled package for testing ?

Sal Aug 28, 2014 2:30 pm
Subject: Re: Singlepayer scenario

It would help me much.

nonsinn Aug 29, 2014 3:32 pm
Subject: Re: Singlepayer scenario

hi ness,
first i wanna say thx to u and the work on a Scenario.
Second -and after a little talk with beko- we miss a feedback from you for the RealLife Meeting Wink

feel free to join us and keep up the good work
nonsinn

PS: everyone else who wanna join us, drop a note on the above mention link and i am sure most of you can join the meeting as well (if you contribute something to maxR Happy

ness Aug 31, 2014 2:38 pm
Subject: Re: Singlepayer scenario

Sorry, I won't be there for the real life meeting;
But I will try to have a few scenarios you can run and talk about there Smiling

alzi Sep 08, 2014 5:57 pm
Subject: Re: Singlepayer scenario

hi ness,

I found a little time to look at the scenarios (or at least at the patch file you posted).

I did not test it in real yet because it does not match the current source code anymore. Would it may be possible to upload a new package?

Some comments on the code so far:

At first: I like it. Looks realy good in general!

One thing I would like to mention is that you did not stick to our coding guidelines. That's not dramatic for now, but before any code goes into GIT it should match the rest of the code (at least in most points).

An other thing is about the usage of the "cGame" class. The current class hierarchy was not intended to be extended for such scenarios. Actually it was not intended to stay there at all. It should serve as temporary place where I could collect the information about different game starts (single player, multiplayer host/client, hot seat). Sp now it is easy to check which information those game starts have in common and which ones they don't so the whole thing can be replaced with something different, more generic that does not introduce any code duplication. But for now, it is okay, how you did it because this new and shinny solution is not available yet. I just wanted you to know about the issues so that you may do not loose any time and effort into something that has to be redone later on anyway.

edit:
here are two links about our coding guidelines:
- an old one in german: https://www.maxr.org/showtopic.php?id=163&page=2
- and a newer one in english: https://www.maxr.org/showtopic.php?id=652