[Minigame] GoPlanets

[daemon]

I'd like to introduce you to a little project of mine called GoPlanets. I started this as part of my little Go playground but then it turned into an actual game. The idea behind this game isn't really new and I'm sure you're already familiar with this concept .



It's still unfinished and the AI is rather dumb but I think its quite fun to watch.

Download (Windows 32bit)
Source

As the title suggests, the game is written in Go so please tell me how it performs on your PC and of course everything else you can think of.
Enjoy!

[eXpl0it3r]

This is really a great game! Reminds me a lot of Risk.

Btw you've forgotten to package openal32.dll and libsndfile-1.dll.
It would be great to get a quick introduction to what the aim is and how it works. Also the menu should be more intuitive to use, i.e. highlight when you're over something you can interact with. And as you said yourself, the AI is not the smartest, so it's relatively easy to win.

It's quite nice how the ships are avoiding the planets and the other ships and I think you've quite some space to add some really nice effects etc. But so far I like it!

Regarding the AI:
It will in most cases attack grey planets, thus feel free to attack them directly.

[Euphemios]

This is a very good "Galcon Fusion" clone. I like the idea with the solar system. Well done

[Foaly]

I played a game similar to this a while back on a friends computer and liked it a lot, but it was on OS X and closed source and you had to pay for it. Its awesome to see this (very good!) clone.
There is a lot of potential in this! It would be fantastic if you develop it further!

[eXpl0it3r]

I love it when you can cripple the FPS with a few hundred ships.



I wonder though how high one could go, until one would hit an overflow...




As for the AI, I wish it was just a bit better. Currently you can win nearly all rounds by simply attacking the enemy directly as fast as possible, because the AI will first go an try to conquer the neutral planets, by which he'll automatically lose some part of his power. I mean if I attack the AI, I'll not only reduce the AI's ship count, but also slowly take over planets, however if I'd attack an empty planet, my ships would just die out from attacking the neutral planets without damaging the AI's fleet. Maybe one would have to implement two phases. In the first one will conquer the neutral planets and afterwards start the attack.
Personally I think there should also exist a small chance of being able to regain power. For example if the enemy manages to take you down to one planet with a low count of ships, it's impossible to fight back. An idea would be, that the refresh rate increases the lower your ship count is or the other way around. You could also think about a overall maximum limit and a planet limit.

Anyways I don't want to spoil your ideas, it's just a few things I've noticed when playing it a few times.

Btw. sometimes ships get stuck behind a planet and it takes them a while to break free (see first image).

[daemon]

Thanks for the valuable feedback  . I will probably do some improvements like a better AI, a more complete UI and possibly some visual gimmicks but don't expect an update any time soon and no I won't turn it into a full-blown Galcon clone. Anyway, I'll try to incorporate some of your ideas.

@exploiter
I'm surprised it's still running 
I'll see what I can do to avoid ships getting stuck. Maybe that's the reason why Galcon performs the collision only between ships in the same attacking group.

[daemon]

Update! 

Changes since the first build:

