Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


starbasecitadel

Member Since 31 Aug 2012
Offline Last Active Aug 20 2014 10:38 AM

#5086461 starship death and regeneration

Posted by starbasecitadel on 16 August 2013 - 06:30 AM

Great feedback, thanks LorenzoGatti and Luckless, this helps a lot!

 

 

1. Wave spawns: Dead users will spawn with the next 'wave', time adjusted to the game. This means a player rarely spawns totally alone, hopefully making camping less effective, and counter attacks more deadly (As you are likely to face multiple opponents rushing out of spawn that you have to deal with as a group, rather than single players coming out one at a time over a longer period.)

 

 

I like this one in particular for the homeworld.  Timing the ships to all spawn at once as part of a wave (perhaps even displaying a countdown # on the planet for all teams to see) gives an interesting tactical scenario.  It would give an incentive to the offensive team to attack in a coordinated burst which makes endgame battles more climactic rather than drawn out wars of attrition.   

 

  




#5086081 starship death and regeneration

Posted by starbasecitadel on 15 August 2013 - 05:55 AM

This is for a space MOBA where each team tries to destroy the other teams' Citadel (homeworld) to win.

 

What should happen when a starship (player) is killed?

 

I see 3 options and am a bit split between what makes the most sense.

 

a) There is a small delay of about 1-5 seconds and then you are resurrected at your homeword at full health.  This is how Netrek did it and what I have so far, but it makes winning extremely hard (at least until I implement friendly/chain explosion damage but even then it might be frustrating defending your homeworld as you might continuously just regenerate and explode due to friendly explosions).

 

b) Resurrect at homeworld as above, but the delay is substantial the longer the game goes.  This is the League of Legends model.  It means death is more likely to severely impact the game the longer time goes on (the higher your levels are) which helps make it more likely for major endgame battles to be decisive.  I forget the exact seconds but it is something like 3 seconds or so at lv 1 and then a full minute or so by lv 18 the max level.

 

c) Resurrect instantly or with say a 1 second delay, but at a strategically less valuable place like a random planet far away from your team's homeworld though still closer to your team than any other team.  The nice thing here is you are always playing, you don't see that grey screen of death for a minute, or you don't appear immediately at your homeworld which makes winning so hard.   But, then again it might be annoying if endgame you just have to fly long-distance to get back into the action (presumably at your homeworld or attacking the enemy's by lategame).   On the other hand one thing I like about this is since you aren't always needing to do team fights, you can get to other objectives quickly without downtime and this is a nice way of spreading out the starships across the map.

 




#5071890 Addressing Issues with Mobile Gaming Inputs.

Posted by starbasecitadel on 21 June 2013 - 03:50 PM

Good posts.

 

I'm dealing with a somewhat similar issue now in my (early prototype) tablet game.   Initially feedback has been the game has some nice potential with some polish but right now controlling the spaceship and to a slightly lesser degree weapons fire UI are really bad.  My wife's comment was "the game shouldn't be as difficult as piloting an actual NASA spacecraft"  lol

 

I'm going back to the drawing board including another take at making use of the accelerometer to various degrees as well as some of the simpler, earlier controls like thruster buttons instead of swipe.  

 

Maybe I'm getting a bit desperate  but I'm even considering the nuclear option of support 2-5 different UI's.  Some players may prefer swipe, other movement by thruster buttons/controls, others by accelerometer, others firing by accelerometer etc.   I tend to lean against offering a variety of UI's because it increase design/code/testing complexity, and one approach may be found superior by the hardcore players.    I'd prefer to offer a single UI, but am just not sure if enough players will have a clear consensus on which of these is better.   In other words, if in further testing 80% or more prefer 1 approach, I am fine going with that.  But if 1/3 prefer the accelerometer, 1/3 swipe, and 1/3 traditional buttons perhaps I offer 3 choices and you can choose whatever.  




#5064809 A few painful questions about Databases

Posted by starbasecitadel on 25 May 2013 - 11:42 AM

I agree with the others.  For example here is one way to normalize it:

 

 

character

========

id

name

 

attribute

======

id 

name

 

character_attribute

===============

id

attribute_id

attribute_value

 

unique index main_ind (id, attribute_id)

 

 

Your character_attribute table will now have 500 rows per character.    This is much more scalable and still easy to work with.  

 

edit:  Just to populate this a bit to further illustrate:

 

