[GAMEPLAY]

TRY IT

GAMEPLAY

So, in my previous post I detailed how I had built a load of new features. Basically all the ideas I had wanted to try out.
We have now done a decent bit of playtesting and, they actually all worked pretty well, it was fun and pretty much played out according to my theories.

however, we have of course whittled them down and made some refinements in the interest of accessibility for new players (Who are *all* players atm).
The biggest refinments are..

* You can no longer place lasers facing arbitrary directions, they will always face towards the opponents side. We really wanted to keep our 5 button controls scheme (up, down, left, right, action) so the way you placed lasers facing different directions was that the laser always faced towards your character as you placed it. Being able to do this did add some strategic richness especially in combination with lazer-beam reflections, however we found this control scheme just to awkward and unintuitive for new players so its gone.

* your base is a big block that takes damage as one unit, also it can be damaged by any kind of laser (no longer just ULTRA ones)

* ULTRA lazers, blocks and energy nodes are gone.. There are just normal and MEGA ones now. Two types of thing is enough, a normal one, and a bigger one.
the ULTRA laser was conceived as a game ender for games where one opponent is clearly winning but cannot quickly kill the opponent because they are hiding and dragging out the game. Now that the base is vulnerable to all lasers this is no longer necessary.


VISUALS

This has been a big couple of weeks for the visuals. Most of the programmer art is gone

blocks convey the following information..

* What is is Wall, Pgen or Lazer
* Who owns it
* how much health it has
* Whether it can connect to another block on each side
* Whether it is connteced to another block on each side[/li][/list]

Energy balls

Before, how much energy you had in the bank and how much energy blocks cost were represented by numbers. Now those elements + energy generation by pgens, *and* usage by lasers are all represented by a unified visual system.
The currency used to buy blocks and power lasers is 'energy balls', they are generated by power generators, stored in the bank, and used by lasers. You can see them moving around the energy grids you have built carrying out these various roles

This still has a ways to go, but we're really happy with it. It *shows* how the game works, how energy is money and also powers lazers. It conforms to our what-you-see-is-what-you-get design principle. We hope the detail will mostly wash over new players but teach them exactly how the game works the more they play.

The biggest challenge programmatically in doing this was that we doubled the value of each energy ball.
Before, I had a simple elegant system governing the energy economy. It decided every second where the energy produced would go, and it would be implemented instantly.
With the introduction of energy balls travelling over time things became a bit more complex, but it was still just one simple addition to the existing system.
The smallest unit of energy in the game was the amount required to power a normal laser for 1 second. So this was 1 unit of energy. With this value a wall cost 3 units and a lazer or pgen cost 10.
We thought representing the price of 10 balls for a pgen or lazer visually was too busy, so we decided to double the value of energy balls. So now a wall costs 1 unit and a pgen or lazer costs 5.
The problem is that now it would take a normal pgen 2 seconds to generate one unit of energy, and a normal laser 2 seconds to use it. I could have increased the tick rate of the economy to 2 seconds, but then, if you happened to place a lazer just after the last tick, it would take 2 seconds for the lazer to request energy + more time for the energy ball to reach it and it to power on. This could be annoying and also confusing for new players, wondering why their laser is taking so long to turn on.
So instead I made the energy economy work asynchronously. Now energy 'contracts' between energy producers and consumers in each system of connected blocks are decided every half second. However, the actual production and transfer of energy happens independantly, so a pgen will produce an energy ball 2 seconds from whenever it produced the last one..
I also wanted to keep certain behaviours that I had in my earlier system, for the energy to be automatically handled somewhat intelligently; energy is not sent to lasers that cannot be fully powered, also lasers prioritize using generated energy rather than using stored energy from the bank, they also get energy from their closest power generator.
I wont go into any more detail, but suffice it to say, implemetning this was *very* complicated. My elegant system is no more. Instead there is now a lot more code dealing with spefic circumsatnces, eg. a class dealing with routing energy to lasers, another one for routing energy *from* the bank. etc.

Also from a multiplayer point of view, each player simulates their own energy economy and simply alerts the other player only when one of their lasers has turned on or off.
The remote players economy and energy balls are simulated, but it is just for show, it has no effect other than visually.
 

