Nounce now, name later - Page 2

Nounce now, name later

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

User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Nounce now, name later

Post by smoth »

11041 wrote:
smoth wrote: No all projects call for that.
Aye but as a personal opinion i think alot of mods could do with it. as their current system is either unsightly, looks poorly done or simply hard to find the information for each unit. (not displayed or displayed in a werid palce compared to the unit in question)

i suspect its as forb said that it requires time, effort and skill to create such a thing
Not really that time consuming. Forb just isn't strong in that stuff. Most projects here don't want >9000 health bars over their units.

when you say most "mods" what have you actually looked at?
11041
Posts: 13
Joined: 10 Feb 2011, 01:52

Re: Nounce now, name later

Post by 11041 »

TechA, BA, CT, Micron Wars, ZK, S1944.

Mostly: morphs in Tech Annihilation
Morhps in CT (though i think thats been fixed)
Ammo in S1944 (simply find it hard to gauge how much ammo each unit has)
Morphs in ZK (lack ETA but otherwise good)

Umm not sure what else think theres more am tired
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Nounce now, name later

Post by FLOZi »

Latest S44 has (a tweaked) CA healthbar widget, turning it on will turn off all the old S44 widgets (e.g. ammo, suppression, ranks), and give you the multiple bars you so desire. :wink:
camo
Posts: 29
Joined: 17 Aug 2010, 20:24

Re: Nounce now, name later

Post by camo »

Since most people have the urge to talk about bars over units instead of the game itself: I have a modified bar-widget and since i already wrote a lot of gadgets, know how to change it as well. So if there will be ammo, there will obviously be an indicator for it. Be it bar or something else. Research is currently only visible in the research-center, but will gain an own (permanent) widget. Infrastructure is there already anyway.
Enemy unit health will be invisible and own units might receive a bar, might receive some other indicator.


@Ammo:
Energy can not be used for ammo. You know the reason, since you all read the first post carefully. It will not be s44-like ammo. I like the concept, but find in unfitting for my project. Either standard, like in 1st post or maybe with ammo-trucks/planes driving around and automatically supplying the units.

@Models:
I will crawl through the model bases later on. Don't know how they play out, since I need individual parts to assemble them on-the-fly.
But I definitely need some sort of soldiers in battle-suits soon, maybe I find a kbot, that doesn't look to robotic in there.
camo
Posts: 29
Joined: 17 Aug 2010, 20:24

Re: Nounce now, name later

Post by camo »

Besides the things mentioned on page 1, the game has a custom Case-Sensitive-Gui now. I got the chance to try the module-system with multiple weapons the first time and it worked.

There is an unit-internal communication inplace, so all weapons automatically attack the same target, if in range etc. (See the one unit in the center) Weapons have low hitpoints and could be destroyed by strikes from above for example. That gives arty and aircraft new possibilities.

I liked the idea of lego, but won't use it. The style as such appears to be only useful for buildings to me. By being able to combine different chassis and weapons i can already create a lot of units anyway ;)

See the attached ingame-screenshot.


I rewrote a lot of internal stuff to make it even easier to extend the game with more content, but thats just code, not colors. So don't bother.
Attachments
ingame.png
Ingame-Screenshot
(465.44 KiB) Downloaded 2 times
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Nounce now, name later

Post by FLOZi »

Are you doing the modular system via transports?
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nounce now, name later

Post by knorke »

looks interessting!
i like that you seem to make new original lua instead of making pretty models and then going all "omgomg what scripts can i c&p"
Players build huge cities (17x34 atm) ontop of metalspots
if you "custom make" so much stuff, you might as well get rid of the metalmap and use your own system? Might give you more freedom maybe.
camo
Posts: 29
Joined: 17 Aug 2010, 20:24

Re: Nounce now, name later

Post by camo »

FLOZi wrote:Are you doing the modular system via transports?
Yep. Transport and usefull configuration / gadgetry to make it really work.
knorke wrote:looks interessting!
i like that you seem to make new original lua instead of making pretty models and then going all "omgomg what scripts can i c&p"
[...]
if you "custom make" so much stuff, you might as well get rid of the metalmap and use your own system? Might give you more freedom maybe.
You wanna say, the models arent pretty? :twisted:

Cities are very important and strong, so there has to be a limiter, preventing people from "spamming" them.
Consequently, they need fixed points on the map, where they can be placed.

I had 3 Options in my mind:
1) Add Metadata zu maps. Yeah nice, but shittons of work and limiting mapchoice. Hell, no!
2) Use Metal: Metal is (on good maps) placed in a fair, even and thought-over way. The amount can be varied (Tho few maps do it in an interesting fashion. Fixed Metal/Spot=Lame). It is only used once after building the city to calculate its internal production, so there can be cities with different outputs and useless ones (Not on a metalspot)
3) Spawn random information on the map. This can make even bad maps more interesting and prevents 1 Optimal Strategy/Map-Scenarios. But on the other hand I was wondering, how "fair" and "useable" it can get. Both yet to define. By spamming a lot of camo-spots it would, by the law of large numbers, become equal/fair. But there shouldn't be many cities around, i.e. few spots.
3+1) Limit total number of cities, let players place them whereever they want. Just got the idea a minute ago, have yet to think about it.



