Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Our 1.6 years in the industry thus far.



Before "Starting Fresh" I'd like to take a moment and look back on the 1.6 years PolyInteractive has had in the gaming industry, looking back to when we first bashed our heads together and conjured up the amazing idea to put our gaming degrees to good use and start our own gaming studio... Oh how I envy our old bright eyed and bushy tailed selves, we were so optimistic. 



We started off by registering our company on "Companies house" and this was it, this is what made us official and if you searched for PolyInteractive Games on the Companies House website you'd find us, it was great.

Later in that day we looked into getting a loan, those big bad scary things that you should probably avoid especially if it's coming from the Government/ loan shark, or get a loan from a wealthy relative/ bunch of relatives, I'd have taken the latter if it was an option, however, it was not, so I went with the loan shark... I jest, Government, I went with a Government loan. How much did I get? I managed to get a £15,000 loan because my credit was amazing *Insert amazing gif* 

The application and gaining the £15,000 was a month-long process that involved business plans, future projections, proof of identity etc... etc...  

We then over the course of 7 months spent the £15,000... We bought new equipment, a bunch of licenses like Photoshop, Illustrator, Substance painter and 3DS Max, computer desks, an accountant and a space to rent... Everything was looking great, we even found a 2D artist, a 3D artist and a programmer all willing to work for free and reap the rewards of a finished game (they'd get a % of what the released game would make) 






The downfall all started when our programmer handed in his resignation to his day to day workplace as he wanted work full time on the game, him not being big on his IT job in the first place really helped him in his decision to move to us, however, he was that good at his job he was given a higher wage to stay at his IT company, and who'd blame him, with the raise he got we couldn't argue, and with that swift blow our programmer was gone.


After our programmer left our 2D artist went a.w.o.l and vanished and we still to this day haven't heard from him, not long after our 3D programmer became so busy with the day job that he too slowly vanished into the black.

We started looking online for people to fill these empty seats & holes in our hearts but no one was willing to work for cash that a game may or may not make, thus leaving us with a game that was close to being half complete. 



A month went by after we lost our team to their day to day lives and temptations of better wages that we started to spiral out of control in our personal lives, Alex and myself found our selves technically homeless, living out of our office space which was  7 foot wide by 20 foot long, and the only thing separating all the companies in this office space was a very thin wall, thin enough you could hear could hear the next business, it was usually best working with headphones in to avoid distractions. We used to cover the doors glass panel and sleep in hidden placed (under desks, behind shelves) so that other business didn't know we were sleeping in an office space that didn't even have a shower (we cleaned in the toilet sinks) but we still worked on the game, Alex being the 3D artist and myself being the 2D artist and together being game designers, waiting for a programmer to answer our Polycount advert. 



Homeless or not, we still worked our asses off. 



 A few weeks went by of radio silence until we finally got an email, a British student studying in Sweden answered our prayers and this person was a programmer, we rejoiced and got the game to a half-completed state within a few weeks, just in time for EGX. 

To go to EGX we needed £700 but we only had £350 in our bank left over from the £15,000 we had originally loaned, so we called up the EGX representatives and asked if an exception could be made to which they agreed, we would pay half now and half later, things were finally looking up for us. 




Now you might think that things were easy from here on out, but we had to figure out a way to get to London, and stay in a hotel room for 4 days during the event, so our producer who's good at this sort of thing finds us the best-staying deals and he himself is willing to drive us down there to show off our game, however, we just spent the last of our money on getting the ticket... Needing the money Alex throws his car on Facebook for £300 ono and within a day Alex gets a reply to meet up with the guy willing to buy the car, Alex sells the car for £200 and an ice cream.  (He never did get that ice cream) 




We spent 4 glorious days at EGX, we met some new faces and some old, I met old tutors who had gone on to creating their own games company and making it successful & met new games companies also trying to make their way in life just like ourselves, we ate homemade meals as our B&B apartment thing had a small kitchen and our producer was very nice to us and took money from his own pocket to feed us. 

While at EGX we had the opportunity to meet with publishers, publishers like Sindiecate, Play Stack & Rebellion, all amazed at how quickly we put together our game and how we went about making it but none of them took the bait, no one wanted to publish our game, so we left EGX, we were still happy because we got to meet so many people but slightly disheartened that publishers didn't want to help us in making our dream. 

When we got back to the studio we poked around for more publishers sending emails to at least 30+ publishes in and out of the UK, about 80% didn't reply and the 20% that did wasn't interested or didn't work in the mobile games market. 

Later that evening we released out game Rise of Factions: Sparta, only half finished with a promise to complete it when we can for free. 






After releasing Rise of Factions: Sparta we sat and waited and watched the installs of the game, for days no installs were added to the Google Development Console, we pushed it as hard as we could on social media sites, we didn't have any cash to pay for advertising, so all we could do was watch as no one installed the game, and we're certain it's because of the £0.99 price tag we attached the unfinished game, but a lesson was learnt, the industry is harder than it looks. 

Myself and Alex were given a week to move out of the office as we had overstayed our welcome for 2 months owing our landlord £1200+ and our accountant services we discontinued and a payment of £700+ was also due to be paid back, making a nightmarish sum of £1900 to be paid back, to which our loan also wanted us to start paying back at a £350 a month sum... We managed to hold things off as we'd just become more homeless & because we were too broke to start paying any of it back. 

Myself and Alex found a very very small place to live, we chucked out the bed so we could move our office into the only living space there was and we both slept on the floor, myself on a futon I managed to save from my last relationship and Alex in his old trusty sleeping bag, and we slept like this for 4 more months, we were beaten down, but we weren't out for the count.  


I'm going to leave this blog here with you and give you the rest of the story in a weeks time, I didn't realize that I would fill a blog with so much content.



Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By G-Dot
      Hello everyone! I've decided to implement a destructible enemies system.
      When bullet hit enemy in specific part of his body(arm fo example) armour, which covers that part of body, will fall off. Enemies in my game are robots so this means that when shooting them certain plates of their armour will fall off. All enemies will have a different amount of armour plates
      My solution: 
      The only solution I came up with is to make an actor with a static mesh and attach it to the bones of enemy's skeletal mesh. When bullet hit that actor it detaches and fly away with add impulse node.

      Maybe there is a better solution, which I'm missing and it's more efficient. 
    • By mujina
      What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
      I'll be more specific about my design issue:
      I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
      My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
      for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic `get_collider_of_entity` function, but rather a function `get_circle_collider_of_entity` and a separate one `get_line_collider_of_entity`, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
      I am in need to write a system as the one in the snippet above. I can write several overloaded `check_collision` functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic `get_collider_of_entity` function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
      One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
      get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
      Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual `collide_with(const Collider& other)` method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
      A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
      I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!