[* Laserbeams reflect each other 90' when they meet head on]

Try it out!

Since shortly after the 1st games meetup where I demoed LazerGrrl, I had a big list of core gameplay ideas I'd like to try out.
I've now implemented all of them. (as well as tonnes of lesser features!!)

* Laserbeams reflect each other 90' when they meet head on
   More on this below..
   
* Mega and ultra Lazers, Blocks and Power Nodes
   There are now 3 levels for blocks, power nodes and lasers. Normal, Mega and Ultra. A megablock can only be damaged by a megalazer or above. Mega power nodes provide 4 power and a mega lazer uses 4 power. Ultra power nodes provide 12 power and an ultra lazer uses 12 power.
   The bigger lazers are built by placing the existing lazer blocks in a row.
   
* New map layout
   Now each player only has 3 normal power nodes on their side of the map, 2 mega and one ultra power node are in the middle to be fought over. The mega nodes are surrounded by weak walls, the ultra power node is surrounded by megawalls, so you must build a megalazer to get access to it.
   The connection points to your bank are now on the side walls rather than the rear, this makes your connection vulnerble to being cut by your opponent.
   The map is now symmetrical in 2 axes, this automatically doubles the strategic possibilities. Eg. now both players could concentrate on one side, or opposite sides, or both split their activities among both sides. I got this idea from the classic supreme commander map 'Finn's revenge'
   
   The idea behind this and the, mega ultra concept, was to address some shortcomings of the prototype.
   1. Players didnt fight over resources, they had more than enough on their side of the map. Now they have less on their own sides and the ones in the middle are far more valuable.
   2. The game didnt escalate, In longer games players would just build more and more normal lasers and pgens. Now the game has the tech vs spam concept from RTSes. you can still spam lots of normal lasers or fewer bigger lazers.
   
* Victory through killing enemy base aswell as enemy player
   If you build an Ultra lazer and are able to power it (you basically need to take the central ultra power node, or else have a ridiculous amount of energy in the bank to burn through) You can now destroy your opponents base (which is made of ultrablocks) and win the game that way.
   
   This was done to address the prototype issue where, Someone could be clearly winning, but the game would drag on, because the loser would simply hide in an awkward part of the map, or on their opponents side. Now if someone has the upper hand they can go for the central power node and build the game ending ultralazer. The losing player can try and harry their efforts of else try and assassinate their opponent with normal lazer spam.

...
   
In general the *ideal* I'm going for with these features is.....   
Far more strategic possibilities with the same small number of elements. (still just the 3 blocks as in the prototype, wall, pgen and lazer)
Yet, hopefully it is still accessible as new players can *still* play it as it was in the prototype, only building the normal level elements.

The 1st prototype was a true MVP (minimum viable product) for a playable game, that I literally threw together in a few days.
In terms of the core game mechanics, I imagine this most recent build to be the most bloated with features. The process from now will be one of playtesting, refinement and *cutting* features until we have arrived at the set of core game mechanics we want to present to the public. There is a Games Fleadh coming up in a couple of weeks. Our goal is to have this '1st public ready' set of mechanics ready for then. We will then use the Games Fleadh crowd as guinea pigs.



Lazer reflection

in theory this is a killer feature.. as it elegantly resolves what happens when lazers meet*, and using only the existing elements adds huge amounts of potential complexity
im thinking, noobs will be, what happpens when lazer hits laser? oh they reflect! and not think  anymore on it. intermediate players will descern the lasers turn right when they meet head on rule.. ans master players will be able to predict complex interactions and use them in their strategies

*In the prototype I did not code *anything* to handle this situation, both lazers just shot each other
 
WYSIWYG

We added one more design principle. WYSIWYG. What you see is what you get. This was a useful guiding principle when I was working out how to handle the movement.
I love the idea that there is no meaningless graphical detail, there can be detail, but it all conveys something meaningful. From vividly drawn crucial things, to more subtly portrayed less significant things. The subtle elements will wash over and be ignored by new players but they will subtly teach more experienced players exactly how the game works.
A really good example of this principle and a new feature I'm very happy with is the 'energy balls'. Now power consumption, production and storage are represented with energy balls. So you will see an individual ball leave a power generator and enter a lazer and the lazer turns on. You will also see energy balls leaving or entering the bank. In the future we wont have numbers for you banked energy amount, it will be represented by energy balls in a storage chamber.
 
All our design principles are now...

* Simple elements leading to complex possibilities.
* Secret RTS
* Accessible
* Fun! (for us to make)
* WYSIWYG

Play it now!

Got loads of work done this week! including...

* Interactive menus
* Player customisation room
* Customisation info stored on server, is applied when u log in.
* Leave and start new game
* Scorekeeping
* New round after round completes
* Esc - back to main menu, you leave the game and other players wins by default
* Can sell blocks at shop, money you get is proportional to blocks health

* Two new design principles.

In addition to the existing ones..

1. Simple elements leading to complex possibilities.
2. Secret RTS

we added..

3. As accessible as possible for new players.
We decided to prioritize the experience of casual player just checking it out for the 1st time. Therefore we want to keep the mechanics as intuitive and simple as possible. This has lead us to make decisions like prioritizing the keyboard as the main control input, as everyone playing on any kind of pc will have a keyboard.
This may sound like a no brainer but there were things in the game that went against that principle which we had actually started to like, notably the awkward controls, we had found a layer of strategy in them, when obstacles were in a certain arrangement it could be impossible to place a block where you want due to how the controls worked.
We decided the controls are the controls, they should be as intuitive and fluid, and not impede you as the player, as much as possible no matter what. Also because of the adversarial nature of a pvp game like this, strategy can be generated by almost any feature, even bugs. For example theres a bug in supreme commander (for reclaiming) that all good players take advantage of and is part of the meta.
We have a lot of ideas for features and tweaks that will add layers of strategy without sacrificing something as vital as intuitive controls.

4. If you have a fun idea, do it.
Already an unwritten rule for us. We're both doing this for fun. This keeps us excited and motivated to work on this project in our spare time for no material gain. Also I think it adds a certain purity to our designs, we are not compromising or fixating on stuff like monetization or fitting in to the market, in our design.
The new menu system is a good example of this. I just thought the idea of the menu system being rooms you walk around in and interact with would be much more fun (for me) than conventional ones so I built it.


* New movement mechanics

Iterating on the movement mechanics was the 1st feature to give me pause. I initially tried several different ideas. We wanted players to be able to move their build cursor without moving the player, to remove that 'awkward controls' issue mentioned above. But we liked the snappy way they currently worked. I made it so if you were holding a block, and were not in constant movement, and were changing direction, then, only the build cursor would move.
I also added a smooth lerping animation on the sprite rather than them just jumping from square to square, but this strangely seemed to make the movement seem much slower, so I changed it so the sprite lerps really fast between squares and then pauses before moving again.
Eventually I thought the controls were getting too complicated, we liked these controls, but the fact that they work differently when holding or not holding a block I think would be jarring to new players.
I then decided what really are the design principles for the movement, and started again from them.
The principles were.

1. Accessible (intuitive, consistent)
2. Responsive.
3. What you see is what you get.

So the final scheme I came up with based on those principles is...
Just the build cursor moves when you change direction at all times. This is consistent.
The character lerps smoothly from square to square, what you see is what you get, eg once the sprite has arrived at a new square you can immediately move again there is no pause.
However I also made the build cursor *snap* from square to square, this is so you can build or remove blocks at all times, even when moving, this was to keep the snappy responsive building from the early build.

So, because there is a pause when you change direction, the overall movement was a little slower than before, to make up for this I increased the speed which the character can move from square to square in a straight line. Previously I had made the time it takes to move from square to square the minimum time in which I could stop on the square I wanted. However, the smooth lerp of the sprite from square to square actually makes it easier to judge when your character will arrive at the next square so these 3 changes (pause when change direction, sprite lerp, faster movement speed) balanced out very nicely.

Is the jumping pose an homage to megaman?
I love the character art!

I got multiplayer working! I have never made a multiplayer game before so this was quite exciting!

Try it out. [enter the online door, if someone else also does so on their pc within 30 seconds you will be matched]
CONTROLS: wsad and space OR left stick and A button

...

I want Lazergrrl to be a webGL game, because people can just hit the link and immediately start playing. No download or install. This greatly reduces the barrier to entry in my opinion. Also the same build will run on windows, osx, linux, android + others maybe.

I'm building it in Unity, so I first looked at Unities built-in multiplayer services.
I quickly ran into the problem of these services not working in webGL builds. Their high level API and low level network transport layer are both restricted on webgl. Basically you'll need a server somewhere running a Unity desktop build for it to work, which seemed like too much hassle so I starting looking at another option.

That option was gamesparks. They provide a backend for games as a service. I've used them before for things like leaderboards. It turns out they have a realtime service for multplayer games. Is it part of their Unity sdk? yes. Will it work in a Unity WebGL build? yes!
I went through their very thorough tutorials on getting started with their realtime services.
Everything just worked and soon I was able to make the other character move over the internet!!

I 've initally built the worst / quickest to do / 'naive' implementation of the netcode. I generally program like that. Do whatevers simplest 1st and if its not good enough for some reason then iterate on it or optimise the bits that need to be optimised, but if it *is* good enough, happy days, its done, move on! I picked that up from reading about John Carmack in the book 'Masters of Doom'

Right now there is a big potential for bugs, it can be possible for two players to move into the same square if they do so simultaneously. Currently if you move on your machine, it sends a packet to all other machines telling them youve moved, theres no one source of truth.
I can fix that by writing cloud code on gamesparks that will be the source of truth for where stuff is in the game. So after I do that, when you hit the button to move...
* your character will start animating
* It will ask the server if the square you want to move into is occupied
* If its not, you continue moving and the server tells the other players you've moved, it also updates its own state with you in that new position.
* If it is already occupied, then the server tells you that square is occupied and you stay where you are.

Another thing is, I am using their 'structured data' in the packets I'm sending, which are like jsons or something. I'm sending packets with ints and other primitives in them. These structured data packets are bigger and therefore slower. If I want to optimize a certain netcode call I can switch it to unstructured data which is just a raw stream of bits. because this game is grid based I'll be able to get a lot of payloads (for instance mvement) down to 1 byte if I want, by individually setting bits to convey information.

Apart from that its actually not bad I think (though this is my first multiplayer implementation so who knows!!). The way multiplayer works is that a players own character and blocks are simulated perfectly on their own machine, and if they move, or die, or place a block, or one of their blocks gets destroyed, then they tell the other players.
In contrast the remote players behaviour does not have to be perfect, they will just appear to do whatever theyve been told. So for example. The local player *must* move from square to adjacent square one at a time, nothing else is possible, the local move command specifies what direction to move in. Whereas the remote move command just specifies a square to move to, so a remote player could jump from one square to another several squares away, this is in case packets are lost or there is lag. Its coded to assume that the information coming from other players is not perfect or in the the right sequence.

Hi everyone,

I’m Pablo but you can call me Pab, I’m the artist of LazerGrrl!
Before starting to produce game-ready art assets I wanted to make a concept image that would help me imagine this universe and its characters.
I started with Lazer Grrl herself. My idea is to make her super simple yet unique, thus the few features she has can become iconic.
Also, I got inspired by the first placeholder art made by Brian. I kept the big hands, ovalish heads and cool shades.

Here is an example of two logos. Personally, I prefer the black and white one, I think it looks like a sticker on top and that gives it some attitude, it can also lead to an interesting UI. In my opinion.

All this is WIP and all feedback is very welcome.

Thanks!

VVV Ok so is the standard structure? VVV

page 1 1st post -> Up-to date synopsis.

page 1, 2nd post -> original 1st devlog
page 1, 3nd post -> original 2nd devlog
page 1, 4th post -> original 3rd devlog
etc..

Final page, last post -> Most recent devlog.

I that case I should probably re-post the 1st devlog so it doesnt get lost when I overwrite the 1st post

Also thanks for taking the time to explain to a noob

I am having a go at devlogging for the 1st time.
I am confused as to how it works on this site.

I assumed that each week (or whatever) you make a new forums post detailing what you did and showing the results.

But looking at the devlogs here, a lot of peoples logs seems to be like 50 pages long.... Ok so I guess they are posting all their subsequent logs as replies to their 1st log....No, the 1st post contains the most recent info.. So are they going back and editing their OP every time they post a log??? What is going on!??!?!

Is there a way you are supposed to devlog here, or do you do do whatever?

Cheers for the feedback!!
"Does the laser run out of energy?"
in this 1st build lasers are limited by how much power you have.
Any group of connected blocks will form a power grid. One power generator will power one laser, any excess power will be turned to money if the grid is connected to your bank. So theres a tradeoff between having more lasers and earning money (if you have a lot of money you can even burn through it by having more lasers then power gens)

"It is possible to build defensively (successfully that is)?"
Well walls cost 5 energy and take 10 seconds for a laser to chew through (which uses up 20 energy) I did see people employ a turtle strategy that sometimes worked and sometimes didnt.

Planned any more level layouts?
I'll try and come up with one layout that works really well 1st. One thing I definitely didnt like in this build was that you dont really fight over resources like in supcom, the 6 power points on your side of the map are more than enough. I have ideas for a new layout that will hopefully foster competition.

How about other block types?
I have a lot of ideas for other blocks but I want to keep it as simple as possible. Ill use my simple elements -> complex possibilities design principle when making decisions. If you could use even the current set in loads of different ways I'd be happy. I think cus you build in this game (as opposed to bomberman where you destroy an existing grid) the more freedom I give players to build and invent new strategies the better.

...

The above being said, that build is sooo early. Literally just 2 & 1/2 days work. Just the 1st working *thing*. I felt I had to build it before I could even start thinking about the game properly. There will be vast sweeping changes to the gameplay.

I thought it was too early to actually put that build up live on itch.io (for the general public) but I'm happy for devs to play. Heres the link if youre interested...

http://lazergrrl.bitballoon.com/

Its wegGL so no install but its only local multiplayer so you'll need more than one person there to play!

[VVVV LATEST GIF,& LINKS VVVV]

VVVV LATEST GIF,& LINKS VVVV



Play 'LazerGrrl Lite' now in browser for free!!
Itch.io
Gamejolt

Get early access to the full desktop version
Itch.io

Check out the KickStarter video which shows the proposed features for the full version





Find an opponent, chat to devs, give feedback, take place in tournaments, on our Discord
Discord


Also...

Facebook

Instagram

Twitter

VVVV ORIGINAL 1ST POST VVVV





(Crappy Video of it in action (me and my dad playing, not exactly an actual match, just showing it working)


This is the first devlog for this game, and also my first devlog ever!!


I've been a professional game dev for about 4 years but I have never made a multiplayer game. I never even usually *play* multiplayer games.

However I went through a spate of playing two of them recently..

1. 'Go' the ancient Chinese boardgame, which I played on kgs

2. 'Supreme commander' the epic scale RTS, with an emphasis on strategy,  by gas powered games. I played this on the awesome community made lobby FAF, Forged Alliance Forever.[note: In supcom you have a commander unit who can build structures. What sometimes happens in the game is that players will have a 'base-war' by building static defences/ static artillery / shields with their commander.]

During this period I came up with the idea for this game. So I think in my twisted brain the core concepts of LazerGrrl are derived from from those two games.

I thought it I would have a go building it for fun + for the experience of making a multiplayer game.
There was alocal game-dev event coming up so I threw together the prototype in the video with Unity in 2-3 days. Its just a local multiplayer game with controller or keyboard input.

It got a good reaction from some people. Some people were able to have fun competitive games and play over and over. I was not expecting that considering it was such an early build, just the very 1st working prototype from my brain, with no playtesting or thought put into the game design. I reckon if I'm careful with this and make the right decisions it could end up being a pretty good game.

After talking to other devs and seeing people play it (and playing it myself for the 1st time) I started to formulate some initial design principles that will guide the design of the game. They're based on the games I was playing 'go' and 'supcom'.

1. Simple rules and element leads to complex behaviour.  (like in go) For example, only have a few kinds of blocks the player can build, but let them place them in many different  configurations, leading to many emergent strategies and counter-strategies

2. The game is like an RTS boiled down to the absolute core. By which I mean you fight over resources to spend on infrastructure which you use to fight over more resources.

An artist with some pretty impressive stuff agreed to work on it with me. and has already thrown down a few concept sketches.



So next steps are..

1. Get multiplayer working over the internet

2. Get people playing it.

3. Use metrics and feedback from players to inform decision making in the game design