character table

===========

id , name

1 , Conan

2 , Gandalf

 

character_attribute  table

===================

id , name

1 , class

2 , level

3 , strength

4 , spellpower

 

character_attribute

==============

id , attribute_id,  attribute_value

1 , 1 , Warrior

1 , 2 , 15

1 , 2 , 18

1 , 2 , 0

2 , 1 , Wizard

2 , 2, 20

2 , 3 , 5

2 , 4 , 19




#5056932 UDP packets from server to client

Posted by starbasecitadel on 26 April 2013 - 06:48 AM

I use UDP in both directions. 

 

I've tested at least 20 different places, including coffee shops, libraries, restaurants, 3g/4g cellular and never had a problem with firewalls/router incompatibility.   Maybe my sample size is too small, I'd really like to have about 200 different places tested before calling it a day (that's what Beta is for), but that has been my experience. 

 

While I haven't hit any router issues yet, I certainly have seen differences in packet loss and latency.  A couple Starbucks location are the worse: they average about 15% packet loss, 1200ms ping.




#5046895 What should I do after mastering GameMaker Studio

Posted by starbasecitadel on 26 March 2013 - 09:38 AM

This will help us to advise you by suggesting alternatives which do not share GM's limitations.

 

That makes sense if by "mastering gamemaker", OP means he has created fully playable game(s), possibly including publicly releasing them using GameMaker, and is now frustrated by its limitations and wants to create a more advanced game.  

 

If on the other hand OP means he is a master of all the various features of GameMaster, using their coding logic and full capabilities, but has not actually completed a single playable game (eg he can make every feature individually as a stand along prototype, but not compose them together as a cohesive product), then the next step for sure would be to create a game or two on GameMaker and release them.   A trap it is easy to fall into is to learn dozens of new languages, SDKs, engines, and other technologies for the sake of improving performance or the cool new features they have, without actually doing anything useful with it.    

 

But if he has created some GameMaster games he is happy with, the next step is to answer these 3 questions:

 

  - what kind of game types appeal to you the most (MMORPG, FPS, Facebook, strategy, shooter, social, etc)?

  - what kind of platforms (PC, mobile, console) are you interested in?

  - do you want to continue doing side/hobbyist projects, or do you want to join a game development company?

 

I wouldn't even think at all about specific languages/SDKs/engines until those 3 questions are answered. 

 




#5041701 Buying a "developer" spot on the new Richard Garriot project

Posted by starbasecitadel on 10 March 2013 - 09:41 PM

I agree, you definitely won't be in the "real" developer forums, or have access to their internal ticketing system, feature lists etc.

 

But even so, it sounds like there will be some opportunity to talk directly with their dev team, at least to a limited degree.




#5041534 Looking to move from Web Design to Game Development

Posted by starbasecitadel on 10 March 2013 - 09:49 AM

You really first should decide your target platform that you are most interested in, and if your primary goal to work on other people's games at a game development company, or your own games for side projects hoping to start your own company one day.

 

On platform, I recommend mobile for a number of reasons.  It is a rapidly growing market with much less saturation then PC, and gamers are more accepting of hobbyist games than on other platforms.    Also, job-wise the number of mobile game dev jobs is skyrocketing while there is less growth for jobs in other platforms (though they are at a much higher job base).   You just have a lot less competition on mobile right now, and that makes it easier to get hired and also move up the ranks as you are competing with people with < 5 years in mobile versus often 20 years on PC/console.

 

If you go to mobile route, I highly recommend CoronaLabs / Lua to learn first.  It is easy to learn and get a game going much quicker than almost any other environment.

 

Many new game devs believe getting into something with a higher learning curve, but that is used more often by some "hardcore" professionals, is a way to shortcut the process.  I strongly disagree!   The biggest problem by far for new game programmers is that they fail to ever produce any playable game.  Your resume and skills are way more impressive with a successful iOS game that is actually selling (even if only $1000/year) written in CoronaLabs, than someone who has strong C++ game dev skills on paper but has never produced a public game.

 

This isn't to say you should never learn C++, I'm just recommending Corona for your first couple of games-- then at that point you can either keep going with it (as you may find success with that route), or at that point start learning C++.   But it is really important to build a strong foundation of game dev skills first, and not trying to make life difficult by trying to learn game skills in a language/sdk tool set (C++) that requires a far steeper learning curve.   

 

 




#5040778 Breaking into industry without coding or art skills.

Posted by starbasecitadel on 08 March 2013 - 06:22 AM

 I never got into probability or percentage of vacancies that require specific skillsets.

 

I think that is a shortcoming of the analysis, however.     The rules of supply and demand are at work, so since there are only a small number of positions in the development process that don't require coding or artistic/musical skill, and many people who are interested in those roles (designers and producers), then your realistic chances of getting that position are much less likely.  Really the only position that has large numbers of non-coders/artists is QA, and even here there are far more people qualified for that position than for coding and art/music, so they are hard to get as well.  

 

In terms of roles such as lawyer and accountant, these generally aren't involved in game development and so really shouldn't be factored into this discussion.  

   

Maybe I have just missed the kinds of threads you have in mind though, or I am checking the wrong sections (I probably check Game Design the most here).  The ones I've seen are almost always along the lines of "I want specifically to be a producer or designer, and here is a brief or detailed description of the game I want to build.  But I have no coding or art experience, nor any coders or artists on my team."   For those kinds of people, they typically seem so wedded to their own specific game design that it is hard for me to imagine them being happy in another role like QA for someone else's project.  It is for these situations where the standard advice is they should learn coding or art, and I think it is good advice.

 

And even if it were all about indies and school projects - does a broader perspective really hurt that much? Is it that annoying, incorrect, wrong, revolting or unacceptable to look around and see there's more to game development than struggling to release a game for $0.99?

 

The answer here is going to be different for every person.  For some people, they would be very happy in any position contributing to the game development pipeline for any sized company on just about any project.  For them, a broader perspective can be a good thing.   For other people (and I'd include myself here), a large part of the fun is being a game designer for specific games you or a small team you are involved in comes up with and build it from scratch.   I've had several opportunities to join game companies but so far haven't been interested.  I'd much rather do what I'm doing now, which is work on non-game stuff for my day job, but have tons of creative control working on my own game on the side.   Which path is better will depend on individual personalities and goals. 

 

 




#5038271 Mobile Games

Posted by starbasecitadel on 01 March 2013 - 09:23 PM

I would recommend CoronaLab's product for most kinds of 2D mobile games.   If you have programming skills, but this is your first mobile game, then it is perfect.  You can come up to speed much more quickly with it then the others.

 

I'd only go with one of the others if you are doing something unusual enough that it requires more low-level control, in which case I would recommend Marmalade or possibly Moai, or Cocos2d.  Each of those 3 has a steeper learning curve, but you can have finer grain control, it just depends on what you are doing.   But for probably 95% of the games and applications I've seen for mobile, Corona would be a great choice.




#5035758 Understanding Game Design?

Posted by starbasecitadel on 23 February 2013 - 08:57 AM

I have not heard about even one indie studio where the founders were not programmers/artists. Directing and coordinating simply is not what is required.

 

Yeah, the issue is one of credibility.  If you have at least a couple hundred thousand or more to pay some salary that is one thing.    Raising that kind of money is not easy, unless you have a couple top-selling games you played a leading role in already (and even with those credentials, fundraising is by no means easy).

 

Getting people to join without pay is difficult, even if you give up substantial equity.   It requires you to sell a vision.  If you have never done a game before, you lack credibility.  If you have nothing to show, you lack credibility.   Even a visually appealing, polished, GDD and presentation that you took 3 years to write, sadly, probably isn't going to be enough to give you credibility.  At a minimum, you need either some nice art, or a prototype, to have a chance at successful recruiting people to join your team with no salary.

 

 

That's the approach I'm taking-- program a playable prototype, with the initial art coming from cheap royalty free images as well as royalty free sound effects which I hope to complete end of this year.   At that point, I'll be able to shake hands with artists, hand them my iPad and let them play the game as part of my recruitment pitch to see if they are willing to join the project.  

 

The #1 credibility question that prospective team members and investors will ask you for is "can you successfully produce something real"?   

 

Which answer will have a higher success rate making the pitch?

 

"Here is a working prototype, it is a playable demo version though it is missing many features and art.  Play this game and let me know what you think"

 

"Look at this concept art and UI mockups for all the major screen types that I've put together"

 

"I haven't programmed anything, I have no artistic ability, I never have been involved in video game production before.. but check out my game idea and design document"

 




#5033377 David and Goliath, how do you compete with a game giant.

Posted by starbasecitadel on 17 February 2013 - 09:06 AM

I typically see this as trying to find niches that game giants or other popular games do not cover.  

 

This is the key.  As an indie developer, your one and only edge over a large corp is also an extremely powerful one, you have a much greater ability to take creative risk and develop something unique.

 

When you work for a large company, what motivates the vast majority of people is keeping the steady paycheck.  Yes, even in a game company filled with creative people, after a few years some of the big company bureaucracy mindset that is so common creeps in for most organizations.  You don't want to be the producer who tries something unique, and it fails; even if you keep your job, you may very well get demoted or at least lose a lot of prestige and be known as "the one with that looney idea that flopped and cost us millions!"     So, you stick to what is safe; ideas that are far less likely to be home runs or particularly innovative, but are also much less likely to lose lots of money.  

 

As an indie developer you have more room for risk taking, mostly because your company is still relatively small and flexible.  You still are worried about your paycheck, but there is a more entrepreneurial feel that gives you much more flexibility.  

 

Then, as a hobbyist developer, you have the most room for risk taking of all.  As a hobbyist developer, the cost for you failing is so low (since by definition games aren't your primary source of income, so it is pure opportunity cost you are risking).

 

The key is coming up with something that has at least some unique feature or innovation and running with it.  That doesn't mean you have to create an entirely new genre or paradigm in the way that Ultima created the RPG genre, id Software created 3d fps,  EverQuest/WoW for MMORPG, Minecraft for sandbox etc.   That is of course awesome, but far more commonly you can still become very successful within a normal genre with a couple innovative features.

 

In fact, I would ask myself "is my innovation so unique and daring/risky that major studios would avoid it?"   The space where they refuse to operate in is exactly the space where you should be operating.    This is a space where on the downside, it is more risky and you should expect a lot more projects to fail, but it is also where home runs and serious breakthroughs are more likely.

 

Innovation does not have to be limited to game design itself (though that is what myself and probably most people here are interested in).  It could be a marketing innovation, in much the same way affiliate marketing propelled the success of so many  early internet businesses across many industries.  It could be an HR innovation, where you discover a very effective way to successfully recruit talented high school or college game developers.  It could be a teamwork innovation, where you create a new communication style that significantly enhances team productivity.  

 

Opportunity to take innovative risks is your one and only edge as a hobbyist/indie developer-- milk it! 

 

 

 

 

 

 

 

 

  

 

 

 

 

 

 




#5033354 Interesting "mix of games" game idea

Posted by starbasecitadel on 17 February 2013 - 07:45 AM

There are some cool ideas here for sure in terms of the design.

 

Hey guys, i've just started learning to code

 

However, as a project for a new coder?  No way.. it is far too complex.     I know it isn't as sexy and inspirational to start with a simple single-player game like Tetris, but that by far is a quicker way to build up your skill set than starting on something extremely advanced, and probably only making it 5% complete after 1 year and then getting frustrated and possibly never trying to make a game again.   

 

 

 

For example, my first game was a ASCII based Mines of Moria kind of game, then did some simple 2d sprite animation stuff, then a bit later did a single player Stratego game, then added networking multi-player to it, then did Chess, etc.    Walk, then run!




#5025266 Ideas are a dime a dozen...

Posted by starbasecitadel on 24 January 2013 - 05:35 PM

For some business applications, where requirements are very rigid and the general type of problem is pretty familiar, then a waterfall / non-iterative approach can make sense.

 

But for game design, at least for me personally, an iterative approach has been useful enough that I can't imagine using a non-iterative approach, from a practical basis.

 

To take just one example, I had initially imagined/planned/designed that the movement UI would be heavily accelerometer based.   But, before I settled on my current movement AI, I quickly prototyped 3 different UI's: accelerometer, traditional buttons, and swipe. Over the course of a few weeks, myself and 2 others tested all 3 prototypes, and I made quick coding tweaks to fix bugs / fine-tune.  We found that what I envisioned (the accelerometer), was absolutely terrible and so got scrapped completely and ended up going with swipe.  

 

I'm very glad that I (or anyone else) did not spend dozens of hours making extensive, detailed plans based on using the accelerometer, as all that design work would of been wasted.  

 

This isn't to say a nice design or an "ideas guy" is bad, I think they can be extremely useful in some situations.  Specifically, where they are not set in stone but willing to rapidly iterate, and you already have enough programmers and artists.

 

For a small hobbyist team, an ideas guy even without programming or art skill could still be extremely useful to the team, as long as they are able and willing to do a lot of non-design tasks and grunt work the team needs too, as opposed to spending 90% of their time on ideas.  If they spend 25% of their time or less on idea generation / design documentation, and 75% or more on other useful tasks, it could work out. 

 

I'm talking about things like:

 - recruit additional members: go to arts colleges and compsci colleges, hand out business cards, tack on your posters, go to game boards

 - community outreach - go to web boards and chats and try to find new alpha testers

 - find and purchase things like server hardware as needed

 - schedule interviews with prospective new team members

 - book meeting rooms / library room time / videochat and coordinate schedules for team meetings

 - grunt work to relieve the artist: sometimes the concept artist needs 100 images to be resized in a way you can't automatically batch it, this is an area the ideas guy can help out, getting the artist back to working on the aspects of concept art creation only they have the skillset to do

 - update the team's game website with content / blog posts

 - research cost-effective marketing plans

 

If someone is the "ideas guy" and refuses to help out with these kinds of things, when the programmer(s) and artists are overloaded with work, that is probably what people are objecting to.

 

Now, if the team is big enough, say 10?  20 people?  At a certain point, I think a full-time purist ideas guy / game designer or even several could make sense, depending on the situation.  I haven't worked on game development teams that large, but hypothetically I could see a lot of value at that point in a true purist ideas guy, for some scenarios.

 

 

 

 



#5024706 Starbase Citadel - minimum viable product

Posted by starbasecitadel on 23 January 2013 - 07:32 AM

I skimmed through your list, which has quite a lot, and I think it might be better to think of what is the minimum needed to be playable.  Not a complete game, but to start showing something at all.  I.e. 2 races, 1 unit for each race, 1 race controlled by AI, one race controlled by player, can fly around in an area, and try to take out the opponent.  Then add another unit.  

 

 

Thanks!   Yeah, I am realizing even my initial target plan was a little daunting.  I've broken it down into a much-reduced initial version with just 2 starship types (1 for each of the 2 initial races) with a single ability (besides the built-in lasers and torps that all ships get).   The goal for this release is an internal early Alpha version; a fully playable game suitable for a small group of alpha testers to play.

 

 

One piece of advice I would give is re-edit your list so that you separate them into subgroups and features associated eg:
 
Player
Unit (ship) etc.
 
At the moment reading through the list it skips back and forth in the types of features and what they would be associated with. Furthermore as you divide them up it is more likely that a feature that isn't there but should be can be identified.

 

Good points, I've organized it a little better and you are right, that made it more obvious I had missed several necessary features.

 

 

 

I would also get a UserVoice account, which is a free system that lets players suggest ideas and vote on them, which will tell you in larger scale what is important to the players, and how they view the game over all and its direction.  (Each player gets 10 points, and can add 1, 2 or 3 points to any idea, including ones they propose.  You could throw your own ideas out there as well, and see how they fair.

 

I checked it out and it looks like a great way to provide a feedback mechanism.  Thanks!

 

 

 

Alpha I Version

 

Human Frigate

  •  Torpedoes: collision detection / damage
  •  Ability: Shield Flare
  •  AI

 

Regelos Destroyer

  • Ability: Repeat Laser Blast
  • AI

 

Bases: Art + AI for each of the following 

  •  Human Starbase
  •  Regelos Starbase
  •  Human Citadel
  •  Regelos Citadel

 

Energy

  •  Add energy indicator to main screen
  •  Subtract more energy for faster movement as well as laser use
  •  Disallow lasers or fast movement when out of energy, shields max at half

 

General Gameplay

  • Friendly versus Enemy (no friendly fire), display team color
  • Stats: Display these small icons around each ship on tactical map:  Hull, Shield, Energy
  • Display remaining game objects on strategic window
  • Add borders to game world / fix size 

 

 

Planets

  • capturing enemy planets mechanism
  • seeding planets: assign ownership of planets at game start
  • display team ownership of each planet on tactical and strategy map
  • defense grid
  • repair/fuel stations 

 

Player Slot Management

  • 20 players per team
  • victory conditions (server reset)
  • players entering / leaving game conversions with AI
  • quit button





PARTNERS