If you have any idea on how else to distribute or how to optimize the system, drop a message
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Nounce now, name later

Post by knorke »

Not completly sure how your "cities" work in detail but it seems more like few big cities fairly far apart? Well, metalspots are usually one every few meters.
1) Add Metadata zu maps. Yeah nice, but shittons of work and limiting mapchoice. Hell, no!
I think if you use the metalspots it will limit your map choice more in the long run: You will have to find maps where you like the layout, graphics and the metallayout.
Unless you make your own maps of course.

Storing some coordinates in a configfile is not that much work actually and if you want to adjust things it is much easier to edit a textfile vs recompiling the map.
ie for Conflict Terra such a file looks like:
http://code.google.com/p/conflictterra/ ... el_res.lua
And the gadget to read it is basically just a loop that loops through all entries:
http://code.google.com/p/conflictterra/ ... pawner.lua
(line 81 PutResourcesOnMap(), rest is blabla)

(Also note line 23 - 33, you can either include your metadata in the map or in the game.)

I now also use a similiar system for map features & even startpositions. So I basically only use the heightmap and plant trees & bushes as I wish.
S44 places its flags on metalspots but they can also define positions in a config file.
Imo such systems is much better then being limited by the metalmap or not being able to use a nice map because it has ie trees that are out of scale with your units.
Mappers basically only make maps for BA, if you want to use them for your game you have to be creative ;)
camo
Posts: 29
Joined: 17 Aug 2010, 20:24

Re: Nounce now, name later

Post by camo »

Now thats some information.

I had/have no real clue how maps work, so my assumption was I have to modify the maps or ask the mapper to include special data. Now, that I browsed the source I get the idea and could implement it. Since the resourceamount is only read once in 1 LOC, injecting a variety of different methods for resources are possbile.
So it will end in a Modoption: Use Metalspots, Use Geospots?, Use Metadata, Randomdistribution 1, ..., Randomdistribution n. With fallbackroutines, if no usefull data exists.

As for trees and other features: You refer to a Spring.GetAllFeatures/Spring.DestroyFeature-Combination at startup?


"but it seems more like few big cities fairly far apart": Yes. They join several metalspots. i.e. if you have the typical metalspotcloud, instead of placing tons of mexes, you build one city, since it spans them all anyhow.
camo
Posts: 29
Joined: 17 Aug 2010, 20:24

Re: Nounce now, name later

Post by camo »

An update after returning from a long journey and some development afterwards:


New resources:
Okay, it was more than 1 line to perfectly integrate it, but now I have an own resource-system, followed by a bunch of modoptions. Metal can still be used if desired and both "my" resources and/or metal can be scaled by a factor or adjusted to a fixed amount, if someone doesn't like my resmap or the metallayout of a map. If a resource-file doesn't exist, it falls back to metal-mode.
A random-resource-spawner might be another idea, to make games a bit less predictable beforehand.
gui1.png
New resources
(176.91 KiB) Downloaded 2 times
GUI:
Besides the "x units selected" hiding behind the minimap, all former GUI-Components are removed. (Someone knowing, how to get rid of the text?)
Building Modules
Building Modules
gui2.png (73.06 KiB) Viewed 894 times
All buttons show tooltips with descriptions and costs
Unit-Buildmenu
Unit-Buildmenu
gui4.png (329.21 KiB) Viewed 894 times
The unit-build-menu was renewed by codestructure and look. One can choose the components in any order, the last click sends the order. The blueish icons are the selected ones.
Selected units are shown by icon in the bottom part. Didn't take a screen how it looks with more than 1 unit, but i can tell, that they are shown smaller. So there always is 1 "mainunit" in a selection (this is important for the other bits of the GUI)

Code:
Besides adding code, some existing lines have changed to make it easier now or later. Research is disabled at the moment, since i will change it a bit more too.
As you can see on the one screen, a multiple of a unit-weapon-combination can be ordered at one time with the typical Hotkeys (i.e. 5,20,100 Units). A repeat-function is also there, but I hope it's never used. I don't have stumpys anyway :P

Beauty:
I still follow the concept of "the data is there". So the game-play and passing data around works fine now, it might just need a better representation.


Next:

Write random-resource-spawner with different presets in ModOptions?
Support for several resource-files per Map?
Finalize Research-System
Write Research-GUI
Widget to make creating resource-files just pushing buttons instead of C&P
Fiddle around in other GUI-Widgets
Continue with the useless-buttons-widget for attack etc.

Evaluate, if moving weapons by lua is better than transports (they make the weapons wobble quite a bit on bumpy terrain)
Post Reply

Return to “Game Development”