InWar: Kingdom Rebirth

WIP games, tools & toy projects
#1

Hey guys,

I wanted to share with you the project we are currently working on. This is hobby project, meaning that most of the work is done during nights/weekends. It is our first project.

1279×840 278 KB

Technologies: LibGDX
Download link: https://goo.gl/npnGp6

Basically, the game is 2D, with platform view, tower of defense (dunno if we can call it like that, hope so :P). The main idea, is that the waves of enemies might be coming from both sides of the screen, but player can only see one of the sides. The player controls the horseman, who moves across the map and can mobilize units to take them to the place which they should defend. At the moment, the most basic set of features have been implemented to make the game playable, there are still many tweaks and effects are to be implemented.

Controls:

  • Knight is moved with left/right arrows
  • Units can be recruited from the recruitment bar below
  • Units can be mobilized by the knight by clicking on the left button, above knight’s silhouette
  • Units can be sent to tower by selecting the unit and clicking the button above its silhouette

The feedback we are looking for currently (opinions on any of the points is more then welcome!):

  • Controls. They seem a bit retarded to me, maybe you have some suggestions to make it better? Maybe I should highlight the units which can be mobilized when the knight is selected and is passing nearby? I plan to make it a mobile game, that is why I do not do fully hotkey-based controls.
  • The view. Should I stick to pure 2D platform style view? Or maybe make it slightly isometric with an area of 50-150px, so the units do not stack that much on top of each other and it is easier to identify the quantity of enemies?
  • The idea itself. It is not new idea, for example Kingdom: New Lands has similar view and some concepts, but we believe that our game will be more dynamic, more battle based, rather then focusing on the economy.

NOTE:

  • The knight is not attackable because we do not have sprites for that
  • The tower when the enemy is close “shuts” the gate, so enemy cannot pass, but also ally troops cannot pass.
  • Troops have some automatic behaviors which we still have not fully tuned

Feel free to add any criticism and feedback (if you spot a bug feel free to blame us :D)!

#2

Controls:

Use flicking and dragging for everything that moves.
The follow mechanic is clunky right now, split it into two: follow-attack-on-sight and follow-ignore-enemy, so that the player does not have to click around frantically to release his followers.

  • follow and attack on sight: drag from unit to knight
  • follow and ignore enemy: drag from unit to knight, then double click knight
  • tower: drag from unit upwards in the direction of the tower.
  • cancel: tap or drag/flick downwards from the unit

Whatever you do, never make the player click very small, moving icons.

You could use the gyro/accelerometer combo for moving the knight (aka viewport) at various speeds.
If not, use customizable buttons or so, something you cannot click accidentally (seperate it from the battlefield, you need to be able to click your units without accidentally moving the viewport)

View/Graphics:

Stick to one thing and make everything fit together.
The 3d pre-rendered units and their animations look butt-ugly compared to the drawn backgrounds.
If you cannot support the workload, make it simpler, but never make it inconsistent.
Both views would look good if they are polished and well made, but keep in mind that isometric view also needs some 3d gameplay for full effect, it’s a huge step from what you have right now. it also eats away your screen-space that you might need for well laid out buttons.

Game:
If units start coming in from both sides, it might get frustrating, since the player is stuck in his slow-moving viewport.
Also, moving the knight doesn’t feel rewarding, it’s almost as if the knight is just a fancy overlay tacked to the viewport… oh, well it actually is just that ;D
Make the knight be able to fight as a hero unit or interact in some other meaningful way and add some nice animations and speed ramps.

This is just a big dump of half fleshed-out thoughts on this, take it with a grain of salt.

#3

Damn nice ideas out there! When I will be at home I will go through once again, but the things you say sound damn good :P! To defend the knight a bit, we plan to make a bit bigger intervals between the waves, so the traps can be placed in the forest (for example), ambushes, maybe to pick some bonuses. Knight also will have some stamina based skill to sprint. We were also thinking, as a bonus, you might get a spyglass, which would allow you to check fast the other side of the castle without actually moving there. Thanks, I loved your feedback :)!

#4

Hi,
I played your game and found it very good. I love graphics, it’s awesome:).
I like the way units are moving, very realistic. Great job.

Infantry when is in tower is useless and exposed to enemy fire. Maybe by clicking on the yellow arrow the unit should go to fight with enemy soldiers through some gate. My tactic based mostly on archers.

When archers are in tower and enemies are cutting the tower, arrows have strange/funny path. Maybe consider case when archers must keep foe units at distance and when they are close to a tower the archers cant shoot them and you need to send knights. Would be more fun:).

#5

Thanks for you feedback :)!

First of all, since you mentioned the assets I must say that the credit must be going to Reiner’s Tilesets (http://www.reinerstilesets.de/). Since we do not have yet the credits section it is important to identify the people who actually provided the graphical components (I will try to compile the whole list tomorrow), the real heroes :P!

Secondly, regarding the arrows. I agree, at some point the trajectory is so damn weird :D! You suggestion is interesting as it would force the player to recruit additional melee troops or even place some obstacles/traps in the path of the enemies, so they could be slowed down and still hit by the range units. On another hand, for archers, we were thinking to experiment with dynamic hitbox, so deployed on the tower units, instead of receiving the same obstacle location as all other units, would ignore the tower where they are deployed at and simply shoot down. I am not sure how it will look though, we will definitely experiment with proposed by you solution :)!

#6

Hi

It doesn’t work on my main computer under Mageia Linux 5.1:

[quote]Exception in thread “LWJGL Application” java.lang.ExceptionInInitializerError
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setVSync(LwjglGraphics.java:558)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:122)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.lwjgl.opengl.XRandR.findPrimary(XRandR.java:326)
at org.lwjgl.opengl.XRandR.ScreentoDisplayMode(XRandR.java:315)
at org.lwjgl.opengl.LinuxDisplay$3.run(LinuxDisplay.java:746)
at org.lwjgl.opengl.LinuxDisplay$3.run(LinuxDisplay.java:743)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:743)
at org.lwjgl.opengl.Display.(Display.java:138)
… 2 more
AL lib: (EE) alc_cleanup: 1 device not closed
[/quote]
However, XRandR works on it:
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
VGA1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
1920x1080 60.00 + 60.00 60.00
1920x1080_60 60.00*
1600x1200 60.00
1680x1050 59.95
1600x900_75 75.00
1600x900_60 60.00
1280x1024 75.02 60.02
1440x900 74.98 59.89
1280x960 60.00
1368x768_75 75.00
1368x768_60 60.00
1360x765_75 75.00
1360x765_60 60.00
1152x864 75.00
1280x720_75 75.00
1280x720_60 60.00
1024x768 75.08 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
640x480 75.00 72.81 66.67 60.00
720x400 70.08
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

I use XRandR 1.4.3. What can I do to work around this bug?

P.S: It’s caused by an unfixed bug of LWJGL 2:


Using the LWJGL 3 backend of LibGDX should solve this problem.

#7

Cheers, thank you for the input, going to try to plug the LWJGL3 though Gradle to see if it solves the problem! Was looking forward to hear from people using Linux :)!