• New nebula shader
• New impact effect
• A visual indicator is displayed when conquering a planet
• A new AI (slightly better but still vulnerable to early game harass)
• Revamped UI
• Ships move slower but the spawn rates are higher (too slow?)
• Collision is done per fleet (ships don't get stuck anymore)
• Fixed a nasty bug in the quadtree (it's much smoother now)
• Hopefully better performance

Solar systems are still on my todo list.   

Download

The new menu


Some gameplay

[eXpl0it3r]

Yes! An update!

I'd call it a bug, not sure what you'd call it, but the round shouldn't end when only one color is in control of the planets, but it should end when only ships of one color exist. For example if you send out a huge fleet to take over a planet and in the same action the enemy steals your planet. Your huge fleet could still grab the next planet, but since the round ends when one color is in control of all planets, the fleet never reaches the destination...

I like the new impact effect. And yes it's much harder to fight against the AI, especially since it now always runs for the smallest population numbers.

[FRex]

On wine it runs only when I change fragment shader to just output black, with it it crashes:

Failed to compile fragment shader:
0:23(73): error: Could not implicitly convert operands to arithmetic operator
0:0(0): error: no matching function for call to `pow(float, )'
0:0(0): error: candidates are: float pow(float, float)
0:0(0): error:                 float pow(float, float)
0:0(0): error:                 vec2 pow(vec2, vec2)
0:0(0): error:                 vec3 pow(vec3, vec3)
0:0(0): error:                 vec4 pow(vec4, vec4)
0:23(74): error: Operands to arithmetic operators must be numeric
0:23(14): error: cannot construct `vec3' from a non-numeric data type

fatal error: malloc/free - deadlock
[signal 0xc0000005 code=0x1 addr=0x2f0 pc=0x42d9b8]

goroutine 1 [syscall]:
[fp=0x3a11a0] return()
   C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist934530519/go/src/pkg/runtime/asm_386.s:472
[fp=0x3a11c8] runtime.cgocall(0x49f584, 0x3a11d4)
   C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist934530519/go/src/pkg/runtime/cgocall.c:162 +0x10a
[fp=0x3a11d4] bitbucket.org/krepa098/gosfml2._Cfunc_sfShader_setFloat2Parameter(0x0, 0x13ca38, 0x44800000, 0x44400000)
   C:/Users/paul/AppData/Local/Temp/go-build931663947/bitbucket.org/krepa098/gosfml2/_obj/_cgo_defun.c:2377 +0x31
[fp=0x3a11f4] bitbucket.org/krepa098/gosfml2.(*Shader).SetFloatParameter(0x41e305a8, 0x4fe978, 0xa, 0x3a1218, 0x2, ...)
   font.go:1883 +0xe2
[fp=0x3a1258] main.(*Nebula).SetParams(0x41e30598, 0x44800000, 0x44400000, 0x4951a3f0, 0x3f8ea3fc, ...)
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/nebula.go:45 +0x89
[fp=0x3a1778] main.NewGame(0x400, 0x300, 0x420100, 0x42866c)
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/game.go:226 +0x1dbf
[fp=0x3a17c4] main.main()
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/main.go:52 +0x1a2
[fp=0x3a17dc] runtime.main()
   C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist934530519/go/src/pkg/runtime/proc.c:182 +0x8e
[fp=0x3a17e0] runtime.goexit()
   C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist934530519/go/src/pkg/runtime/proc.c:1223

goroutine 2 [syscall]:

goroutine 4 [chan receive]:
main.func·003(0x0)
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/physics.go:74 +0x8b
created by main.NewPhysicsManager
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/physics.go:76 +0xff

goroutine 5 [chan receive]:
main.func·003(0x1)
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/physics.go:74 +0x8b
created by main.NewPhysicsManager
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/physics.go:76 +0xff

goroutine 7 [chan receive]:
main.(*SoundManager).FadeIn(0x41e8f000, 0x41e70a80, 0x41e30568)
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/soundManager.go:174 +0x4c
main.func·005()
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/soundManager.go:194 +0x82
created by main.(*SoundManager).FadeWorker
   C:/Users/paul/Desktop/krepa098-goplanets-cb9dce2581e1/soundManager.go:200 +0x5f
AL lib: (WW) FreeContext: (0x7ce60fd8) Deleting 67 Source(s)
AL lib: (WW) FreeDevice: (0x7cd32930) Deleting 3 Buffer(s)

[eXpl0it3r]

On wine it runs only when I change fragment shader to just output black, with it it crashes:

Not sure why it should be the devs job to fix Wine's problems...

Also the project is open source, so feel free to build your own Linux binary.

[FRex]

It's not just wine problem, shader is not compiling in c++ either.
This:

  color.rgb = vec3(     1.0-pow(l,pow((1.0-sin(length(pos)))*colorSeed.r,2)*2),
                        1.0-pow(l,pow((1.0-sin(length(pos)))*colorSeed.g,2)*1.4),
                        1.0-pow(l,pow((sin(length(pos)))*colorSeed.b,2)*1.2)  );

changed to this:

  color.rgb = vec3(     1.0-pow(l,pow((1.0-sin(length(pos)))*colorSeed.r,2)*2.0),
                        1.0-pow(l,pow((1.0-sin(length(pos)))*colorSeed.g,2)*1.4),
                        1.0-pow(l,pow((sin(length(pos)))*colorSeed.b,2)*1.2)  );

works, because C(++) Linux and GL aren't C#, Windows and D3D so we get inconsistencies like that and more.
I always make floats end in .0 because things like that tend to happen...

[daemon]

Thanks for the feedback.

On wine it runs only when I change fragment shader to just output black, with it it crashes:

My bad. I somehow missed the warnings during shader compilation. Btw. I've uploaded a linux binary as you probably don't want to pull the whole Go toolchain   

I'd call it a bug, not sure what you'd call it, but the round shouldn't end when only one color is in control of the planets, but it should end when only ships of one color exist. For example if you send out a huge fleet to take over a planet and in the same action the enemy steals your planet. Your huge fleet could still grab the next planet, but since the round ends when one color is in control of all planets, the fleet never reaches the destination...

Yep... indeed. I'll change that in the final release.

[FRex]

It ran fine on wine and I use 32 bit linux.
Really anything with SFML runs fine on wine(compared to old windows games that use DirectX 8 or 9 that just die after launch, blackscreen, miss sounds etc.), I ran Zloxx 2(for hours) and one other SFML game and there were no problems.

[Yemeni Cpluspluser]

Very fun and exciting, I played it for 16 minutes ^_^

[Foaly]

The update looks very nice! I have to try it as soon as I get home!